Linux Security Modules

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 du noyau Linux depuis sa version 2.6.

Conception

Linux Security Modules (LSM) est un framework de sécurité pour le noyau Linux. LSM permet aux développeurs de modules de sécurité de proposer de nouveaux mécanismes de sécurité afin de renforcer la sécurité du système. Il a été introduit dans le noyau Linux 2.6 et a été développé pour fournir une interface standardisée pour les modules de sécurité. Il permet aussi l'utilisation de plusieurs modules de sécurité distincts afin de sécuriser différents aspects du système.

LSM est conçu pour fournir tout ce qui est nécessaire à l'implémentation d'un module de contrôle d'accès obligatoire (MAC, pour “Mandatory Access Control”), 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 « Hook » (ou appels au module) à chaque point du noyau où un appel système de l'utilisateur va provoquer un accès à un 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 « Hook » (crochet) ou d'appel vers une couche supérieure (up call). Il ne supporte pas non plus la virtualisation.

L'interface utilisateur de LSM est standardisée et permet aux administrateurs système de définir des politiques de sécurité pour leur système. Les appels système standardisés de l'interface utilisateur comprennent des appels système pour définir des politiques de contrôle d'accès, des listes de contrôle d'accès, des politiques MAC, des politiques de processus, des politiques de pare-feu et d'autres mécanismes de sécurité.

L'interface de module de LSM fournit une interface standardisée pour les modules de sécurité. Cette interface permet aux modules de sécurité d'ajouter de nouveaux mécanismes de sécurité au noyau Linux, de modifier les comportements existants ou de remplacer des mécanismes de sécurité existants. Les modules de sécurité peuvent aussi utiliser les appels système standardisés de l'interface utilisateur pour définir des politiques de sécurité pour leur module.

LSM est conçu pour être flexible et configurable, permettant aux administrateurs système de choisir de charger différents modules de sécurité pour répondre à des besoins de sécurité spécifiques ou de désactiver certains modules s'ils ne sont pas nécessaires. Les développeurs de modules de sécurité peuvent également personnaliser leur module pour répondre aux besoins de sécurité spécifiques de leur application.

LSM est très proche de l'examen de sécurité (audit) de système, car ils ont le même objectif : le contrôle d'accès. Cependant, les deux différents légèrement. L'examen de sécurité nécessite d'enregistrer toutes les tentatives d'accès, ce que LSM ne peut pas faire. En effet, il lui faudrait pour cela de multiples « Hook » (crochets), pour 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 a aussi été 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 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, créateur du noyau Linux, rejeta cette requête, car beaucoup de projets de sécurité étaient en développement à ce moment-là. Comme ceux-ci avaient tous leurs particularités et que la communauté n'avait pas encore formées de consensus sur le modèle de sécurité idéal, Torvalds proposa de créer une architecture modulaire.

En réponse, Crispin Cowan (en) proposa LSM, une interface fournissant suffisamment de points d’ancrage 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é, 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 points d’ancrage permettant d'utiliser des répertoires (“pathname-based”) sont ajoutés dans LSM. Ils ont notamment permis l'intégration des projets AppArmor et TOMOYO (en).

Critiques

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, particulièrement 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 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 aussi partagée par l'auteur de RSBAC, 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, spécialement à 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.

À 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 »)

Même encore, aujourd'hui, LSM conçu pour offrir un cadre générique pour la sécurité du noyau Linux, permettant aux développeurs de modules de sécurité de proposer de nouveaux mécanismes de sécurité pour renforcer la sécurité du système, représente toujours certains défauts de sécurité identifiés dans LSM :

1. Complexité : LSM est un framework complexe qui peut être difficile à configurer et à utiliser correctement. La configuration incorrecte de LSM peut entraîner des vulnérabilités de sécurité.
2. Vulnérabilités des modules : les modules de sécurité développés pour LSM peuvent eux-mêmes contenir des vulnérabilités de sécurité. Les développeurs de modules de sécurité doivent être très attentifs pour s'assurer que leur module est sécurisé et ne crée pas de vulnérabilités supplémentaires.
3. Vulnérabilités du noyau : LSM est intégré dans le noyau Linux, ce qui signifie que les vulnérabilités du noyau peuvent également affecter la sécurité de LSM. Les correctifs de sécurité pour LSM doivent être intégrés dans le noyau Linux, ce qui prend potentiellement du temps.
4. Impact sur les performances : l'utilisation de LSM peut avoir un impact sur les performances du système, car chaque module de sécurité doit être chargé et vérifié pour chaque requête.
5. Limitations : LSM peut ne pas être capable de protéger tous les aspects d'un système. Certains types de vulnérabilités de sécurité nécessitent des solutions de sécurité supplémentaires.

En résumé, bien que LSM soit un framework de sécurité important pour le noyau Linux, il présente certains défauts de sécurité. LSM peut être complexe à configurer et à utiliser correctement, et les modules de sécurité développés pour LSM peuvent ainsi contenir des vulnérabilités de sécurité. L'utilisation de LSM peut aussi avoir un impact sur les performances du système. Il est crucial de comprendre ces défaillances de sécurité lors de l'utilisation de LSM et de mettre en place des mesures supplémentaires de sécurité si nécessaire.

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
• TOMOYO Linux