Comment et quel chroot réaliser pour ce que je veux faire ?

Support Debian
#1

Hello,

J’ai créé il y a peu sous ma debian (jessie) un serveur multi pour le jeu Doom, ça fonctionne au poile, j’ai un utilisateur dédié pour ce petit service, mon serveur est globalement bien sécurisé, mais j’aimerais aller plus loin : Chrooter mon utilisateur “doom” dans sa home, faire en sorte qu’il ne puisse surtout pas en sortir !

J’ai lu quelques docs sur le sujet, mais j’ai l’impression qu’à chaque fois, c’est un système quasi complet qui est réinstallé dans le chroot… du coup je me dis, quel est l’intérêt ? Ok, on isole du chroot le reste du “vrai” système, ceci dit, si le chroot est compromis, il reste possible d’y faire des saletés dedans (ou même simplement s’en servir d’un rebond pour aller faire de la memerde sur une véritable cible, en prenant notre identité).

Bref, tout ce que je veux moi, c’est que mon utilisateur doom :

  • ne puisse en aucun cas sortir de sa home
  • ne puisse rien lancer d’autre que des choses basiques comme le serveur doom, mais aussi vi, touch, etc… et lui dégager le client ssh, telnet, netcat & cie.

Pourriez-vous m’orienter ou m’expliquer comment faire svp ?

Merci !

#2

Bonjour,

Pour ma part j’utilise le Chroot via ssh avec un environnement personnalisé et certains binaires dédiés au Chroot.

Pour le faire je me base sur un vieux script (qui fonctionne encore du tonnerre :slight_smile:) -> http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/

Concrètement, il va recréer l’arborescence classique dans le home de ton utilisateur (/etc, /bin …) avec une copie des lib et binaires que tu lui aura autorisé (regarde à la ligne 124 du script). C’est à dire que si tu ne veux pas mettre la commande rm ou toutes autres à dispo dans le Chroot tu peux.

Tu va ainsi pouvoir créer un environnement bridé, sur lequel l’utilisateur Chrooté ne pourra que se nuire à lui même. Et biensur à condition de ne pas lui mettre à disposition certaine commande lui permettant de s’évader du Chroot (MAKEDEV, mount, Gcc … Google est ton ami).

Ensuite j’empêche aussi l’utilisateur de lancer plus de 10 process pour éviter les fork bomb, pour cela je passe par le fichier de conf :
/etc/security/limits.conf

Cette solution devrais donc répondre à ton besoin. Toutefois n’oublie pas que rien n’est infaillible. Donc ne laisse pas n’importe qui accéder au compte Chrooté.

#3

Hello,

Pourquoi tu pars pas plutôt sur une solution de containers ?

Merci,

#4

Hello,

@Vanson :

J’avais déjà tenté un truc dans l’après midi avec ce script, mais il tombe en erreur (sachant que j’ai fait les modifications suggérées aux lignes 406/407) :

Adding User test_chroot to jail
Copying necessary library-files to jail (may take some time)
cp: cannot stat ‘/lib/libnss_compat.so.2’: No such file or directory
cp: cannot stat ‘/lib/libnsl.so.1’: No such file or directory
cp: cannot stat ‘/lib/libnss_files.so.2’: No such file or directory
cp: cannot stat ‘/lib/libcap.so.1’: No such file or directory
cp: cannot stat ‘/lib/libnss_dns.so.2’: No such file or directory
Copying files from /etc/pam.d/ to jail
Copying PAM-Modules to jail
cp: cannot stat ‘/lib/security’: No such file or directory

Une idée du problème ?

edit: problème corrigé par l’application de cette solution : http://stackoverflow.com/questions/30503567/chroot-ssh-on-debian-8

voici la fin de la sortie :

Not creating new User account
Modifying User "test_chroot"
Copying files in test_chroot’s $HOME to “/test//home/test_chroot”

Adding User test_chroot to jail
Copying necessary library-files to jail (may take some time)
Copying files from /etc/pam.d/ to jail
Copying PAM-Modules to jail

Mais le chroot ne fonctionne pas, je peux toujours me promener où je veux avec mon user :frowning:

edit2: En fait, si ça fonctionne, encore faut-il modifier le sshd_config pour y chrooter notre pote, ça va mieux… quand on est une buse, hein.

edit3: C’est le dernier, promis… j’ai pigé ce qui me gênait : quand je me connecte en ssh, ça fonctionne, mais si je viens d’un autre user vers mon test_chroot, je peux me promener comme je veux où je veux. En gros, dès que je sors du contexte ssh, je peux aller où je veux et ça me gêne beaucoup car je veux pouvoir enfermer mon user en local ! Je m’explique, si le service que je distribue est victime de remote buffer overflow, le bonhomme se retrouve avec les droits de mon user, sur ma machine et peut donc potentiellement passer de la commande… reste pour lui qu’à élever ses droits. Moi, je veux qu’il reste enfermer dans sa home, point barre.
Est-ce que je dois faire une modif au niveau de pam aussi ?

@TrashHard :

Qu’entends-tu par contenairs ? Des machines virtuelles ? Si oui, c’esy déjà le cas en fait. Là je suis sur une VM paravirtualisée Xen, mais d’un point de vue sécurité, cette forme de contenair ne fait pas tout, je veux vraiment isoler hermétiquement mon utilisateur à son seul et unique répertoire, ayant accès aux binaires que je lui autorise et rien d’autre.

Merci pour vos réponses :slight_smile:

#5

Non les containers ne sont pas des VM, il s’agit d’une virtualisation de processus. Dans le cas de docker par exemple, qui utilise LXC, on définis une images systèmes avec tout ce que tu veux dedans, et ensuite et lance un container une ou plusieurs fois. Ça permet de sécurisé totalement ton OS car dans le cas où un utilisateur atteint le système et passe root ça ne sert à rien, les modifications systèmes ne sont pas enregistrées et il suffit de relancer un container et tu as un système tout neuf.

C’est beaucoup plus sécurisant qu’un chroot, il existe beaucoup de méthode pour s’exit d’un chroot ou tout simplement de faire un brutforce sans que personne le vois si mount en bind les binaires et que tu laisse su, sudo ou des binaire qui utilisent du sticky bit

#6

Je vais me pencher là-dessus dans ce cas. Je vais déjà régler mon problème avec chroot (juste histoire d’aller au bout de mon raisonnement et comprendre pourquoi la chroot marche en ssh, mais pas en local d’un su à un autre) et je regarderai docker, ça me plait bien !

#7

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]

#8

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

#9

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?

#10

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 :kissing_cat:

#11

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 :

  1. Je me connecte en SSH sur un autre compte (non chrooté)
  2. Je fais un su depuis ce compte sur mon compte chroot
  3. Je me retrouve bien dans ma home chrooté, mais si je veux sortir de celle-ci, je peux…

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).

#12

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 :slight_smile:

#13

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

#14

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…).

#15

@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 …

#16

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é ?).

#17

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?

#18

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é.

#19

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. :wink:

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?

#20

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.