Aller au contenu

Linux Security Modules

Un article de Wikipédia, l'encyclopédie libre.
Ceci est une version archivée de cette page, en date du 17 août 2007 à 15:46 et modifiée en dernier par Mirmidon (discuter | contributions) (Traduction de l'article en anglais (à compléter)). Elle peut contenir des erreurs, des inexactitudes ou des contenus vandalisés non présents dans la version actuelle.
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)

Linux Security Modules (LSM) est un framework qui permet au noyau Linux de supporter une variété de modèles formels de sécurité afin d'abolir la préférence d'une seule implémentation de sécurité. Le framework est distribué sous licence publique générale GNU et fait partie intégrante de noyau Linux depuis sa version 2.6.

Conception

LSM a été conçu afin de fournir une implémentation réussie du module de contrôle d'accès obligatoire ( MAC mandatory access control ), tout en modifiant le moins possible le noyau Linux. LSM évite d'utiliser l'approche qui est 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 insère des crochets "hooks" (appels à des modules) à chaque point dans le noyau où un appel système de niveau utilisateur conduit à l'accès d'un objet interne important du noyau comme les inodes et les tâches de contrôle des blocs. Ces crochets permettent de contrôler l'intégrité des demandes.

Le projet est suivi de près pour résoudre les problèmes liés au contrôle d'accès et pour empêcher l'utilisation d'une importante et complexe rustine logicielle sur le noyau traditionnel.

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.

Histoire

At the 2001 Linux Kernel Summit, the NSA proposed that SELinux be included in Linux 2.5. Linus Torvalds rejected SELinux at that time, because he observed that there are many different security projects in development, and since they all differ, the security community has not yet formed consensus on the ultimate security model. Instead, Linus charged the security community to "make it a module".

In response, Crispin Cowan proposed[4] LSM: an interface for the Linux kernel that provides sufficient "hooks" (upcalls) from within the Linux kernel to a loadable module so as to allow the module to enforce mandatory access controls. Development of LSM over the next two years was conducted by the LSM community, including substantial contributions from the Immunix Corporation, the NSA, McAfee, IBM, Silicon Graphics, and many independent contributors.

In 2006, some kernel developers observed that SELinux was the only widely used LSM module included in the mainstream Linux kernel source tree. 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.

Critiques

Some Linux kernel developers dislike LSM for a variety of reasons. LSM strives to impose the least overhead possible, especially in the case where no module is loaded, but this cost is not zero, and some Linux developers object to that cost. LSM is designed to provide only for access control, but does not actually prevent people from using LSM for other reasons, and so some Linux kernel developers dislike that it can be "abused" by being used for other purposes, especially if the purpose is to bypass the Linux kernel's GPL license with a proprietary module to extend Linux kernel functionality.

Some security developers also dislike LSM. The author of Grsecurity dislikes LSM[5] because of its history, and because LSM facilitates the insertion of malicious modules (rootkits) as well as security modules. The author of RSBAC dislikes LSM[6] because it is incomplete with respect to the needs of RSBAC.

Références

  1. « Linux Security Modules: General Security Support for the Linux Kernel », (consulté le )
  2. « 11th USENIX Security Symposium », (consulté le )
  3. « Using CQUAL for Static Analysis of Authorization Hook Placement », (consulté le )
  4. Crispin Cowan, « Linux Security Module Interface », linux-kernel mailing list, (consulté le )
  5. « grsecurity », grsecurity (consulté le )
  6. « RSBAC and LSM », RASBAC (consulté le )

Liens externes

Modèle:Logiciels libres