mardi 30 juin
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: La fin de Grsecurity ?

Posté par patrick_g (page perso, ). Modéré le 06 janvier 2009.
38
Grsecurity est un patch sous licence GPL pour Linux qui vise a renforcer la sécurité du noyau par l'ajout de divers mécanismes.

Le sponsor principal du projet s'étant retiré du fait de la crise économique, la version 2.1.12 de Grsecurity pourrait bien être la dernière. Selon l'annonce postée sur le site, si un nouveau sponsor ne se manifeste pas avant le 31 mars alors les développements prendront fin et le projet sera gelé, peut-être définitivement.

> Lire la suite (26 commentaires, moyenne: 6,5).   [dépêche : 7989 caractères]

Grsecurity propose une multitude de fonctions pour renforcer la sécurité de Linux et pour contrer les diverses attaques qui visent à prendre le contrôle du noyau.
En premier lieu Grsecurity inclut le patch PaX qui permet de rendre aléatoire les adresses mémoires et d'empêcher l'écriture sur les portions mémoires contenant du code exécutable.
Grsecurity permet également de renforcer la résistance du mécanisme de Chroot (qui sert à isoler un programme dans un système de fichier afin de le sécuriser).
Des fonctions d'audit sont ajoutées dans le noyau afin de mieux surveiller ce qui se passe sur une machine et d'être averti plus vite en cas d'attaque.
La fonction Trusted Path permet d'interdire l'exécution des binaires dont le propriétaire n'est pas administrateur.

En ce qui concerne les restrictions d'accès Grsecurity utilise un modèle de sécurité à base de rôles (RBAC) alors que le modèle de sécurité de SELinux est plutôt celui du contrôle d'accès obligatoire (MAC). Cette différence de philosophie est aggravée par le refus des développeurs de Grsecurity d'utiliser LSM.
En effet, afin d'éviter d'avoir à choisir entre différents modules de sécurité et compte tenu du fait que les développeurs s'écharpaient sur les listes de diffusion, Linus a décidé de privilégier une infrastructure unique sur laquelle viendraient de greffer les modules concurrents.
Cette infrastructure LSM (Linux Security Modules) est utilisé par les modules SELinux et SMACK mais Grsecurity a toujours refusé de jouer le jeu.
Selon les développeurs du projet ce serait une erreur que d'utiliser LSM car cette infrastructure souffrirait de problèmes techniques. Tout d'abord les crochets (hooks) permettant à l'infrastructure de présenter des points d'entrée aux différents modules seraient mal pensés. En nombre insuffisant et spécialisés dans une architecture de contrôle d'accès qui n'est pas celle de Grsecurity, ces hooks ne sont pas adaptés au projet et sont mêmes accusés de faciliter le travail de rootkit pour s'implanter dans le noyau.
Cette critique radicale de LSM est disponible sur le site du projet et on peut y lire entre les lignes qu'il existe une certaine rancœur envers SELinux qui est perçu comme ayant une volonté hégémonique.

À cause de ce refus de l'infrastructure LSM, le patch Grsecurity/PaX n'a jamais pu entrer dans le noyau Linux ce qui a eu de lourdes conséquences. En effet, n'étant jamais entré dans la branche principale, le patch Grsecurity doit être maintenu et adapté par les développeurs du projet afin de rester compatible avec un noyau Linux qui bouge très vite. Ce travail supplémentaire explique le fait que les versions de Grsecurity ne sont pas compatibles avec toutes les versions du noyau. Il y a des « trous » dans la disponibilité du patch puisque, par exemple, la version 2.1.11 est prévue pour les noyau 2.6.24.x alors que la version 2.1.12 est adapté au noyau 2.6.27.x.
Si par malchance vous utilisez un noyau 2.6.25 ou 2.6.26 alors vous ne pourrez pas profiter de Grsecurity (sauf rétroportage effectué par votre distribution).

Un problème plus subtil est celui de la reconnaissance par les sponsors éventuels. Comment faire valoir son excellence technique et obtenir des subsides si on n'arrive pas à intégrer le noyau Linux officiel ? Il est probable que de nombreux sponsors et contributeurs potentiels ont été et continuent à être rebutés par cette absence de perspective d'intégration.
Ce problème est d'ailleurs bien perçu par les partisans de Grsecurity et de PaX qui, après l'annonce des difficultés du projet, ont effectuée une nouvelle tentative en vue d'une entrée dans la branche principale. Ce post sur la liste de diffusion de Linux pose clairement la question: « Avant que le projet ne meure je voudrais attirer encore une fois votre attention sur la question de l'intégration dans le noyau ».
La réponse de Linus a été fort peu encourageante :
« Franchement ces patchs ont toujours été un mélange de :
- trucs raisonnables
- code invasif complètement stupide
Un exemple de la deuxième catégorie est le patch totalement idiot d'émulation pourrie du bit NX. Cette sorte de patch ajoute simplement de la saleté non maintenable et n'est même pas utile sur le long terme. N'importe quel mainteneur sain d'esprit (moi) devrait refuser son intégration.
L'apparente inaptitude (et, plus important encore, le manque total de volonté) de la part de l'équipe PaX pour comprendre ce qui doit ou pas être intégré dans un noyau, de découper leur code et de tenter d'intégrer les parties de bonne qualité (et de savoir reconnaitre les parties pourries ou trop spécialisées pour entrer dans le noyau) a conduit à la non intégration des fonctions de PaX.
Non je ne vais pas soudainement commencer à accepter ce code juste parce que le projet est en mauvaise posture. Aucun des problèmes de base n'a été résolu ».

