> Chroot renforcé car trop permissif par defaut (en gros qui laisse s'échapper les occupants)
Vraisemblablement pour ne pas casser le comportement standard de chroot(2), lequel est défini précisément par POSIX.1-2001.
En l'occurrence, les "problèmes" de chroot visés par grsecurity, ce n'est pas qu'il "laisse s'échapper les occupants", mais qu'il n'isole un processus du reste qu'au niveau du système de fichier, et c'est tout (les IPC fonctionnement normalement, les fd hérités restent ouverts, ...). Mais c'est ce pour quoi il a été conçu, on n'a pas menti sur la marchandise.
Chroot n'était pas prévu pour être utilisé comme un mécanisme de sécurité (cf. [http://lwn.net/Articles/252794/]), encore moins comme mécanisme d'isolation totale (à part pour le système de fichier). Des solutions parallèles sont cependant en cours de développement et intégration dans Linux (autour de la virtualisation et des espaces de nommages multiples et séparés pour les processus, par ex.) ; elles ont le mérite de présenter une architecture d'ensemble et cohérente, et de ne pas casser un appel système standard, existant et déjà largement utilisé par des milliers de logiciels.
> Cacher les process du noyau
C'est plutôt "cacher certains processus à d'autres processus". Tel que proposé par grsecurity, ce n'est pas une chose très simple (ou très saine) à intégrer dans le desktop de monsieur tout le monde. Là encore, il faut veiller à ne pas casser les standards ou l'existant. Et là encore, la virtualisation et la ségrégation de plusieurs espaces de nommages pour les processus (enfin pour le moment, seulement les pids) est une solution plus générale et en cours d'adoption.
> Logs beaucoup plus 'verbose' sur les actions des users
Là je ne sait pas trop de quoi tu parle. L'accounting BSD ne remplis pas cette fonction ?
> Protection de la pile
Si mes souvenirs sont bons, le patchset grsecurity+pax s'était vu rejeté, lorsqu'ils ont demandé l'intégration dans le noyau, notamment parce que les mécanismes de protection de pax divisaient par deux l'espace mémoire adressable par un processus donné, merci la belle régression (je dit ça de mémoire hein, c'est peut être "divisaient en quatre" ou quelque chose similaire, mais c'était bien un problème de ce type). Ce qui casse le fonctionnement d'un paquet d'applis en situation "enterprise", notamment celles qui font vendre du redhat/oracle.
Ce n'est pas la seule raison du refus, je me souvient que d'autres problèmes sans rapport direct avec la protection de la pile ont été soulevés sur lkml à l'époque (non utilisation de LSM, développeur principal qui refuse l'intégration d'une partie de son patchset parce que "la sécu c'est tout ou rien", et qui se montre odieux et borné comme seuls les dévs sécu noyau savent l'être (à la hauteur des devs SELinux ou de Theo de Raadt), ...).
[^] # Re: Pourquoi une option ?
Posté par herodiade . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 9.
Vraisemblablement pour ne pas casser le comportement standard de chroot(2), lequel est défini précisément par POSIX.1-2001.
En l'occurrence, les "problèmes" de chroot visés par grsecurity, ce n'est pas qu'il "laisse s'échapper les occupants", mais qu'il n'isole un processus du reste qu'au niveau du système de fichier, et c'est tout (les IPC fonctionnement normalement, les fd hérités restent ouverts, ...). Mais c'est ce pour quoi il a été conçu, on n'a pas menti sur la marchandise.
Chroot n'était pas prévu pour être utilisé comme un mécanisme de sécurité (cf. [http://lwn.net/Articles/252794/]), encore moins comme mécanisme d'isolation totale (à part pour le système de fichier). Des solutions parallèles sont cependant en cours de développement et intégration dans Linux (autour de la virtualisation et des espaces de nommages multiples et séparés pour les processus, par ex.) ; elles ont le mérite de présenter une architecture d'ensemble et cohérente, et de ne pas casser un appel système standard, existant et déjà largement utilisé par des milliers de logiciels.
> Cacher les process du noyau
C'est plutôt "cacher certains processus à d'autres processus". Tel que proposé par grsecurity, ce n'est pas une chose très simple (ou très saine) à intégrer dans le desktop de monsieur tout le monde. Là encore, il faut veiller à ne pas casser les standards ou l'existant. Et là encore, la virtualisation et la ségrégation de plusieurs espaces de nommages pour les processus (enfin pour le moment, seulement les pids) est une solution plus générale et en cours d'adoption.
> Logs beaucoup plus 'verbose' sur les actions des users
Là je ne sait pas trop de quoi tu parle. L'accounting BSD ne remplis pas cette fonction ?
> Protection de la pile
Si mes souvenirs sont bons, le patchset grsecurity+pax s'était vu rejeté, lorsqu'ils ont demandé l'intégration dans le noyau, notamment parce que les mécanismes de protection de pax divisaient par deux l'espace mémoire adressable par un processus donné, merci la belle régression (je dit ça de mémoire hein, c'est peut être "divisaient en quatre" ou quelque chose similaire, mais c'était bien un problème de ce type). Ce qui casse le fonctionnement d'un paquet d'applis en situation "enterprise", notamment celles qui font vendre du redhat/oracle.
Ce n'est pas la seule raison du refus, je me souvient que d'autres problèmes sans rapport direct avec la protection de la pile ont été soulevés sur lkml à l'époque (non utilisation de LSM, développeur principal qui refuse l'intégration d'une partie de son patchset parce que "la sécu c'est tout ou rien", et qui se montre odieux et borné comme seuls les dévs sécu noyau savent l'être (à la hauteur des devs SELinux ou de Theo de Raadt), ...).