Parce que chroot n'est pas prévu pour la sécurité, c'est juste pour changer 1 flag sur le process. Donc je pense que changer la sémantique n'est pas terrible ( en plus de casser posix ). Il suffit de voir le changement sur les hardlinks dans /tmp, qui est activé par défaut sur Ubuntu, Debian wheezy et partout systemd se trouve depuis 2/3 versions ( ie depuis 1/2 mois ). mais toujours bloqué upstream, car 1 personne a eu un souci le jour de la sortie du 3.8.
( et même si c'est pas prévu pour la sécurité, chroot aide un peu, ça dépend de la menace ( genre un verre automatisé qui dépend de ls pour se lancer, il va avoir plus de mal ), mais ça reste pas non plus utile face à un attaquant plus sophistiqué ).
Quand à lxc, il y a des travaux sur ça, cf les liens que j'ai donné pour d'une part, du coté de Canonical, poussé à l'usage d'apparmor avec l'userspace de lxc, et du coté de Red hat, l'usage de selinux avec les namespaces ( donc lxc ), notament virt-sandbox-service, systemd aussi un peu, et tout le travail fait pour openshift.
Freebsd a jail pour remplacer ça, solaris a les zones, etc, etc.
Et le kernel Linux reste super compliqué, et quand tu regardes tout ce que tu peux faire avec les capabilities http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 , tu vois que rajouter plus de complexité n'aide pas vraiment.
Une des solutions, ça aurait été de merger grsec ( qui propose un chroot comme celui d'openbsd ), mais Linus n'a pas envie d'arbitrer ( et je le comprends ) des disputes entre les psychopathes moyens que le monde de la sécurité héberge, et je pense donc qu'il y a juste eu une mauvaise volonté des 2 cotés.
une autre, c’était de merger openvz ce qui arrive par petit bout. Quand à vserver, je pense que les devs upstreams rentrent dans la catégorie "mecs opiniatres avec qui je voudrait pas bosser" ( en tout cas, les 2 avec qui j'ai interagi ), donc ça doit être le même genre de souci que pour grsec.
[^] # Re: Séparation par utilisateurs/groupes ?
Posté par Misc (site web personnel) . En réponse au journal Fin des RPS et choix cornélien. Évalué à 5.
Parce que chroot n'est pas prévu pour la sécurité, c'est juste pour changer 1 flag sur le process. Donc je pense que changer la sémantique n'est pas terrible ( en plus de casser posix ). Il suffit de voir le changement sur les hardlinks dans /tmp, qui est activé par défaut sur Ubuntu, Debian wheezy et partout systemd se trouve depuis 2/3 versions ( ie depuis 1/2 mois ). mais toujours bloqué upstream, car 1 personne a eu un souci le jour de la sortie du 3.8.
( et même si c'est pas prévu pour la sécurité, chroot aide un peu, ça dépend de la menace ( genre un verre automatisé qui dépend de ls pour se lancer, il va avoir plus de mal ), mais ça reste pas non plus utile face à un attaquant plus sophistiqué ).
Quand à lxc, il y a des travaux sur ça, cf les liens que j'ai donné pour d'une part, du coté de Canonical, poussé à l'usage d'apparmor avec l'userspace de lxc, et du coté de Red hat, l'usage de selinux avec les namespaces ( donc lxc ), notament virt-sandbox-service, systemd aussi un peu, et tout le travail fait pour openshift.
Freebsd a jail pour remplacer ça, solaris a les zones, etc, etc.
Et le kernel Linux reste super compliqué, et quand tu regardes tout ce que tu peux faire avec les capabilities
http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 , tu vois que rajouter plus de complexité n'aide pas vraiment.
Une des solutions, ça aurait été de merger grsec ( qui propose un chroot comme celui d'openbsd ), mais Linus n'a pas envie d'arbitrer ( et je le comprends ) des disputes entre les psychopathes moyens que le monde de la sécurité héberge, et je pense donc qu'il y a juste eu une mauvaise volonté des 2 cotés.
une autre, c’était de merger openvz ce qui arrive par petit bout. Quand à vserver, je pense que les devs upstreams rentrent dans la catégorie "mecs opiniatres avec qui je voudrait pas bosser" ( en tout cas, les 2 avec qui j'ai interagi ), donc ça doit être le même genre de souci que pour grsec.