Ce n'est pas correct de lire dans mes posts des choses que je n'écris pas, aussi bien sur l'inutilité de SELinux que sur l'invulnérabilité de grsec - des choses que je n'écris pas parce qu'il serait faux de les écrire ;)
De plus, toi et moi sommes d'accord sur certains points: j'ai précisément écrit, dans un autre post de ce thread, "on peut utiliser les frameworks de policy basés sur LSM en plus de grsecurity". Même si apparemment, nous ne mettons pas la même priorité sur les élements.
Bref… on arrête longtemps avant que la modération nous signifie qu'on devrait le faire parce qu'on tourne en rond ?
Comme je l'ai signalé dans ce post-là, PaXTeam et spender préfèrent en effet se concentrer sur la réalisation des features utiles pour la minorité d'utilisateurs qui connaissent et croient réellement en leur travail, plutôt que sur l'intégration à mainline, suite à une revue de code par des gens moins compétents en sécurité qu'eux, qui leur imposent de passer du temps à dégrader ce qu'ils ont fait (en imposant des interfaces inadaptées, en refusant les plugins GCC, et j'en passe).
J'ai du mal à leur donner complètement tort, tout comme j'ai du mal à donner complètement tort à leurs trop nombreux détracteurs :)
Il n'y a toujours pas de réponse à la question que je posais dans ce post, et que je ne suis évidemment pas le seul à poser: "What to do to meaningfully improve end user security of Linux ?" (for most users on a day to day basis, je rajoute maintenant pour être plus explicite)
S'il y avait une initiative un peu coordonnée de déplacement des morceaux de cleanup non controversiaux que j'ai listés dans un autre post ici depuis PaX/grsecurity vers mainline, j'essaierais de participer, à mon petit niveau, comme je l'avais fait pour quelques patches de constification en 2011 (suite à une autre discussion LWN où j'avais joué l'andouille), peu avant que la constification soit réécrite avec le plugin GCC.
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.
Mathias Krause (minipli) rentre aussi quelques patches de temps en temps.
Des centaines de hunks de PaX/grsecurity sont de purs cleanups, certains n'améliorant même pas explicitement la sécurité, et ne font l'objet d'aucune controverse pour les pousser vers mainline. Un des exemples qui revient le plus souvent est la constification des structures ops. Une très grosse série de patches de constification avait été poussée vers mainline par Emese Revfy (ephox), et peu de développeurs avaient intégré les modifs de constification…
On peut également citer quelques dizaines de structures locales qui prennent de la place sur la pile et du temps d'exécution alors qu'elles pourraient être static (et souvent const), ou a contrario, quelques variables static pour lesquelles ce static n'a aucun intérêt puisque la première chose que fait la fonction qui les déclare est d'écraser leur valeur.
Nombre de ces hunks sont présents depuis des années, inchangés. L'incitation à les pousser vers upstream est faible, puisque le fait de faire une soumission prend du temps, et comme je l'ai mentionné plus haut, le taux d'intégration de ces patches a déjà été montré comme bas.
Un point de ton post ne me paraît pas techniquement correct: on peut utiliser les frameworks de policy basés sur LSM en plus de grsecurity: https://grsecurity.net/compare.php
A moins que tu veuilles dire par "incompatible avec LSM" que mainline insiste absolument pour que grsecurity passe par les fourches caudines de LSM, alors que spender explique depuis des années ( https://grsecurity.net/lsm.php ) que c'est parfaitement inadapté parce que LSM est très loin d'être assez puissant ? C'est hélas un fait que "c'est pas un LSM" est une des objections qui ont été formulées contre l'inclusion de grsec dans mainline - peu importe le fait que ça réduise énormément la puissance de la solution.
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.
Les HW1 n'ont pas que des défauts: par exemple, le grayscale est moins coûteux sur HW1 que sur HW2, et les HW1 n'ont pas cette foutue protection d'exécution en RAM :)
AMS bride la quantité utilisable de la mémoire archive sur HW1, mais cette limitation n'embête plus personne depuis longtemps, avec MaxMem et maintenant tiosmod+amspatch.
Sur les ordinateurs modernes, la communication avec calculatrices TI qui ne disposent que du port jack 2.5mm stéréo modifié (les connecteurs sont légèrement différents des connecteurs standard) nécessite un SilverLink (TI Graph Link USB).
[^] # Re: Alternatives
Posté par debrouxl . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 1.
Ce n'est pas correct de lire dans mes posts des choses que je n'écris pas, aussi bien sur l'inutilité de SELinux que sur l'invulnérabilité de grsec - des choses que je n'écris pas parce qu'il serait faux de les écrire ;)
De plus, toi et moi sommes d'accord sur certains points: j'ai précisément écrit, dans un autre post de ce thread, "on peut utiliser les frameworks de policy basés sur LSM en plus de grsecurity". Même si apparemment, nous ne mettons pas la même priorité sur les élements.
Bref… on arrête longtemps avant que la modération nous signifie qu'on devrait le faire parce qu'on tourne en rond ?
[^] # Re: Inclusion
Posté par debrouxl . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 3. Dernière modification le 27 août 2015 à 15:05.
Comme je l'ai signalé dans ce post-là, PaXTeam et spender préfèrent en effet se concentrer sur la réalisation des features utiles pour la minorité d'utilisateurs qui connaissent et croient réellement en leur travail, plutôt que sur l'intégration à mainline, suite à une revue de code par des gens moins compétents en sécurité qu'eux, qui leur imposent de passer du temps à dégrader ce qu'ils ont fait (en imposant des interfaces inadaptées, en refusant les plugins GCC, et j'en passe).
J'ai du mal à leur donner complètement tort, tout comme j'ai du mal à donner complètement tort à leurs trop nombreux détracteurs :)
Il n'y a toujours pas de réponse à la question que je posais dans ce post, et que je ne suis évidemment pas le seul à poser: "What to do to meaningfully improve end user security of Linux ?" (for most users on a day to day basis, je rajoute maintenant pour être plus explicite)
S'il y avait une initiative un peu coordonnée de déplacement des morceaux de cleanup non controversiaux que j'ai listés dans un autre post ici depuis PaX/grsecurity vers mainline, j'essaierais de participer, à mon petit niveau, comme je l'avais fait pour quelques patches de constification en 2011 (suite à une autre discussion LWN où j'avais joué l'andouille), peu avant que la constification soit réécrite avec le plugin GCC.
[^] # 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.
[^] # Re: Inclusion
Posté par debrouxl . En réponse au journal Grsecurity : le patch stable réservé aux sponsors. Évalué à 5.
Mathias Krause (minipli) rentre aussi quelques patches de temps en temps.
Des centaines de hunks de PaX/grsecurity sont de purs cleanups, certains n'améliorant même pas explicitement la sécurité, et ne font l'objet d'aucune controverse pour les pousser vers mainline. Un des exemples qui revient le plus souvent est la constification des structures ops. Une très grosse série de patches de constification avait été poussée vers mainline par Emese Revfy (ephox), et peu de développeurs avaient intégré les modifs de constification…
On peut également citer quelques dizaines de structures locales qui prennent de la place sur la pile et du temps d'exécution alors qu'elles pourraient être static (et souvent const), ou a contrario, quelques variables static pour lesquelles ce static n'a aucun intérêt puisque la première chose que fait la fonction qui les déclare est d'écraser leur valeur.
Nombre de ces hunks sont présents depuis des années, inchangés. L'incitation à les pousser vers upstream est faible, puisque le fait de faire une soumission prend du temps, et comme je l'ai mentionné plus haut, le taux d'intégration de ces patches a déjà été montré comme bas.
Un point de ton post ne me paraît pas techniquement correct: on peut utiliser les frameworks de policy basés sur LSM en plus de grsecurity: https://grsecurity.net/compare.php
A moins que tu veuilles dire par "incompatible avec LSM" que mainline insiste absolument pour que grsecurity passe par les fourches caudines de LSM, alors que spender explique depuis des années ( https://grsecurity.net/lsm.php ) que c'est parfaitement inadapté parce que LSM est très loin d'être assez puissant ? C'est hélas un fait que "c'est pas un LSM" est une des objections qui ont été formulées contre l'inclusion de grsec dans mainline - peu importe le fait que ça réduise énormément la puissance de la solution.
[^] # 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.
[^] # Re: Très intéressant
Posté par debrouxl . En réponse à la dépêche Punix, le baptême du feu. Évalué à 4.
Les HW1 n'ont pas que des défauts: par exemple, le grayscale est moins coûteux sur HW1 que sur HW2, et les HW1 n'ont pas cette foutue protection d'exécution en RAM :)
AMS bride la quantité utilisable de la mémoire archive sur HW1, mais cette limitation n'embête plus personne depuis longtemps, avec MaxMem et maintenant tiosmod+amspatch.
Sur les ordinateurs modernes, la communication avec calculatrices TI qui ne disposent que du port jack 2.5mm stéréo modifié (les connecteurs sont légèrement différents des connecteurs standard) nécessite un SilverLink (TI Graph Link USB).