Linux Security Modules

Un article de Wikipédia, l'encyclopédie libre.

Cet article est une ébauche concernant la sécurité informatique.

Vous pouvez partager vos connaissances en l’améliorant. (Comment ?).

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.

Sommaire

1 Conception
2 Histoire
3 Critiques
4 Voir aussi
- 4.1 Références
- 4.2 Liens externes

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

Portion de texte anglais à traduire en français

Texte anglais à traduire :
It is not intended as a general "hook" or "upcall" mechanism, nor does it support virtualization.

LSM's access control goal is very closely related to the problem of system auditing, but is subtly different. Auditing requires that every attempt at access be recorded. LSM cannot deliver that, because it would require a great many more hooks, so as to detect cases where the kernel "short circuits" failing system calls and returns an error code before getting near significant objects.

The LSM design is described in the paper Linux Security Modules: General Security Support for the Linux Kernel^[1] presented at USENIX Security 2002.^[2] At the same conference was the paper Using CQUAL for Static Analysis of Authorization Hook Placement^[3] which studied automatic static analysis of the kernel code to verify that all of the necessary hooks have actually been inserted into the Linux kernel.

Traduire ce texte • Outils • (+)

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

Portion de texte anglais à traduire en français

Texte anglais à traduire :
If there is to be only one widely used LSM module, it was reasoned, then the indirection of LSM is unnecessary, and LSM should be removed and replaced with SELinux itself. However, there other LSM modules are maintained outside of the mainstream kernel tree (AppArmor, Linux Intrusion Detection System, FireFlier, CIPSO, Multi ADM, etc.), so this argument led to 2 results: 1. that developers of these modules started putting effort into upstreaming their respective modules, and 2. at the 2006 Kernel Summit, Linus once again asserted that LSM would stay because he does not want to arbitrate which is the best security model.

Traduire ce texte • Outils • (+)

[modifier] 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^[5] 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^[6] car LSM est jugé comme incomplet vis-à-vis des besoins de ce projet.