Pour moi ces histoires de SELinux inutilisable viennent de préjugés dus au passé.
Pas toutes ces histoires, non. En-dehors de RHEL et dérivées, pas toutes les distros n'utilisent des politiques de sécurité SELinux un peu complètes et à jour... la plupart des distros n'utilisent simplement pas SELinux par défaut, d'ailleurs, ce qui n'aide pas à avoir des politiques convenables.
Tu as résumé le problème : CentOS 6... Le monde a évolué depuis, non ?
Moi, je sais bien que le monde a évolué depuis CentOS 6... mais que veux-tu, installer CentOS 6 est ce qu'on m'a demandé de faire, parce qu'on doit utiliser des packages qui sont testés avec CentOS 6 et non CentOS 7 - alors je dois faire avec CentOS 6, même si je peux indiquer qu'il y aurait mieux à faire ;)
À t'écouter on pourrait croire que les LSM sont inutiles. C'est bien faux...
A une époque, spender s'était amusé à faire une série d'exploits que SELinux n'empêchait absolument pas. J'ai déjà vu des exploits qui commencent par désactiver SELinux et tous les LSMs, peut-être que ceux de spender que je mentionne en font partie. Ceci reste d'actualité, puisque les capacités des LSMs n'ont pas évolué (parce qu'elles ne peuvent pas évoluer) vers plus de protection efficace du kernel.
Pour empêcher de rooter la machine et nuire aux utilisateurs et données (les exploits les plus dangereux, quoi), les LSMs sont beaucoup moins utiles que grsecurity.
Bien sûr, contre les exploits plus simples (LFI, par exemple), si tu interdis à l'application vulnérable de lire /etc/passwd, ça rend l'exfiltration de données un peu plus difficile, mais ce n'est pas ça qu'il faut faire en premier pour la protection de l'intégrité de la machine, à mon sens. Les sponsors de grsecurity, qui sont pour la plupart des fournisseurs d'hébergement, ne s'y trompent pas: ils commencent par utiliser une base saine, et ensuite, ils peuvent construire par-dessus.
[^] # Re: Alternatives
Posté par debrouxl . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 8.
Pas toutes ces histoires, non. En-dehors de RHEL et dérivées, pas toutes les distros n'utilisent des politiques de sécurité SELinux un peu complètes et à jour... la plupart des distros n'utilisent simplement pas SELinux par défaut, d'ailleurs, ce qui n'aide pas à avoir des politiques convenables.
Moi, je sais bien que le monde a évolué depuis CentOS 6... mais que veux-tu, installer CentOS 6 est ce qu'on m'a demandé de faire, parce qu'on doit utiliser des packages qui sont testés avec CentOS 6 et non CentOS 7 - alors je dois faire avec CentOS 6, même si je peux indiquer qu'il y aurait mieux à faire ;)
A une époque, spender s'était amusé à faire une série d'exploits que SELinux n'empêchait absolument pas. J'ai déjà vu des exploits qui commencent par désactiver SELinux et tous les LSMs, peut-être que ceux de spender que je mentionne en font partie. Ceci reste d'actualité, puisque les capacités des LSMs n'ont pas évolué (parce qu'elles ne peuvent pas évoluer) vers plus de protection efficace du kernel.
Pour empêcher de rooter la machine et nuire aux utilisateurs et données (les exploits les plus dangereux, quoi), les LSMs sont beaucoup moins utiles que grsecurity.
Bien sûr, contre les exploits plus simples (LFI, par exemple), si tu interdis à l'application vulnérable de lire /etc/passwd, ça rend l'exfiltration de données un peu plus difficile, mais ce n'est pas ça qu'il faut faire en premier pour la protection de l'intégrité de la machine, à mon sens. Les sponsors de grsecurity, qui sont pour la plupart des fournisseurs d'hébergement, ne s'y trompent pas: ils commencent par utiliser une base saine, et ensuite, ils peuvent construire par-dessus.