Re,
Il suffit du coup que tu copies tes binaires dans un répertoire du chroot avec un cp et que tu attribues ce répertoire dans les paths. Ça devrait suffir.
Par contre lors de MAJ il faudra penser à recopier tes binaires, mais c’est facilement scriptables ça. Exemple à lancer en root :
[code]#!/bin/bash
bin_dir=’/home/bob/bin’
for i in ${bin_dir}/*
do
cp $(which ${i}) ${bin_dir}
done
[/code]
regarde dans ta conf ssh, c’est à ce niveau la que ton utilisateur se fait Chrooter.
j’ai jamais tenté et eu le besoin de chrooter avec un SU.
ET oui si tu veux quelque chose de plus étanche il te faudra passer par Docker
Désolé je voudrais pas polluer le sujet mais je viens de tomber sur cette discussion et ton message m’intéresse.
Est ce qu’il est possible au même titre de lancer bind9 dans un container plutot que de le chroot-er?
J’utilise bind9 sur mon pc portable perso pour avoir un dns local et ne pas passer par ceux de free ou google ou autre, chrooté selon un tuto que j’avais trouvé sur le wiki il me semble…
Et quels avantages/inconvenients apporterait un container par rapport à un chroot dans ce cas?
Bien entendu sur une machine que j’administre pour un ami j’ai durci et containériser fortement le système.
le couple nsd/unbound sont dans deux dock séparé et communique entre eux sans souci (une fois linké).
Bind9 
Bon, visiblement, chroot ne sert que pour les connexions ssh… si je veux bloquer mon utilisateur dans son chroot, je ne peux le faire que si celui-ci se connecte via ssh (conf sshd_config modifiée). La seule solution consisterait à virer le binaire su de la chroot; et encore, ça ne suffit pas :
Une idée ? Est-ce ici une des limitations de chroot ?
edit: en fait, je pense qu’il s’agit ici d’une simple erreur de raisonnement… chroot fait parfaitement son boulot : dans l’absolu, si je suis amené à utiliser un compte chrooté, je n’ai pas à venir d’un autre compte au préalable… donc passer d’un non chroot à un chroot n’a pas lieu d’être (à part pour des tests, ou maj de librairies/binaires).
Par le fait, la dernière question que je me pose, avant de foncer vers Docker est : Si le service que je fais tourner (ici mon serveur doom) dans mon environnement chroot vient à être compromis de l’extérieur, via un buffer overflow (peu probable, mais admettons…), l’attaquant se retrouvera donc avec les droits de mon utilisateur chrooté.
Ma question est donc la suivante : se retrouvera-t-il chrooté (enfermé dans le chroot) comme dans le contexte d’une connexion ssh, ou pourra-t-il se promener où il veut ? D’après moi, il pourra se promener où il veut vu que l’on sera dans le cadre d’une compromission d’un service autre que ssh, donc non soumis aux contraintes spécifiées dans /etc/ssh/sshd_config.
Ce qui me conforte dans l’idée de passer par Docker, si je dis juste.
Qu’en pensez-vous ?
@Clochette : J’ai trouvé un article qui devrait aussi t’intéresser, concernant chroot et le faux sentiment de sécurité qu’il donne : https://access.redhat.com/blogs/766093/posts/1975883 Bonne lecture, moi je me lance sur Docker 
C’est normal le chroot que tu lance en bash fonctionne dans ce sens :
tty
|_bash
|_chroot
Quand tu quitte ton chroot il revient au bash qui l’a lancé, ça serait pareil si tu lançais un bash avec docker, le docker se killera. Mais tout comme le chroot tout les process attaché seront killé.
Quand tu lance avec un ssh ça donne :
tty
|_ssh
|_chroot
En quittant le chroot le ssh se killé automatiquement car c’est une commande chroot qui est lancé t qui se termine.
Si tu veux utiliser docker avec des connexions ssh je bosse sur un projet dans ce style en ce moment :
Je suis en train de finir les scripts et d’écrire la doc… Je ne sais pas comment fonctionne ton serveur mais je pense que tu peux fortement t’en inspiré. On peut voir ça par échange de MP si tu veux
Bonjour,
en plus de chrooter ton utilisateur Doom, tu peux également, sur ton utilisateur non chrooté, utiliser la commande :
Cela empêchera d’à partir d’un quelconque compte, de remonter jusqu’à la racine /home et d’accéder à ton compte d’administration (chose que j’avais via ssh : d’un compte je pouvais accéder à un autre compte plus “délicat”).
En effet, cela signifie qu’il n’y a que USER qui peut lire / écrire… sur son propre répertoire et qu’aucun membre de GROUPE ni aucun membre de AUTRES y ont accès (en lecture, écriture…).
@Alman : De base, c’est ce que je fais déjà pour tous mes users, sauf erreur d’ailleurs, suivant le degré de configuration de dpkg, il me semble qu’à la conf lors de la mise en place des utilisateurs, on est sollicité pour ça.
Mais ce qui me dérange le plus, quand on sort du contexte de ssh en chroot, c’est que l’user peut se promener où il veut sous / et ainsi augmenter ses droits.
Bon, il faut quand même y aller pour passer root, avec un user normal, une machine à jour, un minimum de services maitrisés et l’absence de compilation possible… mais je me méfie toujours.
@TrashHard : Pour en revenir à Docker, j’ai donc commencé à regarder, j’ai installé le produit et fouillé un peu. Je pense avoir compris l’intérêt de cet outils : pouvoir déployer très facilement un service, sous forme d’image “packageant” toutes les librairies, binaires et fichiers de conf nécessaires indépendamment de l’OS d’origine sur lequel tout a été compilé et l’origine cible sur lequel va être déployé le package.
Si je ne dis pas de bêtise, le principe est de prendre n’importe quel os, d’y mettre le service qu’on veut dessus, de packager l’ensemble, puis de redéployer cet ensemble sous forme d’image docker sur n’importe quelle autre machine, indépendamment de l’OS. C’est bien ça ? Si je m’appuie sur ce tuto, c’est comme ça que je l’ai compris.
Mais ici, si moi je veux faire ma propre image avec mon serveur doom dessus, je fais comment ? Je vais devoir réinstaller une VM vierge, avec une installation Debian minimal, déployer mon serveur doom dessus, supprimer tout ce qui n’est plus utile à l’image (compilation tierce, etc…) et ensuite packager tout ça sous forme d’image, c’est bien ça ?
J’ai l’impression que je vais me retrouver avec l’image d’un OS contenant un service plus qu’une image simple d’un service ? Ai-je mal compris quelque-chose ?
Car pour moi, l’essentiel est étanchéifier le service que je vais proposer… et justement pas de fournir une base de travail avec un OS en cas de compromission.
J’ai l’impression que l’image de base contient l’os de base + le service, le tout enfermé dans un contenair. Ou alors il n’y a que le service (lib+binaires+fichier de confs) dans ce contenair ?
Désolé si je ne suis pas très clair …
Je viens de voir un tuto assez bien fichu pour l’écriture d’un Dockerfile, je vais m’appuyer dessus pour créer mon image avec mon service, et on verra ce qu’il en retourne du contenu de l’image (le package contiendra juste le service ou bien le service + l’OS, le tout packagé ?).
je ne sais pas si c’est à ma question que tu as répondu ou pas?
Parallèlement j’ai fait mes petites investigations sur le net au sujet de docker et bind9, et j’ai compris un peu le fonctionnement de tout ça, il existe même déjà des DockerFile téléchargeables pour construire des containers pour bind9.
Et de ce que j’ai compris (je suis quand même encore un novice dans le domaine) docker est “plus sûr” que de chrooter bind9 par la vieille méthode, corrigez moi si je me trompe.
Par contre ils parlent de lancer le container via la console, mais je voudrais savoir si le/les containers se lancent automatiquement à chaque démarrage/redémarrage du pc et si le service communique avec le reste du système en toute transparence comme s’il était simplement lancé sur l’hôte?
Oui il est tout à fait possible de configurer le démarrage de container au démarrage du serveur.
Il est aussi possible de configurer le redémarrage d’un container après un crash de ce me^me container.
Je te dirais bien d’étudier à la fois docker et les docker file mais aussi l’utilisation de ‘compose’.
Pour une première je serais toi je me ferais mon premier docker file à la main histoire de bien comprendre, car chacun y va de sa petite façon à faire les docker file.
Certains sont pas très propre ou mal adapté à son infra, d’autres sont tout bonnement géniaux et mérite d’être épluché.
Oui je suis entrain de chercher tout ce que je peux trouver déjà sur internet concernant la “containerisation” histoire de bien comprendre en premier lieu ce qu’est un container, comment ça fonctionne et quelle est/sont la/les différence(s) entre une containerisation et un chroot.
Et puis ensuite me pencher comme tu le suggères sur la construction d’un dockerfile car j’aime connaître comment ça fonctionne, d’autant que comme tu le dis chacun fait et propose son dockerfile et bon même si j’imagine que c’est quand même digne de confiance en matière de sécurité je reste suspicieux par nature quand un script, un paquet ou autre provient d’un individu et non de dépôts officiels comme ceux de Debian par exemple lorsqu’on installe un paquet…
Pour éviter de dévier trop ici et flinguer le sujet inital j’ouvrirai mon propre sujet pour d’autres questions, et en tous cas merci pour votre participation. 
EDIT : désolé pour cette parenthèse qui me vient à l’esprit, “compose” fait partie de docker si je comprends bien? si je me trompe corriges moi.
mais j’ouvre cette parenthèse surtout pour savoir ce qu’il faudrait privilégier entre LXC et Docker dans mon cas?
Je t’invite à voir ce que propose le projet Docker : https://docs.docker.com/
Docker compose et swarn sont de merveilleux outils pour ceux qui veulent mettre en place un infrastructure résilante et scalable par exemple.
Je suis déjà entrain d’étudier tout ça, merci
Désolé de revenir encore une fois dans le sujet mais je pense que cette question a plus sa place ici que dans le nouveau sujet dont j’ai parlé de l’ouverture.
Je viens de consulter une partie des éléments dispo sur internet dont le site de docker, et je vois qu’ils conseillent chez eux d’ajouter leur dépôt et d’installer plutôt “docker-engine”, alors que dans les dépôts Debian il existe déjà le paquet “docker.io”
Quelqu’un peut me dire la différence entre les deux si ce n’est simplement une différence de version, et vaut-il mieux installer effectivement le paquet provenant de leur dépôt ou bien on peut se contenter de nos bons vieux dépôts Débian?
Il est préférable d’utiliser leur dépôts pour avoir une version à jour (en tout cas c’est ce que je fais 
sur les machines où je l’installe).
J’ai pris dans les backport me concernant, du coup j’utilise aussi docker-engine. Chez moi en revanche, je n’ai pas trouvé de paquet docker.io dans ma Jessie.
Une astuce pour chercher un paquet :
Depuis un navigateur une recherche avec les mots clé suivants : debian package nom-du-paquet
Par exemple
debian package docker.io
Salut !
Pour compléter le sujet initial, à noter que Jailkit facilite grandement l’administration d’un chroot (cf. http://olivier.sessink.nl/jailkit). J’ai écrit un tuto de présentation de l’outil qui est accessible ici : https://www.cypouz.com/article/150211/chroot-ton-shell-avec-jailkit