Faut-il abandonner le chroot ou copier iproute2 dans la prison ?
Une prison incomplète échoue après le démarrage, pas au boot. Choisissez entre assouplir le durcissement et copier les binaires ainsi que les bibliothèques dans la nouvelle racine.
Le service démarre, un client s’associe, et aucune route n’apparaît jamais côté serveur. Ou bien le démon refuse de démarrer et nomme une commande qu’il n’a pas pu exécuter. Les deux issues suivent les mêmes trois lignes, généralement copiées ensemble depuis un guide de durcissement : passer à un compte non privilégié, abandonner le groupe et changer la racine du système de fichiers. Une seule des trois cache des fichiers, et une seule d’entre elles retire le privilège de modifier la table de routage. Les séparer est la façon d’apprendre quelle ligne vous voulez vraiment.
Ce que la prison retire et dont le démon a encore besoin
Le changement de racine a lieu après le démarrage, donc le démon garde tout ce qu’il a déjà ouvert et perd tout ce qu’il ouvrirait ensuite. Tout assistant exécuté par la connexion après ce point doit exister dans la nouvelle racine, avec les bibliothèques partagées qu’il charge. Une prison construite à partir d’un fichier de configuration et d’un certificat n’a ni l’un ni l’autre.
Passer à un compte non privilégié est une restriction distincte. Un processus qui a renoncé à root peut être incapable de modifier des routes ou de monter une interface, même quand le binaire est juste là, donc les deux défaillances doivent être diagnostiquées séparément.
Trois conditions décident de la correction nécessaire
La première condition est la façon dont votre build installe les routes. Les versions récentes d’ OpenVPN configurent l’interface et la table de routage dans le processus, tandis que les paquets plus anciens et les configurations maison s’appuient sur des outils externes ou sur des scripts up et down. Si le journal nomme une commande, un outil externe est en jeu et la prison le cache. Si le journal affiche plutôt une erreur de permission, c’est le compte qui pose problème.
La deuxième est la maintenance. Une prison avec des binaires copiés doit être rafraîchie à chaque mise à jour du paquet qui les fournit, sinon la première mise à jour laisse un tunnel cassé derrière elle. La troisième est de savoir si un contrôle précis exige réellement un chroot ; si l’exigence porte en fait sur la séparation des privilèges, le changement de compte peut suffire à lui seul.
| Signal in the log | Other side of the boundary | Repair direction |
|---|---|---|
| Command not found after startup | Binary and its libraries absent inside the new root | Populate the jail, or drop the chroot line |
| Operation not permitted | Account lost the privilege to edit routes | Keep the account privileged, or pre-create routes elsewhere |
| No such device | Jail lacks the tun device node | Create the node inside, or open it before the root change |
Ce qu’une prison fonctionnelle doit contenir
Une prison qui exécute des commandes a besoin du binaire, de chaque bibliothèque à laquelle il est lié et de tout nœud de périphérique que le démon ouvre tard. Copiez les pièces et testez-les sans le VPN dans l’image :
ldd /usr/sbin/ip
chroot /etc/openvpn/jail /sbin/ip route show
chroot /etc/openvpn/jail /sbin/ip link set tun0 upLa première commande liste les dépendances, et c’est celle que les gens sautent. Un binaire copié qui ne trouve pas une bibliothèque échoue avec un message différent d’un binaire manquant, et les deux ressemblent à une panne OpenVPN quand on les lit côté client. Exécuter la commande à la main dans la prison reproduit la panne sans redémarrer le service.
Copiez aussi la configuration, les certificats et toute CRL dans la prison, car un fichier que le démon s’attend à relire après le démarrage ne sera pas trouvé une fois la racine changée. Notez ce que vous avez copié, puisque la mise à jour suivante du paquet réseau remplace les originaux et laisse la prison sur l’ancienne copie.
Réduire le durcissement à la place
Si la prison existe seulement parce qu’un guide l’a dit, retirer cette ligne tout en gardant les restrictions de compte est une issue défendable. Le démon conserve sa vue du système de fichiers et perd le problème, et la baisse de privilèges retire toujours root du processus de longue durée.
Notez ce qui reste, et pourquoi. Une configuration qui a perdu un contrôle en silence, sans note, est la façon dont le durcissement dérive, et le prochain audit demandera pourquoi la ligne a disparu.
Diviser les trois lignes avant de choisir
Copiez la configuration, désactivez les trois directives et confirmez qu’un client se connecte et que les routes attendues apparaissent. Réactivez ensuite seulement les lignes de compte, puis le chroot seul. L’étape où le tunnel casse identifie la frontière, et vous évitez de reconstruire une prison qui n’était jamais la cause.
Une fois qu’il route de nouveau, lancez une session client avec une verbosité plus élevée et lisez la ligne qui nomme la commande ou la permission en échec. Cette ligne vaut plus que le délai d’attente que le client finit par signaler.