Pour grsec, "patch de test" n'est pas un synonyme de "patch particulièrement instable" :)
Sur plusieurs machines depuis plus d'un an, je n'ai jamais utilisé un des patches stables parce qu'ils ciblent des versions trop vieilles du kernel... et je n'ai eu qu'un problème, qui était circonscrit à peu de modèles de serveur Dell, dont celui que j'ai, et a été rapidement corrigé.
Il n'y a aucune alternative à PaX/grsecurity, qui s'occupent (puissamment) d'anti-exploitation du kernel.
Tout ce dont SELinux / AppArmor et autres frameworks de policy s'occupent, c'est de veiller à ce que les applications ne fassent pas autre chose que ce qui est défini dans la politique de sécurité... mais ils ne durcissent en rien le kernel.
La plupart des PoCs pour les exploits significatifs du kernel Linux (privesc, souvent), tels qu'ils sont publiés, sont arrêtés par plusieurs protections de PaX/grsecurity. En général, quand un tel exploit et son PoC sont mentionnés sur LWN, spender liste les protections impliquées, le plus souvent:
* UDEREF (sur-ensemble strict du SMAP des tout derniers processeurs Intel): empêcher le kernel de lire les structures ops directement en userspace;
* KERNEXEC (sur-ensemble du SMEP des derniers processeurs Intel): empêcher le kernel d'exécuter directement le payload en userspace (soupir...), dont l'adresse a été lue à cause de l'absence d'UDEREF sur mainline;
* RANDSTRUCT: réordonner les champs d'un certain nombre de structures du kernel, pour que les exploits binaires précompilés fassent en général un DoS - et il est difficile de recompiler à la volée une version adaptée au kernel, parce que le layout est difficile à déterminer de l'extérieur;
* une quatrième qui m'échappe à l'instant.
En pratique, la plupart des utilisateurs désactivent SELinux parce que c'est juste trop pénible à l'usage: problèmes de compatibilité dus à une politique de sécurité incomplète ou trop restrictive.
L'autre jour, j'ai dû installer CentOS 6 (soupir de devoir se coller des versions obsolètes de ce genre...) dans une VM avec un hyperviseur propriétaire. Out of the box, la VM ne bootait même pas si je ne désactivais pas SELinux - ce n'est pas une blague !
Bref, je ne peux que te conseiller de continuer avec grsec (et donc, le patch de test, comme moi), parce que c'est ça qui fait une sécurité vraiment améliorée, et non les frameworks de policy qui ne protègent pas des exploits du kernel et ne présentent aucune difficulté réelle pour les agences gouvernementales.
[^] # Re: Alternatives
Posté par debrouxl . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 8.
Pour grsec, "patch de test" n'est pas un synonyme de "patch particulièrement instable" :)
Sur plusieurs machines depuis plus d'un an, je n'ai jamais utilisé un des patches stables parce qu'ils ciblent des versions trop vieilles du kernel... et je n'ai eu qu'un problème, qui était circonscrit à peu de modèles de serveur Dell, dont celui que j'ai, et a été rapidement corrigé.
Il n'y a aucune alternative à PaX/grsecurity, qui s'occupent (puissamment) d'anti-exploitation du kernel.
Tout ce dont SELinux / AppArmor et autres frameworks de policy s'occupent, c'est de veiller à ce que les applications ne fassent pas autre chose que ce qui est défini dans la politique de sécurité... mais ils ne durcissent en rien le kernel.
La plupart des PoCs pour les exploits significatifs du kernel Linux (privesc, souvent), tels qu'ils sont publiés, sont arrêtés par plusieurs protections de PaX/grsecurity. En général, quand un tel exploit et son PoC sont mentionnés sur LWN, spender liste les protections impliquées, le plus souvent:
* UDEREF (sur-ensemble strict du SMAP des tout derniers processeurs Intel): empêcher le kernel de lire les structures ops directement en userspace;
* KERNEXEC (sur-ensemble du SMEP des derniers processeurs Intel): empêcher le kernel d'exécuter directement le payload en userspace (soupir...), dont l'adresse a été lue à cause de l'absence d'UDEREF sur mainline;
* RANDSTRUCT: réordonner les champs d'un certain nombre de structures du kernel, pour que les exploits binaires précompilés fassent en général un DoS - et il est difficile de recompiler à la volée une version adaptée au kernel, parce que le layout est difficile à déterminer de l'extérieur;
* une quatrième qui m'échappe à l'instant.
En pratique, la plupart des utilisateurs désactivent SELinux parce que c'est juste trop pénible à l'usage: problèmes de compatibilité dus à une politique de sécurité incomplète ou trop restrictive.
L'autre jour, j'ai dû installer CentOS 6 (soupir de devoir se coller des versions obsolètes de ce genre...) dans une VM avec un hyperviseur propriétaire. Out of the box, la VM ne bootait même pas si je ne désactivais pas SELinux - ce n'est pas une blague !
Bref, je ne peux que te conseiller de continuer avec grsec (et donc, le patch de test, comme moi), parce que c'est ça qui fait une sécurité vraiment améliorée, et non les frameworks de policy qui ne protègent pas des exploits du kernel et ne présentent aucune difficulté réelle pour les agences gouvernementales.