Inconvénient(s) du chrooting

Le
Romain
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 ?
Pourquoi Debian par défaut ne chroote pas les "gros" services (Apache,
SSH, )

Merci

Romain


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Jean-Yves F. Barbier
Le #9632521
Romain a écrit :
...
Mais quel(s) est(sont) les inconvénients de cette méthode ?



Recréer une partie (ou tout) de l'arborescence Linux, plus ou moins rem plie
(++libs) et surveiller chaque MàJ du système central afin qu'une év olution
de ces libs soit MàJ également; mais aussi et surtout la possibilité de
prendre le contrôle du chroot par des attaques très diverses, dont de très
sophistiquées sur la mémoire partagée (etc etc) en n'étant pas ro ot.

Et donc de finir par prendre le contrôle du système central, le chroo t
étant souvent sa copie conforme par paresse ou ignorance; et parce que de
toute façon, si l'attaquant a réussi une fois, il-y-a 90% de chance q u'il
réussisse une 2nde.

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



sans doute pour les raisons sus-mentionnées et d'autres encore.

[++supputation] Etant donné que Debian s'est taillée en grande partie sa
réputation par son orientation stabilité/sécurité, si l'intérê t avait été réel
& significatif, le staff aurait sans doute utilisé chroot par défaut.

[--supputation] Debian c'est la liberté et l'admin est tout puissant; d onc
il fait ses propres choix en fonction de ses besoins, de son expérience et
de la variation du coefficient de flexibilité des câbles réseau eth ernet.

--
Shit Happens.
mouss
Le #9632511
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).


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme