Comment configurer les prisons Linux chroot

Le terme prison chroot a été utilisé pour la première fois en 1992, dans un article d’un éminent chercheur en sécurité, Bill Cheswick, (ce qui est intéressant si vous aimez ce genre de chose, vous pouvez trouver l’article ici). Les prisons Chroot ont commencé à apparaître en 2003, avec des applications comme IRC et FTP. En 2005, Sun a introduit sa technologie de “conteneurs” appelée Zones, qui était à son tour un précurseur du concept d’espaces de noms, qui est une technologie de base utilisée avec les conteneurs.

Bases de Chroot

Chroot permet à un administrateur de contrôler l’accès à un service ou à un système de fichiers tout en contrôlant l’exposition à l’environnement de serveur sous-jacent. Les deux exemples courants que vous pourriez rencontrer sont pendant la séquence de démarrage et le “shell d’urgence” sur les systèmes Red Hat/ CentOS / Fedora, et en FTP sécurisé (SFTP).

La commande ressemble à ceci:

chroot <newroot> ]

Semblable à la commande sudo, la commande chroot modifie l’environnement de la commande suivante. En d’autres termes, cela vous changera vers le répertoire newroot, et fera également de ce répertoire le répertoire “fonctionnel”. Le command s’exécute ensuite à cet emplacement, ce qui est utile pour sauver un système qui ne démarre pas.

Contrairement à sudo, vous serez “dans” le répertoire. Cette pratique, encore une fois, est utile si vous démarrez à partir d’un support externe mais que vous devez accéder à un système de fichiers ou à une commande “local” pour travailler.

L’autre utilisation courante de chroot consiste à restreindre un service ou un utilisateur en utilisant un wrapper pour masquer le reste du système de fichiers, limitant ainsi la vue d’un utilisateur distant des données des autres utilisateurs. Une implémentation populaire utilisant cette approche SFTP.

Exemple

Avant de commencer à utiliser cet exemple, vous devez vous assurer d’avoir des sauvegardes. Dans ce cas, sauvegardez le fichier /etc/ssh/sshd_config car vous apporterez des modifications spécifiques à celui-ci:

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Pour l’instant, vous limiterez uniquement les utilisateurs SFTP à leurs répertoires personnels sur le serveur. Cette exigence signifie que vous devrez ajouter des utilisateurs et les placer dans un groupe:

# useradd -g sftpusers -s /sbin/nologin -p nick nick

Notez que cela affectera nick un compte sans shell de connexion. Cette technique est à la fois pratique et une bonne pratique de sécurité: S’il utilise simplement SFTP, il ne devrait pas avoir de privilèges de connexion. Je discuterai de la fourniture d’un shell aux utilisateurs distants dans le prochain article.

Maintenant, vous devez indiquer au service ssh ce qu’il faut faire lorsque les utilisateurs de SFTP se connectent. Ouvrez le fichier /etc/ssh/sshd_config et ajoutez ce qui suit à la fin:

Subsystem sftp internal-sftpMatch Group sftpusersForceCommand internal-sftpChrootDirectory /homeX11Forwarding noAllowTcpForwarding no

Il est important d’ajouter ces paramètres en tant qu’ensemble d’entrées séparé et d’utiliser la syntaxe Match pour indiquer que cette section ne s’applique qu’aux utilisateurs de ce groupe. Si vous apportez les modifications aux entrées existantes, elles s’appliqueront à tous les utilisateurs SSH, ce qui pourrait interrompre l’accès distant.

Les lignes de configuration se décomposent comme suit:

• Le ForceCommand fait que ssh choisit son installation intégrée pour fournir un service SFTP (que vous pouvez contrôler indépendamment).
• ChrootDirectory indique à sshd où restreindre l’utilisateur.
• Subsystem sftp internal-sftp indique à sshd de charger le service interne sftp et de le rendre disponible.

Vous devrez peut-être vous assurer que ce Subsystem n’est pas déjà défini en commentant cette ligne plus tôt dans le fichier de configuration:

# override default of no subsystems# Subsystem sftp /usr/libexec/openssh/sftp-server

Une fois que vous avez apporté les modifications et vérifié l’orthographe, allez-y et enregistrez les modifications. Puis, redémarrez sshd:

# systemctl restart sshd

Tester le nouvel utilisateur:

$ sftp nick@showmenick@showme's password:Connected to [email protected]> lsaccounting ansible fred jason kenny lisa nicksftp> pwdRemote working directory: /sftp> exit

Oups, attendez une minute: On dirait que vous pouvez également voir tous les répertoires des autres utilisateurs. Cependant, vous ne pouvez pas accéder à ces répertoires:

sftp> cd fredsftp> lsremote readdir("/fred"): Permission denied

Vous pouvez diriger l’utilisateur chrooté vers son propre répertoire personnel en modifiant la ligne ChrootDirectory dans le fichier sshd_config comme ceci:

ChrootDirectory /

Ce changement rapide donne à Nick l’impression qu’il se trouve dans son propre répertoire personnel et qu’il ne pourra voir les fichiers d’aucun autre utilisateur:

sftp> pwdRemote working directory: /home/nicksftp>sftp> exit$ touch test.txt$ sftp nick@showmenick@showme's password:Connected to [email protected]> put test.txtUploading test.txt to /home/nick/test.txttest.txt 100% 0 0.0KB/s 00:00sftp> lstest.txtsftp>

Où est-il passé ? Vérifiez ceci:

# ls /home/nicktest.txt

Notez que a chroot jail n’est pas considéré comme une restriction de sécurité adéquate en soi. Bien qu’il empêche un utilisateur de sortir d’un répertoire restreint, il existe des moyens de contourner cela (l’idée générale est mentionnée dans la page de manuel chroot(2), que vous devriez consulter si vous envisagez d’utiliser cette astuce dans un contexte critique de production ou d’entreprise.)

Conclure (pour l’instant)

Ainsi, vous pouvez voir que chroot peut être un outil assez utile. Dans la partie 2, j’examinerai plus en détail l’attribution de répertoires spécifiques aux utilisateurs et la fourniture d’un environnement shell à un utilisateur distant sans exposer le reste du serveur.

Nouveau dans les conteneurs? Téléchargez l’introduction sur les conteneurs et apprenez les bases des conteneurs Linux.