Et toujours d'après son texte il n'y a pas "une faille de sécurité" à corriger : il y en a des tonnes.
Selon Brad, il n'existe que deux options : aucune zéro ou GRSecurity. Ce raisonnement ne se tient pas. Il y a de bonnes raisons de pas utiliser GRsecurity : l'énorme patch est très intrusif et n'est pas intégré upstream. En conséquence, GRsecurity n'est pas utilisable directement sur RHEL, Debian ou OpenSuse. Quand des bugs sont corrigés, les distributions Linux fournissent des correctifs. Avec GRsecurity, il faut mettre à jour le noyau soit même, c'est très délicat. Bien sûr, il existe des personnes qui utilisent GRsecurity et sûrement des paquets tout prêt, mais c'est différent du point de vue de la responsabilité que d'utiliser des paquets fournis par une distribution Linux.
L'attitude de Brad n'est pas constructive. Les développeurs noyau ne veulent pas de son patch, car personne n'est capable de dire de relire son patch et parce qu'il tue les performances.
Je pense qu'il existe un juste milieu entre GRsecurity (lent mais sûr) et aucune sécurité. Comme je l'ai dit, les améliorations liées à la sécurité prises indépendemment ne sont pas efficaces, mais mises bout à bout, ça devient complexe d'écrire un exploit noyau.
[^] # Re: Sécurité: Contournement de kASLR par Brad Spengler (grsecurity)
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de Linux 3.14. Évalué à 7.
Et toujours d'après son texte il n'y a pas "une faille de sécurité" à corriger : il y en a des tonnes.
Selon Brad, il n'existe que deux options : aucune zéro ou GRSecurity. Ce raisonnement ne se tient pas. Il y a de bonnes raisons de pas utiliser GRsecurity : l'énorme patch est très intrusif et n'est pas intégré upstream. En conséquence, GRsecurity n'est pas utilisable directement sur RHEL, Debian ou OpenSuse. Quand des bugs sont corrigés, les distributions Linux fournissent des correctifs. Avec GRsecurity, il faut mettre à jour le noyau soit même, c'est très délicat. Bien sûr, il existe des personnes qui utilisent GRsecurity et sûrement des paquets tout prêt, mais c'est différent du point de vue de la responsabilité que d'utiliser des paquets fournis par une distribution Linux.
L'attitude de Brad n'est pas constructive. Les développeurs noyau ne veulent pas de son patch, car personne n'est capable de dire de relire son patch et parce qu'il tue les performances.
Je pense qu'il existe un juste milieu entre GRsecurity (lent mais sûr) et aucune sécurité. Comme je l'ai dit, les améliorations liées à la sécurité prises indépendemment ne sont pas efficaces, mais mises bout à bout, ça devient complexe d'écrire un exploit noyau.