Re: Fonctionnement de chroot
On Sat, 24 Jan 2004 13:25:53 +0100
Olive <enchere_email@yahoo.fr> wrote:
> Je souhaite utiliser chroot pour des raisons de sécurité et j'essaye
> donc d'expérimenter cette commande. Cependant je me rends compte que
> cette commande n'est pas très documentée et j'aimerais avoir quelques
> éclaircissement :
>
> 1) Tout d'abord j'ai voulu mettre dans la 'prison' qu'un ls pour faire
> un test. Impossible de le faire marcher sans mettre aussi un /bin/bash,
> est-ce normal ?
ls doit marcher dans un chroot mais pour le lancer il faut bash si tu es
en interactif, si tu fais un programme qui se chroote et lance ls ça marchera
sans bash.
> 2) Y a-t-il une différence fondamentale entre recopier dans la 'prison'
> les exécutables avec les /lib/*.so correspondant ou vaut-il mieux
> recompiler statiquement ?
Le problème est le même que sans chroot, c'est toujours mieux d'en mettre
le moins possible mais en général ce ne sont pas les librairies qui posent
problème (notamment parce qu'il faut être root pour les modifier et que
si une intrusion donne un accès root c'est trop tard)
> 3) Comme indiqué dans :
> http://www.linuxsecurity.com/feature_stories/feature_story-99.html
> Il est fondamental d'éliminer tout notion de 'root' dans la prison, mais
> je ne vois pas bien comment lancer les programmes en tant qu'utilisateur
> ? car dès que je lance chroot il semble que je sois directement devenu
> root dans l'environnement (UID 0)
Plus précisément il est fondamental qu'un utilisateur qui cracke le
programme qui tourne dans le chroot ne puisse pas obtenir un accès root
sinon le chroot ne sert plus à rien. Tu peux laisser des fichiers exécutables
par root uniquement, mais surtout pas de binaire avec le flag suid.
> J'ai essayé -sans succès- d'utiliser le programme setuidgid des
> daemontools pour fixer l'UID du processus que je vais lancer mais
> bizarrement même si j'importe dans la 'prison' /etc/passwd et
> /etc/group, setuidgid persiste à me dire que l'utilisateur n'existe
En général le programme doit tourner en root au départ (par exemple
pour binder une socket < 1024) et change vers un autre user le plus
vite possible.
J'ai un exemple ici:
http://www.floc.net/cgi-bin/viewcvs.cgi/public_scripts/wrapper.c?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup
> pas... De plus le fait même d'avoir setuidgid dans la 'prison' me renvoi
> à la case départ (désolé c'est à force de jouer au Monopoly...) car du
> coup la notion de root peut revenir par la fenêtre (un attaquant peut
> corrompre le setuidgid pour acquérir l'UID 0).
Je ne connais pas setuidgid, si c'est un exécutable suid comme celui de perl
il y a un problème, si c'est un truc que tu lances en root pour abandonner
des privilèges il n'y a pas de risque particulier d'escalade d'une intrusion.
Essaies makejail (package du même nom), en gros il essaie de trouver tous
les fichiers requis par ton programme qui tourne en chroot. Il y a déjà des
fichiers de configuration pour les trucs courants comme apache bind mysql,
environ une dizaine de lignes dont tu peux t'inspirer pour ton cas.
Alain
Reply to: