Linux Security Modules

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[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.

Lors du sommet des développeurs du noyau de Linux (en) 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és 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 (en) 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 (“MAC” pour “mandatory access control”). Le développement de LSM a été conduit pendant les deux années suivantes par la communauté, incluant des contributions importantes de la part d'Immunix Corporation (en), 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 (en) (“LIDS”), FireFlier (en), CIPSO (en), Multi ADM (en), 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 (en).

Bien que LSM tente d'imposer le minimum de surcharge son coût n'est pas nul, y compris lorsqu'aucun module n'est chargé. De même, alors que LSM est destiné uniquement au contrôle d'accès, il peut être utilisé dans un autre but, notamment pour contourner la licence GPL avec un module propriétaire afin d'étendre les fonctionnalités du noyau. Ces deux raisons expliquent que certains développeurs du noyau Linux apprécient peu LSM.

D'autres développeurs, plus orientés sur la sécurité, sont également réticents à l'égard de LSM. Par exemple, l'auteur de grsecurity[6] en raison de son histoire^{[réf. nécessaire]} et parce que LSM permet l'insertion de code malveillant (rootkit) ainsi que des modules de sécurité. Cette réticence est également partagée par l'auteur de RSBAC[7], car LSM lui semble incomplet vis-à-vis des besoins de ce projet.

Cependant, ces deux critiques datent respectivement de 2006 et 2008 et les arguments soulevés sont associés à la version 2.6 du noyau Linux. Elles sont donc à relativiser au présent, notamment à partir de 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 a été mis en place avec la version 3.4 du noyau Linux et il n'a pas été lancé par les spécialistes de la sécurité sans avoir préalablement comblé les problèmes relatifs à l'ancienne version du noyau sur laquelle se basaient les critiques exposées ci-dessus[8]..

A partir de la version 3.7 du noyau Linux, Le LSM Yama est autorisé à venir renforcer des modules plus connus comme Apparmor ou SELinux, et à cohabiter avec eux par empilage (« LSM Stacking »)[9]