Si j'ai bien compris, ils l'ont conçu pour que Linux puisse répondre à leurs propres critères d'utilisation de logiciels pour des opérations sensibles, en fonction de contraintes légales qui leurs sont imposées.
Bref, ils sont problablement les utilisateurs qui ont le plus besoin de cette technologie ; il est donc improbable qu'ils aient pris le risque de laisser des trous connus - même cachés. De même qu'ils n'ont surement pas choisi Rijndael pour devenir AES en fonction d'une quelquonque fragilité de l'algorithme, vu qu'ils seront contraints de l'utiliser quotidiennement.
Celà étant dit il faut reconnaitre que les contraintes de la NSA sont assez tortueuse, et (en conséquence ?) SELinux un poil byzantin.
Je suis d'accord avec Sytoka Modon (commentaire ci-dessus) pour privilégier RSBAC lorsque l'administration étasunienne n'est pas votre cible: le code est moins volumineux (potentiellement moins de bugs), le système est beaucoup plus facile à mettre en oeuvre (potentiellement moins d'erreurs d'admin) et surtout, certains composants de SELinux sont affectés par de sombres histoires de brevets logiciels qui font froid dans le dos.
Mais de là à dire que SELinux est une régression en termes de sécurité ....
Quoiqu'il en soit, ces systèmes sont peut-être contraignants et difficiles à mettre en oeuvre dans une distro (mais certaines l'ont fait ...) mais ça n'est pas le cas des options de renforcement à la compilation, comme fstack-protector et fortify ainsi que de certains patches du noyau ! C'est maintenant une responsabilité des mainteneurs de distribution, de contraindre un minimum de protections en les activants pour les binaires qu'ils produisent.
Quand on apprend qu'une majorité (je n'ai plus les chiffres en têtes, peut-être 70%) des failles critiques indéxées par le CERT sont des buffers overflow, précisément, ce que protègent ces outils simples et non intrusifs (dont la mise en oeuvre n'est pas lourde mais doit être faite par ceux qui packagent), on peut trouver irresponsable, pour des mainteneurs de distribution, de les ignorer.
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par herodiade . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 3.
Bref, ils sont problablement les utilisateurs qui ont le plus besoin de cette technologie ; il est donc improbable qu'ils aient pris le risque de laisser des trous connus - même cachés. De même qu'ils n'ont surement pas choisi Rijndael pour devenir AES en fonction d'une quelquonque fragilité de l'algorithme, vu qu'ils seront contraints de l'utiliser quotidiennement.
Celà étant dit il faut reconnaitre que les contraintes de la NSA sont assez tortueuse, et (en conséquence ?) SELinux un poil byzantin.
Je suis d'accord avec Sytoka Modon (commentaire ci-dessus) pour privilégier RSBAC lorsque l'administration étasunienne n'est pas votre cible: le code est moins volumineux (potentiellement moins de bugs), le système est beaucoup plus facile à mettre en oeuvre (potentiellement moins d'erreurs d'admin) et surtout, certains composants de SELinux sont affectés par de sombres histoires de brevets logiciels qui font froid dans le dos.
Mais de là à dire que SELinux est une régression en termes de sécurité ....
Quoiqu'il en soit, ces systèmes sont peut-être contraignants et difficiles à mettre en oeuvre dans une distro (mais certaines l'ont fait ...) mais ça n'est pas le cas des options de renforcement à la compilation, comme fstack-protector et fortify ainsi que de certains patches du noyau ! C'est maintenant une responsabilité des mainteneurs de distribution, de contraindre un minimum de protections en les activants pour les binaires qu'ils produisent.
Quand on apprend qu'une majorité (je n'ai plus les chiffres en têtes, peut-être 70%) des failles critiques indéxées par le CERT sont des buffers overflow, précisément, ce que protègent ces outils simples et non intrusifs (dont la mise en oeuvre n'est pas lourde mais doit être faite par ceux qui packagent), on peut trouver irresponsable, pour des mainteneurs de distribution, de les ignorer.