Linux Security Modules

Le Linux Security Modules (sigle: LSM) est une infrastructure qui permet au noyau Linux de prendre en charge divers modèles formels de sécurité ce qui évite de favoriser une implémentation de sécurité particulière. Cette infrastructure est distribuée sous licence publique générale GNU et fait partie intégrante de noyau Linux depuis sa version 2.6.

Conception

LSM est conçu pour fournir tout ce qui est nécessaire pour permettre l'implémentation d'un module de contrôle d'accès obligatoire (MAC), tout en modifiant le moins possible le noyau Linux. LSM évite d'utiliser l'approche d'interposition utilisée par Systrace (en) qui ne s'adapte pas aux noyaux multiprocesseurs, et qui est vulnérable aux attaques time-of-check-to-time-of-use (en) (TOCTTOU). Au lieu de cela, LSM ajoute des crochets « hooks » (appels au module) à chaque point du noyau où un appel système de l'utilisateur va provoquer un accès à un important objet interne du noyau, comme les inodes, ou les blocs de contrôle de tâche.

Le projet est strictement limité à la résolution des problèmes de contrôle d'accès afin d'éviter d'avoir à recourir à une modification importante et complexe du noyau de base.

LSM n'est pas conçu comme un mécanisme générique de crochet (hook) ou d'appel vers une couche supérieure (upcall). Il ne supporte pas non plus la virtualisation.

L'objectif de LSM, le contrôle d'accès, est très proche de l'examen de sécurité (audit) de système, mais il est très légèrement différent. L'examen de sécurité nécessite d'enregistrer toutes les tentatives d'accès. LSM ne peut pas le faire. En effet il lui faudrait pour cela de très nombreux crochets, de façon à détecter les cas où le noyau court-circuite les appels système inaboutis et renvoie un code d'erreur avant d'atteindre des objets importants à l'intérieur du noyau.

La conception de LSM est décrite dans l'article Linux Security Modules: General Security Support for the Linux Kernel qui a fait l'objet d'une présentation à la conférence Usenix Security 2002.

Lors de cette conférence fut aussi présenté l'article Using CQUAL for Static Analysis of Authorization Hook Placement qui étudie l'analyse statique automatisée du code du noyau, dans le but de vérifier que tous les crochets nécessaires ont bien été insérés dans le noyau Linux.

Histoire

Lors du Linux Kernel Developers Summit qui a eu lieu en 2001, la NSA a proposé que SELinux soit intégré dans la version 2.5 du noyau. Linus Torvalds rejeta cette requête car beaucoup de projets de sécurité étaient en développement à ce moment. Comme ceux-ci avaient tous leurs particularité et que la communauté n'avait pas encore formé de consensus sur le modèle de sécurité parfait, Linus Torvalds proposa de créer une architecture modulaire.

En réponse, Crispin Cowan proposa LSM, une interface fournissant suffisamment de crochets (« hooks ») dans le noyau Linux pour créer des modules permettant de renforcer le contrôle d'accès obligatoire. Le développement de LSM a été conduit pendant les deux années suivantes par la communauté, en incluant des contributions important de la part d'Immunix Corporation, la NSA, McAfee, IBM, Silicon Graphics, ainsi que d'autres contributeurs indépendants.

Certains ont présenté l'argumentation suivante : s'il ne doit y avoir qu'un seul modèle de sécurité, alors l'interface via LSM n'est pas nécessaire, il faut supprimer LSM et le remplacer par SELinux. Cependant, d'autres modules LSM existent et sont maintenus indépendamment du développement du noyau Linux : AppArmor, Linux Intrusion Detection System, FireFlier, CIPSO, Multi ADM, etc. De ce fait, l'argumentation en question a deux effets :

• les développeurs de ces autres modules ont déployé plus d'énergie dans leur amélioration ;
• lors du Kernel Summit de 2006, Linus Torvalds a répété que LSM resterait dans le noyau Linux, car il ne souhaitait pas trancher sur le choix du meilleur modèle de sécurité.

