On Sat, 24 Jan 2004 13:25:53 +0100 Olive <[EMAIL PROTECTED]> 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