À suivre les échanges sur la liste de diffusion il semble clair que les partisans de Grsecurity n'ont pas bien compris le modèle de développement du noyau Linux et ce ne sont pas leurs appels pour sauver le projet qui vont y changer quoi que ce soit.
Robert Hancock a détaillé pour eux la marche a suivre :
« Tout ça c'est bien joli mais ce ne sont pas des messages qui vont faire avancer les choses. Si ces gens veulent inclure leur code dans la branche principale alors le chemin est le même que pour tous les autres : proposer des patchs concrets, qui améliorent pas à pas le fonctionnement et qui ne font pas doublon avec des fonctions déjà présentes. Des patchs qui relèvent clairement du noyau et pas de l'espace utilisateur, qui n'ajoutent pas une charge de maintenance inacceptable, etc.
Si de tels patchs sont soumis alors ils auront le potentiel pour être acceptés. La question est : pourquoi les gars de Grsecurity n'ont pas fait ça avant par opposition à maintenant qu'ils sont en crise ?
Dire aux développeurs de Linux "Hé, incluez ce gros bout de code dans votre noyau sinon on reprend notre joujou et on rentre chez nous" n'est pas la bonne méthode ».

Les perspectives d'inclusion étant donc sombres, il semble peu probable que Grsecurity/PaX survive à cette crise sans l'apparition d'un sponsor décidé à faire vivre le projet. Grsecurity se bat pour sa survie et fait la publicité de ses fonctions afin de démonter que ses choix étaient bons depuis des années. Un graphique illustrant l'influence du projet sur les autres systèmes d'exploitation a été créé et est accessible sur le site.

Il serait dommage que ce projet, jouant souvent le rôle d'aiguillon et de défricheur, ne soit plus en mesure d'avancer et disparaisse définitivement.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Difficulté d'être inclu dans le noyau

Posté par Victor STINNER (Jabber id, page perso, ) le 06/01/2009 à 16:45. (lien). Évalué à 10.

Le patch grsecurity modifie 539 files fichiers et fait environ 37.000 lignes. C'est un très gros patch monolithique qui doit être redécoupé pour être inclu dans le noyau. Est-ce que ce travail a déjà été fait ?

PaX seul modifie 455 fichiers et pèse environ 23.000 lignes.

Le prix du développement out-of-tree

Posté par fweisbec () le 06/01/2009 à 17:20. (lien). Évalué à 10.

C'est le prix à payer lorsqu'on développe un projet pour le noyau sans travailler avec le reste de la communauté. Certes peut être qu'ils n'acceptaient pas de bosser sur une base bancale. Alors en ce cas il fallait envoyer des patchs pour virer ces mauvaises bases et les tourner petit à petit vers ce qu'ils voulaient tout en apportant régulièrement l'argumentation qui va avec.

C'est déjà parfois difficile de faire avaler aux mainteneurs un petit jeu de 10 petits patchs qui développe une idée travaillée de manière isolée sans en parler à la communauté. A moins d'avoir de la chance ou beaucoup d'expérience.
En règle générale, soit l'idée est carrément refusée, soit on applique les révisions des rélecteurs de patchs et on renvoie une nouvelle version de son jeu de patch, et on itère comme ça jusqu'à ce que ça plaise à tout le monde. On voit régulièrement passer, sur la mailing list de Linux, des patchs qui en sont à leur 5ème, 10 ème version. Enfin heureusement ce n'est pas toujours comme ça. Au delà de 5 itérations c'est quand même plus rare. Mais ça peut être comme ça au lancement d'un projet pour le kernel et après la suite du développement est souvent plus simple et plus fluide, une fois qu'on a compris comment accorder ses propres désirs avec la direction que veut prendre la communauté, on parvient à balancer des patchs qui sont inclus sans trop de besoin de correction.

Bref, je parlais là d'un petit jeu de 10 petits patchs. Mais leur truc est un pavé.

C'est difficile d'inclure un pavé dans le noyau, l'idéal étant d'inclure chaque fonctionnalité d'un projet petit à petit, en restant toujours très proche de la liste de diffusion. Si un changement nécessite d'un coup un gros patch, il faut toujours parler de son idée avant et voir l'avis des autres, au risque d'être frustré après avoir balancé un patch de plusieurs semaines de boulot sans en en avoir parlé avant.

Chantage

Posté par Aris Adamantiadis (page perso, ) le 06/01/2009 à 18:27. (lien). Évalué à 10.

Le chantage à l'abandon du support de grsec, brad nous l'a déjà fait il y a 2 ans quand il avait besoin grave de thunes. Evidement que c'est pas dans son interet de merger grsec dans linux, ça casse son business

Bon

Posté par win32powa () le 06/01/2009 à 21:18. (lien). Évalué à 10.

Espérons qu'ils vont pas tuer leur femme hein ...
Ok ====>[]

--
Win the 32 bits, harder as possible.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1756s (dont 0.0561 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !