diff options
Diffstat (limited to 'content/Informatique/chroot.rst')
| -rwxr-xr-x | content/Informatique/chroot.rst | 107 |
1 files changed, 53 insertions, 54 deletions
diff --git a/content/Informatique/chroot.rst b/content/Informatique/chroot.rst index ce5a733..f394fd2 100755 --- a/content/Informatique/chroot.rst +++ b/content/Informatique/chroot.rst @@ -15,19 +15,18 @@ La demande ~~~~~~~~~~ Ma copine m'a demandé de trouver une solution simple pour échanger des -fichier avec sa sœur, msn posant des problèmes… J'ai pensé à mon serveur -ssh et mettre en place une connexion sftp pour ça. Sur le principe cela -a été adopté avec une petite présentation de filezilla (je ne sais pas -s'il existe des clients sftp intégrés sous windows ?), j'ai donc -commencé à mettre en place le système. De mon côté, la condition -principale est de n'autoriser les connexions que par clef publique ( pas -de mot de passe ), ma copine a tenu à ce que sa sœur ne puisse pas -accéder aux documents présents dans son home, et du mien à ce que l'on -ne puisse pas pour autant se promener dans l'arborescence du serveur : -il va donc falloir chrooter l'environnement. Il existe pas mal de -documentation la dessus sur internet, mais je me suis souvent retrouvé -face à des exemples incorrects ou incompatible avec le fait de passer -par une clef publique, je vais donc détailler les problèmes rencontrés. +fichiers avec sa sœur, msn posant des problèmes… J'ai pensé à mon serveur ssh +et mettre en place une connexion sftp pour ça. Sur le principe cela a été +adopté avec une petite présentation de filezilla (je ne sais pas s'il existe +des clients sftp intégrés sous windows ?), j'ai donc commencé à mettre en place +le système. De mon côté, la condition principale est de n'autoriser les +connexions que par clef publique (pas de mot de passe), ma copine a tenu à ce +que sa sœur ne puisse pas accéder aux documents présents dans son home, et du +mien à ce que l'on ne puisse pas pour autant se promener dans l'arborescence du +serveur : il va donc falloir chrooter l'environnement. Il existe pas mal de +documentation la dessus sur internet, mais je me suis souvent retrouvé face à +des exemples incorrects ou incompatible avec le fait de passer par une clef +publique, je vais donc détailler les problèmes rencontrés. Le compte + clef publique ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -41,30 +40,30 @@ La première étape est de créer le compte, cela se fait assez simplement |Création de la clef ssh avec puttygen| et en répondant aux questions par défaut… Vient ensuite la clef publique : filezilla gère les clefs -privés au format ppk ( putty ) et je n'ai pas trouvé d'outil pour les +privés au format ppk (putty) et je n'ai pas trouvé d'outil pour les générer sous windows. Je suis donc passé par wine + puttygen pour créer la clef. Une fois celle-ci crée, on enregistre la partie publique et la partie privée de la clef. La clef publique va être enregistrée dans le fichier ${user}/.ssh/know\_host sur le serveur pour autoriser le client à s'y connecter. La clef privée sera enregistrée de son côté au format ppk pour être utilisée par filezilla (il est possible à partir de ce -fichier de générer une clef privée de type openssh ). +fichier de générer une clef privée de type openssh). |image1| Il faut ensuite intégrer la clef privée dans filezilla en passant par -les paramètres : elle sera automatiquement lue à la connexion ( il faut -choisir «interactive» dans le type d'authentification ). ( Attention : +les paramètres : elle sera automatiquement lue à la connexion (il faut +choisir «interactive» dans le type d'authentification). (Attention : sous windows j'ai rencontré des problèmes avec un répertoire contenant des accents, la clef semblait être lue, mais la connexion ne se faisait -pas pour autant. ) +pas pour autant.) Chrooter l'environnement ~~~~~~~~~~~~~~~~~~~~~~~~ Aujourd'hui il est possible de chrooter nativement un environnement sftp avec openssh. Il faut pour cela mettre en place une condition sur -l'utilisateur ( ou le groupe ) pour faire le chroot : +l'utilisateur (ou le groupe) pour faire le chroot : :: @@ -84,13 +83,13 @@ connexion par clef. En effet, lorsque l'utilisateur va se connecter, ssh va lire dans son répertoire personnel pour lire le fichier .ssh/know\_host et autoriser ou non la clef qui se présente. Ce qui signifie que si l'on modifie le répertoire personnel, il faut aussi -déplacer cette arborescence ( hors de question dans ce cas de mettre / -comme racine de l'utilisateur ). À noter : j'ai préféré faire le match -sur le nom de l'utilisateur plutôt que sur son groupe ( le groupe sera -utilisé par ailleurs ). Dans le cas où nous avons plusieurs -utilisateurs, il est possible de les mettre à la suite ( séparés par des -virgules ). J'ai vu de nombreux tutoriaux qui indiquent comme répertoire -de chroot « /home/%u » ( le répertoire de l'utilisateur standard ), et +déplacer cette arborescence (hors de question dans ce cas de mettre / +comme racine de l'utilisateur). À noter : j'ai préféré faire le match +sur le nom de l'utilisateur plutôt que sur son groupe (le groupe sera +utilisé par ailleurs). Dans le cas où nous avons plusieurs +utilisateurs, il est possible de les mettre à la suite (séparés par des +virgules). J'ai vu de nombreux tutoriaux qui indiquent comme répertoire +de chroot « /home/%u » (le répertoire de l'utilisateur standard), et qui demandent de changer le répertoire de login de l'utilisateur par « / ». Je pense que c'est une très mauvaise idée : d'une part parce que cela oblige à déposer les clefs à la racine du serveur, mais aussi à cause de @@ -98,9 +97,9 @@ la contrainte d'openssh demandant à ce que le répertoire root soit détenu par root : cela veut dire que l'utilisateur n'a pas le droit de déposer de fichiers ou de créer de répertoires dans son propre home ! Le plus simple est donc de prendre un autre répertoire pour l'échange, et -laisser le home de l'utilisateur pour la configuration. ( Cela permet +laisser le home de l'utilisateur pour la configuration. (Cela permet aussi d'être sûr que le répertoire .ssh ne sera pas effacé par erreur -par l'utilisateur… ) J'ai donc mis un lien symbolique pour lier le /home +par l'utilisateur…) J'ai donc mis un lien symbolique pour lier le /home de l'utilisateur avec son répertoire d'échange : :: @@ -109,8 +108,8 @@ de l'utilisateur avec son répertoire d'échange : # ln -s /var/chroot/home/${user} /home/${user}/echanges On retrouvera ainsi la possibilité de voir les fichiers déposés en -passant par le /home de l'utilisateur ( même si ce dernier ne pourra pas -y aller… ) +passant par le /home de l'utilisateur (même si ce dernier ne pourra pas +y aller…) Isoler l'environnement ~~~~~~~~~~~~~~~~~~~~~~ @@ -118,7 +117,7 @@ Isoler l'environnement Maintenant que nous avons empêché l'utilisateur de se balader sur l'ordinateur, nous allons l'empêcher de se balader dans les autres répertoires des utilisateurs : cela se fait en une ligne de commande -(pour chacun des répertoires que nous allons ouvrir en sftp : ) +(pour chacun des répertoires que nous allons ouvrir en sftp :) :: @@ -131,12 +130,12 @@ Autoriser le partage ~~~~~~~~~~~~~~~~~~~~ Maintenant que nous avons fermé les droits de manière générale il nous -reste à autoriser le partage des fichiers ( après tout c'était le but de +reste à autoriser le partage des fichiers (après tout c'était le but de la demande !) de manière plus fine. Cela implique pour moi deux choses : #. permettre à un autre utilisateur d'accéder aux données présentes -#. permettre à un autre utilisateur de déposer ( ou de supprimer des - donnée ) +#. permettre à un autre utilisateur de déposer (ou de supprimer des + données) Pour le premier point, c'est facile il suffit d'ajouter l'utilisateur A au groupe de l'utilisateur B : @@ -146,12 +145,12 @@ au groupe de l'utilisateur B : # usermod -a -G ${user} ${un_autre_utilisateur} Et l'utilsateur un\_autre\_utilisateur pourra donc accéder à l'ensemble -des fichier pour les lire ( et éventuellement les rapatrier chez lui). -Pour le second point ( possibilité d'écrire et modifier ) c'est un peu +des fichiers pour les lire (et éventuellement les rapatrier chez lui). +Pour le second point (possibilité d'écrire et modifier) c'est un peu plus compliqué; en gros nous voulons que les fichiers déposés par sftp dans le répertoire de l'utilisateur ait comme groupe d'appartenance -celui du propriétaire du répertoire ( quel que soit l'utilisateur qui -dépose ) et qu'ils soient modifiable par le groupe ( g+w ) du +celui du propriétaire du répertoire (quel que soit l'utilisateur qui +dépose) et qu'ils soient modifiable par le groupe (g+w) du propriétaire. Par exemple : l'utilisateur A dépose un fichier dans le répertoire d'échange de l'utilisateur B. Il faut que les droits de ce fichier se présentent ainsi une fois le transfert terminé : @@ -161,11 +160,11 @@ fichier se présentent ainsi une fois le transfert terminé : $ ls -l fichier -rw-rw---- 1 utilisateurA utilisateurB -( ainsi l'un et l'autre pourront supprimer le fichier ). Pour cela nous +(ainsi l'un et l'autre pourront supprimer le fichier). Pour cela nous allons utiliser une « bidouille » de l'os : le sgid bit. Derrière ce nom barbare se trouve un marqueur qui permet de fixer le droit de tous les -fichiers qui seront créés dans le répertoire ( plus d'info -`ici <http://en.wikipedia.org/wiki/Setuid>`_ ). Pour le déterminer on +fichiers qui seront créés dans le répertoire (plus d'info +`ici <http://en.wikipedia.org/wiki/Setuid>`_). Pour le déterminer on passe par chmod : :: @@ -175,20 +174,20 @@ passe par chmod : Cela détermine bien quel est le groupe qui sera propriétaire du fichier, mais cela ne donne pas à ce groupe le droit de le modifier pour autant ! Sous linux, c'est la commande umask qui permet de déterminer les droits -des fichiers. Le problème est qu'il s'agit d'une commande lié à +des fichiers. Le problème est qu'il s'agit d'une commande liés à l'environnement de l'utilisateur, et non pas aux répertoires sur -lesquels nous travaillons ( à moins de passer par les ACLs mais cela est -déjà assez compliqué comme ça… ). Ici, nous sommes dans un environnement +lesquels nous travaillons (à moins de passer par les ACLs mais cela est +déjà assez compliqué comme ça…). Ici, nous sommes dans un environnement sftp, sans shell de login, donc sans possibilité d'exécuter la commande directement, il faut que ce soit le serveur sftp qui le configure. J'ai -trouvé énormément de documentations ( la plupart des bidouillages ) pour +trouvé énormément de documentations (la plupart des bidouillages) pour contourner le problème, mais la solution la plus simple vient de la -dernière version d'OpenSSH (5.4 ) sortie le 8 mars dernier. +dernière version d'OpenSSH (5.4) sortie le 8 mars dernier. |image2| Une nouvelle option sur le serveur sftp permet d'indiquer quel est -l'umask qui sera appliqué ( dans notre cas 002) : dans le +l'umask qui sera appliqué (dans notre cas 002) : dans le fichier/etc/ssh/sshd\_config nous allons configurer les paramètres par défaut du serveur sftp : Remplacer : @@ -204,7 +203,7 @@ par : Pour définir les droits umask qui seront appliqués par défaut pour toutes les connexions sftp par défaut. Ce paramétrage est à redéfinir -pour les paramétrages personnalisés ( bloc Match ) : +pour les paramétrages personnalisés (bloc Match) : :: @@ -214,15 +213,15 @@ Conclusion ~~~~~~~~~~ Nous avons un environnement bien hermétique, pouvant gérer -l'augmentation du nombre de compte ( il suffit de refaire les chmod dans -notre environnement chrooté à la création du compte ), et hermétique. Le +l'augmentation du nombre de compte (il suffit de refaire les chmod dans +notre environnement chrooté à la création du compte), et hermétique. Le paramétrage côté serveur est effectivement assez lourd au début, mais je pense que la mise à jour ne demande pas trop de travail, et on gère les -droits de manière assez fine ( en passant par les groupes ce qui me -semble être dans la mentalité unix ). Pour le client, il n'y a pas grand -chose à paramétrer ( récupérer la clef et l'intégrer ), et il n'y a +droits de manière assez fine (en passant par les groupes ce qui me +semble être dans la mentalité unix). Pour le client, il n'y a pas grand +chose à paramétrer (récupérer la clef et l'intégrer), et il n'y a aucun risque que celui-ci vienne casser son paramétrage. On peut même -sauvegarder sa clef privée dans son home (le vrai ), au cas où il +sauvegarder sa clef privée dans son home (le vrai), au cas où il perdrait le fichier. .. |Création de la clef ssh avec puttygen| image:: |filename|../images/puttygen-300x276.jpg |