Après avoir lu sur les espaces de noms Linux, j'avais l'impression qu'ils sont, parmi de nombreuses autres fonctionnalités, une alternative au chroot. Par exemple, dans cet article :
D'autres utilisations [des espaces de noms] incluent […] l'isolation de style chroot() d'un processus à une partie de la hiérarchie de répertoire unique.
Cependant, lorsque je clone l'espace de noms de montage, par exemple avec la commande suivante, je vois toujours toute l'arborescence racine d'origine.
unshare --mount -- /bin/bash
Je comprends que je suis maintenant en mesure d'effectuer des montages supplémentaires dans le nouvel espace de noms qui ne sont pas partagés avec l'espace de noms d'origine et donc cela fournit une isolation, mais c'est toujours la même racine, par ex. /etc est toujours le même pour les deux espaces de noms. Ai-je encore besoin de chroot changer la racine ou existe-t-il une alternative ?
Je m'attendais à ce que cette question fournisse une réponse, mais la réponse n'utilise que chroot , encore une fois.
MODIFICATION #1
Il y avait un commentaire maintenant supprimé qui mentionnait pivot_root . Puisque cela fait en fait partie de linux/fs/namespace.c , il fait en fait partie de l'implémentation des espaces de noms. Cela suggère que changer le répertoire racine uniquement avec unshare et mount n'est pas possible, mais les espaces de noms fournissent une version propre - plus intelligente - de chroot . Je ne comprends toujours pas l'idée principale de cette approche qui la rend fondamentalement différente de chroot , même après avoir lu le code source (dans le sens par exemple de la sécurité ou d'une meilleure isolation).
MODIFICATION #2
Ce n'est pas un doublon de cette question. Après avoir exécuté toutes les commandes de la réponse, j'ai séparé /tmp/tmp.vyM9IwnKuY (ou similaire), mais le répertoire racine est toujours le même !
Réponse acceptée :
Entrer un espace de noms de montage avant de configurer un chroot , vous permet d'éviter d'encombrer l'espace de noms de l'hôte avec des montages supplémentaires, par ex. pour /proc . Vous pouvez utiliser chroot à l'intérieur d'un espace de noms de montage comme un hack simple et agréable.
Je pense qu'il y a des avantages à comprendre pivot_root , mais il a un peu de courbe d'apprentissage. La documentation n'explique pas tout à fait… bien qu'il y ait un exemple d'utilisation dans man 8 pivot_root (pour la commande shell). man 2 pivot_root (pour l'appel système) pourrait être plus clair s'il faisait la même chose et incluait un exemple de programme C.
Comment utiliser pivot_root
Immédiatement après avoir entré l'espace de noms de montage, vous avez également besoin de mount --make-rslave / ou équivalent. Sinon, toutes vos modifications de montage se propagent aux montages dans l'espace de noms d'origine, y compris le pivot_root . Vous ne voulez pas ça :).
Si vous avez utilisé le unshare --mount commande, notez qu'il est documenté pour appliquer mount --make-rprivate par défaut. AFAICS c'est une mauvaise valeur par défaut et vous ne voulez pas cela dans le code de production. Par exemple. à ce stade, il arrêterait eject de travailler sur un DVD monté ou une clé USB dans l'espace de noms d'hôte. Le DVD ou la clé USB resterait monté dans l'arborescence de montage privée et le noyau ne vous laisserait pas éjecter le DVD.
Une fois que vous avez fait cela, vous pouvez monter par ex. le /proc répertoire que vous utiliserez. De la même manière que vous le feriez pour chroot .
Contrairement à l'utilisation de chroot , pivot_root nécessite que votre nouveau système de fichiers racine soit un point de montage. Si ce n'est pas déjà le cas, vous pouvez le satisfaire en appliquant simplement un montage lié :mount --rbind new_root new_root .
Utilisez pivot_root – puis umount l'ancien système de fichiers racine, avec le -l / MNT_DETACH option. (Vous n'avez pas besoin de umount -R , ce qui peut prendre plus de temps.).
Techniquement, en utilisant pivot_root doit généralement impliquer l'utilisation de chroot aussi bien; ce n'est pas "soit-ou".
Selon man 2 pivot_root , il est uniquement défini comme l'échange de la racine de l'espace de noms de montage. Il n'est pas défini pour changer le répertoire physique vers lequel pointe la racine du processus. Soit le répertoire de travail courant (/proc/self/cwd ). Il se trouve que c'est le cas faites-le, mais c'est un hack pour gérer les threads du noyau. La page de manuel indique que cela pourrait changer à l'avenir.
Habituellement, vous voulez cette séquence :
chdir(new_root); // cd new_root
pivot_root(".", put_old); // pivot_root . put_old
chroot("."); // chroot .
La position du chroot dans cette séquence est encore un autre détail subtil. Bien que le point de pivot_root est de réorganiser l'espace de noms de montage, le code du noyau semble trouver le système de fichiers racine à déplacer en regardant la racine par processus, qui est ce que chroot ensembles.
Pourquoi utiliser pivot_root
En principe, il est logique d'utiliser pivot_root pour la sécurité et l'isolement. J'aime penser à la théorie de la sécurité basée sur les capacités. Vous transmettez une liste des ressources spécifiques nécessaires et le processus ne peut accéder à aucune autre ressource. Dans ce cas, nous parlons des systèmes de fichiers transmis à un espace de noms de montage. Cette idée s'applique généralement à la fonctionnalité "espaces de noms" de Linux, bien que je ne l'exprime probablement pas très bien.
chroot définit uniquement la racine du processus, mais le processus fait toujours référence à l'espace de noms de montage complet. Si un processus conserve le privilège d'effectuer chroot , il peut alors parcourir l'espace de noms du système de fichiers. Comme détaillé dans man 2 chroot , "le superutilisateur peut s'échapper d'une 'prison chroot' en...".
Une autre façon stimulante de défaire chroot est nsenter --mount=/proc/self/ns/mnt . C'est peut-être un argument plus fort pour le principe. nsenter / setns() recharge nécessairement la racine du processus, à partir de la racine de l'espace de noms de montage… bien que le fait que cela fonctionne lorsque les deux font référence à des répertoires physiques différents, pourrait être considéré comme un bogue du noyau. (Note technique :plusieurs systèmes de fichiers peuvent être montés les uns sur les autres à la racine ; setns() utilise celui du haut, le plus récemment monté).
Cela illustre un avantage de combiner un espace de noms de montage avec un "espace de noms PID". Être à l'intérieur d'un espace de noms PID vous empêcherait d'entrer dans l'espace de noms de montage d'un processus non confiné. Cela vous évite également d'entrer à la racine d'un processus non confiné (/proc/$PID/root ). Et bien sûr, un espace de noms PID vous empêche également de tuer tout processus qui se trouve en dehors de celui-ci :-).