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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Yves F. Barbier
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.
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.
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
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
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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
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
