USENIX Association Proceedings of the 11th USENIX Security Symposium San Francisco, California, USA August 5-9, 2002 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2002 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Linux Security Modules: General Security Support for the Linux Kernel Chris Wright and Crispin Cowan Stephen Smalley WireX Communications, Inc. NAI Labs, Network Associates, Inc. [email protected], [email protected] [email protected] James Morris Greg Kroah-Hartman Intercode Pty Ltd IBM Linux Technology Center [email protected] [email protected] Abstract mented [9, 1, 4, 41, 23, 10, 29, 37], mainstream oper- ating systems typically still lack support for these en- hancements. In part, the absence of such enhancements The access control mechanisms of existing mainstream is due to a lack of agreement within the security com- operating systems are inadequate to provide strong sys- munity on the right general solution. tem security. Enhanced access control mechanisms have failed to win acceptance into mainstream operating sys- Like many other general-purpose operating systems, the tems due in part to a lack of consensus within the se- Linux kernel only provides discretionary access controls curity community on the right solution. Since general- and lacks any direct support for enhanced access control purpose operating systems must satisfy a wide range of mechanisms. However, Linux has long supported dy- user requirements, any access control mechanism inte- namically loadable kernel modules, primarily for device grated into such a system must be capable of supporting drivers, but also for other components such as filesys- many different access control models. The Linux Secu- tems. In principle, enhanced access controls could be rity Modules (LSM) project has developed a lightweight, implemented as Linux kernel modules, permitting many general purpose, access control framework for the main- different security models to be supported. stream Linux kernel that enables many different access control models to be implemented as loadable kernel In practice, creating effective security modules is prob- modules. A number of existing enhanced access control lematic since the kernel does not provide any infrastruc- implementations, including Linux capabilities, Security- ture to allow kernel modules to mediate access to ker- Enhanced Linux (SELinux), and Domain and Type En- nel objects. As a result, kernel modules typically re- forcement (DTE), have already been adapted to use the sort to system call interposition to control kernel op- LSM framework. This paper presents the design and erations [18, 20], which has serious limitations as a implementation of LSM and discusses the challenges method for providing access control [41]. Furthermore, in providing a truly general solution that minimally im- these kernel modules often require reimplementing se- pacts the Linux kernel. lected kernel functionality [18, 20] or require a patch to the kernel to support the module [10, 3, 15], reduc- ing much of the value of modular composition. Hence, many projects have implemented enhanced access con- 1 Introduction trol frameworks or models for the Linux kernel as kernel patches [29, 37, 23, 32, 27]. The critical role of operating system protection mech- At the Linux Kernel 2.5 Summit, the NSA presented anisms in providing system security has been well- their work on Security-Enhanced Linux (SELinux) [29], understood for over thirty years, yet the access control an implementation of a flexible access control architec- mechanisms of existing mainstream operating systems ture in the Linux kernel, and emphasized the need for are still inadequate to provide strong security [2, 39, 28, such support in the mainstream Linux kernel. Linus Tor- 17, 26, 6, 30]. Although many enhanced access control valds appeared to accept that a general access control models and frameworks have been proposed and imple- framework for the Linux kernel is needed, but favored a conceptually simple, minimally invasive, and effi- new infrastructure that would provide the necessary sup- • cient; and port to kernel modules for implementing security. This approach would avoid the need to choose among the ex- able to support the existing POSIX.1e capabilities • isting competing projects. logic as an optional security module. In response to Linus’ guidance, the Linux Security Mod- ules (LSM) [45, 40] project has developed a lightweight, The various Linux security projects were primarily inter- general purpose, access control framework for the main- ested in ensuring that the security framework would be stream Linux kernel that enables many different ac- adequate to permit them to reimplement their existing cess control models to be implemented as loadable ker- security functionality as a loadable kernel module. The nel modules. A number of existing enhanced access new modular implementation must not cause any signif- control implementations, including POSIX.1e capabil- icant loss in the security being provided and should have ities [42], SELinux, and Domain and Type Enforcement little additional performance overhead. (DTE) [23], have already been adapted to use the LSM framework. The core functionality for most of these security projects was access control. However, a few security projects The LSM framework meets the goal of enabling many also desired other kinds of security functionality, such as different security models with the same base Linux ker- security auditing or virtualized environments. Further- nel while minimally impacting the Linux kernel. The more, there were significant differences over the range generality of LSM permits enhanced access controls of flexibility for the access controls. Most of the secu- to be effectively implemented without requiring kernel rity projects were only interested in further restricting patches. LSM also permits the existing security func- access, i.e. being able to deny accesses that would or- tionality of POSIX.1e capabilities to be cleanly sepa- dinarily be granted by the existing Linux discretionary rated from the base kernel. This allows users with spe- access control (DAC) logic. However, a few projects cialized needs, such as embedded system developers, to wanted the ability to grant accesses that would ordinar- reduce security features to a minimum for performance. ily be denied by the existing DAC logic; some degree It also enables development of POSIX.1e capabilities to of this permissive behavior was needed to support the proceed with greater independence from the base kernel. capabilities logic as a module. Some security projects wanted to migrate the DAC logic into a security module The remainder of this paper is organized as follows. so that they could replace it. Section 2 elaborates on the problem that LSM seeks to solve. Section 3 presents the LSM design. Section 4 The “LSM problem” is to unify the functional needs of presents the current LSM implementation. Section 5 de- as many security projects as possible, while minimizing scribes the operational status of LSM, including testing, the impact on the Linux kernel. The union set of desired performance overhead, and modules built for LSM so features would be highly functional, but also so invasive far. Section 6 describes issues that arose during devel- as to be unacceptable to the mainstream Linux commu- opment, and plans for future work. Section 7 describes nity. Section 3 presents the compromises LSM made to related work. Section 8 presents our conclusions. simultaneously balance these conflicting goals. 2 The Problem: Constrained Design Space 3 LSM Design: Mediate Access to Kernel Objects The design of LSM was constrained by the practical and technical concerns of both the Linux kernel developers The system call interface provides an abstraction for and the various Linux security projects. In email on the userspace to interact with the kernel, and is a tempting topic, Linus Torvalds specified that the security frame- location to mediate access. In fact, no kernel modifica- work must be: tions are required to overwrite entries in the system call lookup table, making it trivial to mediate this interface truly generic, where using a different security using kernel modules [18, 19]. While this is an attrac- • model is merely a matter of loading a different ker- tive feature, mediating the system call interface provides nel module; limited value for a general purpose security framework User Level process User space REQUEST access Permissive LSM hook open system call Kernel space no no look up inode UID match? DAC override? DENY access error checks yes yes GRANT access DAC checks LSM Module Policy Engine Examine context. "OK with you?" Does request pass policy? LSM hook Yes or No Figure 2: Permissive LSM hook. This hook allows the security Grant or deny. policy to override a DAC restriction. access inode Figure 1: LSM Hook Architecture This limitation enabled the LSM framework to remain conceptually simple and minimally invasive while still meeting the needs of many of the security projects. It also strengthened the justification for adopting the LSM