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.
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 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.
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 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 :
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 pourront notamment être utilisés par des projets comme AppArmor ou TOMOYO.
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 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 car LSM est jugé comme incomplet vis-à-vis des besoins de ce projet.