> sshd utilse chroot
Il utilise chroot comme proftpd utilise chroot. Le serveur n'est pas toujours chrooté, il n'y a pas une arborescense spécifique pour lui (/lib/libc.so, /etc/passwd, etc...).
Si tu as pleins de services chrootés il te faut plein de libc etc... pour chaque chroot. çà bouffe de la mémoire et pose des problèmes pour mettre à jour la librairie C et autre qui sont utilisés par les programmes chrootés (faut pas oublier de mettre à jour une librairie C etc...).
Afin si (par exemple) apache est chrooté comment tu fais pour utiliser des scripts perl en cgi, etc... Tu fais une installe de perl dans le répertoire chroot d'Apache ? Comment tu fais pour utiliser la directive user_dir d'apache si apache est chrooté ? Tu copies /etc/passwd et consort dans le répertoire chrooté d'Apache ? Pour qu'Apache supporte user_dir il doit être root ou pouvoir utiliser un programme avec suid comme suexec. Imagine que ta partition racine soit /dev/hda1. S'il y a un trou de sécurté dans suexec et que tu l'exploites, tu peux faire un "mount /dev/hda1 /quelque_part" après avoir déposé un programme sur le serveur et tu perds tout l'intérêt de chroot. Si tes scrips cgi utilisent d'autres programmes il faut aussi les copier dans le répertoire chrooté etc, etc, etc... Et plein de problème pour maintenir ta bécane et donc des risques d'erreur humain (qui est certainement la première cause de perte de donnée, de temps etc...).
bind chrooté : pourquoi pas. Mais Apache chrooté : bof. Si quelqu'un gagne les droits du compte named ou apache, çà va pas bien loin... A moins que ta bécane soit mal installée...
openbsd avec leur obsession de la sécurité va finir par chrooté X ... Mieu encore a la création d'un compte, il font une installation complète d'openbsd dans /home/toto puis lorsque tu te loggue tu es chrooté dans /home/toto.
Franchement cette paranoïa est ridicule. Les plus gros problèmes de sécurité c'est pas si tel ou tel programme utilise chroot. C'est la configuration des services (erreur humaine) et la non maintenance des bécanes (non application des correctifs).
[^] # Re: Un nouveau serveur DNS libre : PowerDNS
Posté par matiasf . En réponse à la dépêche Un nouveau serveur DNS libre : PowerDNS. Évalué à 1.
Il utilise chroot comme proftpd utilise chroot. Le serveur n'est pas toujours chrooté, il n'y a pas une arborescense spécifique pour lui (/lib/libc.so, /etc/passwd, etc...).
Si tu as pleins de services chrootés il te faut plein de libc etc... pour chaque chroot. çà bouffe de la mémoire et pose des problèmes pour mettre à jour la librairie C et autre qui sont utilisés par les programmes chrootés (faut pas oublier de mettre à jour une librairie C etc...).
Afin si (par exemple) apache est chrooté comment tu fais pour utiliser des scripts perl en cgi, etc... Tu fais une installe de perl dans le répertoire chroot d'Apache ? Comment tu fais pour utiliser la directive user_dir d'apache si apache est chrooté ? Tu copies /etc/passwd et consort dans le répertoire chrooté d'Apache ? Pour qu'Apache supporte user_dir il doit être root ou pouvoir utiliser un programme avec suid comme suexec. Imagine que ta partition racine soit /dev/hda1. S'il y a un trou de sécurté dans suexec et que tu l'exploites, tu peux faire un "mount /dev/hda1 /quelque_part" après avoir déposé un programme sur le serveur et tu perds tout l'intérêt de chroot. Si tes scrips cgi utilisent d'autres programmes il faut aussi les copier dans le répertoire chrooté etc, etc, etc... Et plein de problème pour maintenir ta bécane et donc des risques d'erreur humain (qui est certainement la première cause de perte de donnée, de temps etc...).
bind chrooté : pourquoi pas. Mais Apache chrooté : bof. Si quelqu'un gagne les droits du compte named ou apache, çà va pas bien loin... A moins que ta bécane soit mal installée...
openbsd avec leur obsession de la sécurité va finir par chrooté X ... Mieu encore a la création d'un compte, il font une installation complète d'openbsd dans /home/toto puis lorsque tu te loggue tu es chrooté dans /home/toto.
Franchement cette paranoïa est ridicule. Les plus gros problèmes de sécurité c'est pas si tel ou tel programme utilise chroot. C'est la configuration des services (erreur humaine) et la non maintenance des bécanes (non application des correctifs).