Avec la sortie de la version 2.6.29 du noyau Linux, de nouveaux crochets permettant d'utiliser des chemins (« pathname-based ») sont ajoutés dans LSM. Ces crochets ont été utilisés pour l'intégration des projets AppArmor et TOMOYO.

Critiques

Certains développeurs du noyau Linux n'aiment pas LSM pour plusieurs raisons. LSM tente d'imposer le minimum de surcharge, spécialement lorsqu'aucun module n'est chargé, mais ce coût n'est pas nul. Aussi, LSM est destiné uniquement pour le contrôle d'accès et certains développeurs n'aiment pas que l'on puisse l'utiliser dans un autre but, principalement lorsqu'il est utilisé pour contourner la licence GPL avec un module propriétaire pour étendre les fonctionnalités du noyau.

Certains développeurs de sécurité n'aiment pas non plus LSM. Par exemple, l'auteur de grsecurity en raison de son histoire^{[réf. nécessaire]} et car LSM permet l'insertion de code malveillant (rootkit) ainsi que des modules de sécurité. C'est le cas aussi de l'auteur de RSBAC car LSM est jugé comme incomplet vis-à-vis des besoins de ce projet.

Ces deux critiques datent respectivement de 2006 et 2008. En détail :

• celle de grsecurity a été édité la dernière fois en 2008, vous êtes invités à cliquer dans la partie Références, en dessous au 6 sur le mot grsecurity qui s'y trouve, et ensuite sur le mot [archive] qui est juste à côté pour retrouver les dates de 2008, et pour prendre conscience que cet article avait été rédigé pour le noyau Linux 2.6. En comparaison, la page de Wikipédia sur le noyau linux d'aujourd'hui annonce que nous sommes déjà au numéro de version du noyau 3.19, pour vous dire que ces deux critiques datent vraiment d'une autre époque et pour un autre noyau.
• celle de RSBAC and LSM a été édité en dernier en 2006, pour vous en rendre compte cliquez sur les mots « RSBAC and LSM » au petit 7 du dessous dans la rubrique Références. Et là aussi en début d'article il est question du noyau 2.6, donc nous sommes en présence de critiques conclues, vous l'aurez compris, pour un noyau d'un autre âge et rédigées depuis un autre âge.

Elles sont donc à reconsidérer vivement, surtout connaissant l'arrivée du module LSM Yama, et de son acceptation à la cohabitation avec les logiciels Apparmor et SELinux, dans le seul but de les aider à sécuriser les systèmes Linux. Yama est en place depuis un bout de temps aussi (noyau 3.4), et il n'a pas été lancé par les spécialistes de la sécurité sous Linux, sans avoir comblé les problèmes relatifs au noyau 2.6 annoncés par les critiques du dessus. L'article sur le site linuxfr.org concernant Yama est plus parlant, je vous invite à en prendre connaissance. Vous verrez que l'article termine par l'attente de savoir si le « LSM Stacking » parviendra à s'imposer ou non. « Stacking » peut être traduit par «empilage», nous sommes donc bien en attente de fonctions d'empilage de systèmes de sécurité. Et c'est ce qui va se passer depuis le noyau 3.7 pour le LSM Yama, (comme l'annonce la page Wiki d'Ubuntu, dans son petit bout de phrase, à la fin de la partie «ptrace Protection»). Le LSM Yama est donc maintenant autorisé à venir renforcer des modules plus connus comme Apparmor, SELinux, et à cohabiter avec eux sans plus aucune retenue, nous pouvons donc répondre à la question de la fin d'article du site Linufr.org, par un «Oui messieurs, le « LSM Stacking » est désormais enclenché pour le LSM Yama», et c'est tant mieux !

Voir aussi

Références

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Linux Security Modules » (voir la liste des auteurs).

Liens externes

• LSM project homepage
• Source code and project statistics
• SysAdmin magazine article on BSD Secure Levels