< Back to index
Linux Security Modules (LSM) is a framework to allow the Linux kernel to support a variety of computer security models while avoiding to favor a single security implementation. The framework is licensed under the terms of the GNU General Public License and is standard part of the Linux kernel since Linux 2.6.
Design
LSM was designed to provide everything needed to successfully implement a mandatory access control module, while imposing the least possible changes on the Linux kernel. LSM avoids the approach of [http://citeseer.ist.psu.edu/garfinkel03traps.html system call interposition] as used in Systrace because it does not scale to multiprocessor kernels and is subject to TOCTTOU (race) attacks. Instead, LSM inserts "hooks" (upcalls to the module) at every point in the kernel where a user-level system call is about to result in access to an important internal kernel object such as inodes and task control blocks.
Scoping the intended usage of LSM was very important. It could not be "hooks r us" and become arbitrary upcalls for any purpose. It could not impose a large and complex change patch on the mainstream kernel. The design goal that LSM adopted was to be purely for access control. LSM does not support virtualization, as that is a separate problem space.
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 [http://www.usenix.org/event/sec02/wright.html Linux Security Modules: General Security Support for the Linux Kernel] presented at [http://www.usenix.org/event/sec02/ USENIX Security 2002]. At the same conference was the paper [http://www.usenix.org/event/sec02/zhang.html Using CQUAL for Static Analysis of Authorization Hook Placement] 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.
History
At the 2001 Linux Kernel Summit, the NSA proposed that SELinux be included in Linux 2.5. Linus 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 [http://marc.theaimsgroup.com/?l=linux-kernel&m=98695004126478&w=2 proposed] 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. LSM was ultimately accepted into the Linux kernel mainstream and was included as a standard part of Linux 2.6 in December 2003.
The SELinux kernel module evenutally was accepted into the mainstream Linux kernel (date and citation needed).
In 2006, some kernel developers observed that SELinux was the only LSM module included in the mainstream Linux kernel source tree. If there is to be only one LSM module, it was reasoned, then the indirection of LSM is unnecessary, and LSM should be removed and replaced with SELinux itself. However, there is a large number of LSM modules outside of the mainstream kernel tree (AppArmor, Linux_Intrusion_Detection_System, FireFlier, BSD Secure Levels, CIPSO, Multi ADM, etc.) and so this argument lead 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.
Criticism
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 [http://www.grsecurity.net/lsm.php dislikes LSM] because of its history, and because LSM facilitates the insertion of malicious modules (rootkits) as well as security modules. The author of RSBAC [http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm dislikes LSM] because it is incomplete with respect to the needs of RSBAC.
This entry uses material from from Wikipedia, the leading user-contributed encyclopedia. It is licensed under the GNU Free Documentation License. Disclaimer.