[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Inconvénient(s) du chrooting



Romain wrote:
> Salut à tous,
> 
> Je lis souvent ici ou là que le fait de chrooter les services permet de
> diminuer l'impact d'une éventuelle compromission.
> 
> Mais quel(s) est(sont) les inconvénients de cette méthode ?

- seul root a le droit de faire un chroot. donc un programme qu'on n'a
pas du tout envie de lancer en tant que root n'est pas candidat.

- ça complique les choses:
*) beaucoup de gens se marchent dessus en faisant des liens symboliques
"à l'envers", et passent des nuits à pas comprendre le "no such file or
directory" qu'ils voient bien avec un ls, ll, cd, ... etc

*) si le service ne charge pas les libs et autres avant de faire le
chroot, il faut tout lui copier. et si on veut utiliser un gestionnaire
de packages, va falloir le torturer pour qu'il reinstalle des packages
(déjà installés trois fois:) dans la nouvelle cage. Oui, on peut tout
faire à la main, mais il faut aussi patcher à la main en cas de
problèmes... finalement, on se retrouve avec des versions dans la cage
qui ne sont pas mis à jour. le serpent se mordille la queue (leu leu?).

- si deux services ont besoin d'accéder à un fichier commun, et qu'on
veut le chrooter, on va être obligé de les loger dans la même cage. et
s'il y en a plusieurs... A la fin, on perd ce qu'on gagne.

- si le point ci-dessus est rare, on connait tous le pauvre syslog qui
n'en peut plus de lire dans toutes les cages.

- par les temps qui courent, la virtualisation est parfois plus simple
et plus efficace.

...

> Pourquoi Debian par défaut ne chroote pas les "gros" services (Apache,
> SSH, ...)

- pour ssh, beaucoup de gens l'utilisent pour administrer des machines
distantes. et si on le met en cage, autant l'arrêter. mais faut plus
demander comment changer /etc/resolv.conf :{

- pour apache, il faudrait copier tout un tas de trucs, et si en plus on
 utilise php, perl, ..., alors il faut tout copier dans la cage. l'autre
approche est mod_security, mais c'est un peu lourd. Finalement, mieux
vaut lancer apache dans une "machine virtuelle" (xen, vmware, ... etc).


Reply to: