Linux Security Modules

Pour les articles homonymes, voir LSM.

Linux Security Modules (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 qui ne s'adapte pas aux noyaux multiprocesseurs, et qui est vulnérable aux attaques time-of-check-to-time-of-use (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^[1] qui a fait l'objet d'une présentation à la conférence Usenix Security 2002^[2].

Lors de cette conférence fut aussi présenté l'article Using CQUAL for Static Analysis of Authorization Hook Placement^[3] 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^[4], 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 developpement 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^[5]. 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^[6] en raison de son histoire et car LSM permet l'insertion de code malicieux (rootkit) ainsi que des modules de sécurité. C'est le cas aussi de l'auteur de RSBAC^[7] car LSM est jugé comme incomplet vis-à-vis des besoins de ce projet.

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)

1. ↑ Linux Security Modules: General Security Support for the Linux Kernel, 2002. Consulté le 3 février 2007
2. ↑ 11th USENIX Security Symposium, 2002. Consulté le 3 février 2007
3. ↑ Using CQUAL for Static Analysis of Authorization Hook Placement, 2002. Consulté le 3 février 2007
4. ↑ Crispin Cowan, « Linux Security Module Interface », linux-kernel mailing list, 11 avril 2001. Consulté le 3 février 2007
5. ↑ Patrick Guignot, « Sortie de Linux 2.6.29 », LinuxFR, 24 mars 2009
6. ↑ grsecurity, grsecurity. Consulté le 3 février 2007
7. ↑ RSBAC and LSM, RASBAC. Consulté le 3 février 2007

Liens externes

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