Linux Security Modules

from Wikipedia, the free encyclopedia

Linux Security Modules ( LSM ) is a framework that enables the Linux kernel to support different computer security models without preferring a single specific security implementation. The framework is under the GNU General Public License and has been part of the Linux kernel by default since version 2.6. AppArmor , SELinux , Smack and TOMOYO Linux are the currently officially accepted modules in the Linux kernel.

draft

LSM was designed to meet the special requirements that are required to successfully implement a Mandatory Access Control module and still only have to make the smallest possible changes to the Linux kernel. LSM avoids the system call interposition approach used by Systrace as it does not scale on multiprocessor kernels and is susceptible to TOCTTOU attacks. Instead, LSM inserts " hooks " (upcalls to the module) at every point in the kernel at which a user-level system call leads to an access to an important internal kernel object, such as inodes and task control blocks.

The project is closely focused on addressing the access control problem and aims to avoid a large and complex change to the mainstream kernel. It is not intended as a general " hook " or " upcall " mechanism, nor does it support virtualization at the operating system level .

LSM's objectives for access control are closely related to, but slightly different from, the problem of system auditing. Auditing requires that every access attempt be logged. LSM cannot do this. It would take many more hooks to detect cases where the kernel simply blocks failing system calls and returns an error code before they ever get near critical objects.

The LSM design is described in the treatise Linux Security Modules: General Security Support for the Linux Kernel , which was presented at USENIX Security 2002. At the same conference, the paper Using CQUAL for Static Analysis of Authorization Hook Placement was discussed, which examines the automatic, static analysis of the kernel code in order to check whether all of the required hooks have actually been integrated into the Linux kernel.

use

development

At the Linux Kernel Summit 2001, the NSA suggested that SELinux could be integrated with Linux 2.5. Linus Torvalds rejected SELinux at the time, observing that there were many different security projects in development. And since they were all different, the security developer community had not yet reached consensus on the ultimate security model. Instead, Torvalds asked the developers to "make it a kernel module".

In response, Crispin Cowan suggested LSM: An interface for the Linux kernel that would offer enough "hooks" (upcalls) from within the Linux kernel to a loadable module so that the module could enforce mandatory access control. LSM's development over the next two years was led by the LSM community, including significant contributions from Immunix Corporation, the NSA , McAfee , IBM , Silicon Graphics, and many independent contributors. LSM was finally accepted for the Linux main stream kernel and integrated as a standard part of Linux 2.6 in December 2003.

In 2006, some kernel developers observed that SELinux was the only widely used LSM module built into the Linux mainstream kernel sources. It was considered that if there was only one widely used LSM module, the detour via LSM would be unnecessary and LSM should be removed and replaced with SELinux itself. However, there are other LSM modules that are maintained outside of the mainstream kernel sources ( AppArmor , Linux Intrusion Detection System, FireFlier, CIPSO, Multi ADM, etc.). This exchange of views had two consequences: 1. The developers of these modules went to great lengths to submit their respective modules and 2. At the Kernel Summit 2006, Torvalds reaffirmed that LSM would stay in the kernel because he did not want to have to convey which would be the best security model.

It is likely that the LSM will remain in the kernel, as other security modules such as Smack (version 2.6.25), TOMOYO Linux (Vversion 2.6.30, June 2009) and AppArmor (version 2.6.36) are also available for the mainline kernel were accepted.

reception

Some Linux kernel developers don't like LSM for a variety of reasons. LSM strives to generate as little overhead as possible, especially when no module is loaded. But these costs are not zero and some Linux developers are bothered by it. LSM was designed only to provide access control, it does not prevent LSM from being used for other purposes, and some Linux kernel developers do not like that it can be "misused" for other purposes. Especially when the purpose is to expand the functionality of the Linux kernel with a proprietary module and thereby circumvent the GPL .

Some security developers don't like LSM either. The author of grsecurity does not like LSM because of its history and because LSM enables not only the insertion of security modules, but also the insertion of harmful modules ( rootkits ) by exporting all of its symbols . The author of RSBAC does not like LSM because it is incomplete in terms of RSBAC requirements. He argues in detail: "LSM is only about additional, restrictive access control. The RSBAC system, however, offers a lot of additional functionality, such as symlink redirection, secure_delete and partial Linux DAC deactivation. All of this has to become kernel functions first to be added in separate patches. ". The Dazuko Project argues that working with the LSM API is time-consuming, as it changes with every kernel release, which means additional maintenance costs. Other developers would prefer LSM modules to build on one another, e.g. B. the developers at Yama LSM.

Individual evidence

  1. ↑ Linux Security Modules: General Security Support for the Linux Kernel . Retrieved February 3, 2007.
  2. ↑ 11th USENIX Security Symposium . Retrieved February 3, 2007.
  3. ↑ Using CQUAL for Static Analysis of Authorization Hook Placement . Retrieved February 3, 2007.
  4. ↑ Linux Security Modules: General Security Hooks for Linux . Retrieved October 26, 2015.
  5. ^ Crispin Cowan: Linux Security Module Interface . In: linux-kernel mailing list . April 11, 2001. Retrieved February 3, 2007.
  6. ↑ grsecurity . grsecurity. Retrieved February 3, 2007.
  7. ↑ RSBAC and LSM . RSBAC. Retrieved February 3, 2007.
  8. ↑ add . in addition Retrieved December 26, 2017.
  9. ^ Jake Edge: LSM stacking (again) . www.lwn.net. June 23, 2010. Retrieved May 28, 2015.