Voilà, apres installation de serveur, j'en viens au moment ou je dois decider si je chroot ou pas apache2, mod_php, mysql, et cie.
 
En me documentant sur internet, j'ai été étonné par certains posts sur divers forums qui s'opposaient a ce que j'avais lu dans la plupart des sites parlant de chroot : "Chrootez, comme ca le pirate il ne voit qu'un faux /"
 
et je tombe sur certains posts :
 

 
 
qu'en pensez vous ?

Tout d'abord le fait qu'OpenBSD chroote Apache par défaut n'est pas un signe de danger, c'est juste son rôle. Après tout, cette distro se veut la plus secure au monde, il est donc tout à fait logique qu'elle mette en oeuvre tous les moyens possibles pour protéger ses services à outrance.
 
Ensuite, je pense qu'Apache est déjà suffisemment compliqué à administrer dans certains cas pour qu'on ne s'embarasse pas d'un chroot qui n'est là qu'au cas où une faille serait découverte. Après tout, chroot ou pas, si une faille est découverte dans Apache je serai le premier à couper le mien et à le mettre à jour.
 
Maintenant, j'imagine que dans certains cas l'utilisation d'un chroot ou d'un jail peut se justifier, mais je pense que le choix a déjà été fait par l'ensemble des distros linux : par défaut, apache tourne librement et forke ses childs sous l'user/group spécifié. A l'administrateur d'organiser sa politique de sécu derrière.

à noter qu'il est possible de s'évader d'un chroot
grsec restreint pas mal de choses à ce niveau d'ailleurs (au moins 7 techniques d'évasions restreintes)

C'est pas très difficile de réaliser un chroot et ça empeche à mon avis pas mal d'attaques.
Perso sur mon OpenBSD, apache est chrooté, j'ai crée une cage chroot et tout se passe bien
 
edit: merde ça manque d'arguments, on dirait un troll

Oui hein, j'allais le dire
 
En fait ce qui serait intéressant ce serait que quelqu'un nous présente un exemple concrêt d'attaque réelle qu'il a réussi à bloquer grâce à son chroot, et qui aurait eu des conséquences gravissimes en configuration classique. Ou même l'inverse (attaque non-esquivée par une conf classique, et qu'un chroot aurait pu éviter).
 
Personnellement j'ai fait l'expérience d'un rootkit se propageant par une faille phpBB, et qui avait été placé dans le /tmp d'une de mes machines. Le truc, c'est que ce rootkit n'a jamais eu l'occasion de se déployer puisqu'apache tournait avec des droits restreints (nobody,nogroup). C'est l'exemple-type qui me fait dire qu'un chroot n'est finalement pas si utile que ça, mais je peux bien entendu me tromper

 
comment fais tu pour faire tourner apache avec ces droits ? il va falloir modifier les droits de certains fichiers heberges

Euh.. oui, ça pose un problème ?

 
non, non, je demande juste les explications pour le faire

Et si tu veux qu'Apache forke des childs sous des utilisateurs différents (pour héberger plusieurs personnes sans qu'elles n'interfèrent dans leurs répertoires respectifs) tu as aussi la solution du suexec ou du fastcgi.

Bah déjà, une fois chrooté, le programme ne peut nuire qu'à lui même.
L'execution de code est donc la plupart du temps inutile car ça n'aboutira à rien.
En général y'a pas de /bin/sh, donc ça résoud déjà plein de problèmes de base.
Et le fait que le programme n'ai pas accès au reste du système, ça me semble une excelente méthode de sécurisation
 
Après, j'vois pas trop que dire de plus...

Alors attention, pour compléter ce que dit Deather2, il faut savoir que si l'user sous lequel tourne apache a un shell par défaut, là ça devient dangereux.
Exemple : une machine tournant sur un vieux kernel sensible à la faille ptrace peut se faire rooter sans problème si une faille permet à un type d'exécuter un exploit sous n'importe quel user. Mais bon, tout le monde patche régulièrement son kernel, hein ?