Linux Security Module Framework 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 1 Introduction Security is a chronic and growing problem: as more Computer security is a chronic and growing prob- systems (and more money) go on line, the motiva- lem, even for Linux, as evidenced by the seem- tion to attack rises. Linux is not immune to this ingly endless stream of software security vulnera- threat: the “many eyes make shallow bugs” argu- bilities. Security research has produced numerous ment [24] not withstanding, Linux systems do expe- access control mechanisms that help improve sys- rience a large number of software vulnerabilities. tem security; however, there is little concensus on the best solution. Many powerful security systems An important way to mitigate software vulnera- have been implemented as research prototypes or bilities is through effective use of access controls. highly specialized products, leaving systems opera- Discretionary access controls (root, user-IDs and tors with a difficult challenge: how to utilize these mode bits) are adequate for user management of advanced features, without having to throw away their own privacy, but are not sufficient to pro- their existing systems? tect systems from attack. Extensive research in non-discretionary access control models has been The Linux Security Modules (LSM) project ad- done for over thirty years [1, 25, 17, 9, 15, 4, 19] dresses this problem by providing the Linux kernel but there has been no real consensus on which with a general purpose framework for access control. is the one true access control model. Because of LSM enables loading enhanced security policies as this lack of consensus, there are many patches to kernel modules. By providing Linux with a stan- the Linux kernel that provide enhanced access con- dard API for policy enforcement modules, the LSM trols [6, 10, 11, 13, 16, 18, 23, 19, 31] but none of project hopes to enable widespread deployment of them are a standard part of the Linux kernel. security hardened systems. This paper presents the design and implementation of the LSM framework, The Linux Security Modules (LSM) [29, 26, 30] a discussion of performance and security impact on project seeks to solve this Tower of Babel quandry the kernel, and a brief overview of existing security by providing a general purpose framework for se- modules. curity policy modules. This allows many different access control models to be implemented as load- able kernel modules, enabling multiple threads of security policy engine development to proceed inde- pendently of the main Linux kernel. A number of existing enhanced access control implementations, including POSIX.1e capabilities [28], SELinux, Do- ∗ This work supported in part by DARPA Contract main and Type Enforcement (DTE) [13] and Linux N66001-00-C-8032 (Autonomix) †This work supported by NSA Contract MDA904-01-C- Intrusion Detection System (LIDS) [16] have al- 0926 (SELinux) ready been adapted to use the LSM framework. The remainder of this paper is organized as follows. calls as they enter the kernel) or device mediation Section 2 presents the LSM design and implemen- (mediating at access to physical devices).1 The rea- tation. Ssection 3 gives a detailed look at the LSM son is that information critical to sound security pol- interface. Section 4 describes the impact LSM has icy decisions is not available at those points. At the on permformance and security, including a look at system call interface, userspace data, such as a path some projects that have been ported to LSM so far. name, has yet to be translated to the kernel object Section 5 presents our conclusions. it represents, such as an inode. Thus, system call interpostion is both inefficient and prone to time-of- check-to-time-of-use (TOCTTOU) races [27, 5]. At the device interface, some other critical information 2 Design and Implementation (such as the path name of the file to be accessed) has been thrown away. In between is where the full context of an access request can be seen, and where At the 2001 Linux Kernel Summit, the NSA pre- a fully informed access control decision can be made. sented their work on Security-Enhanced Linux (SELinux) [18], an implementation of a flexible ac- A subtle implication of the LSM architecture is that cess control architecture in the Linux kernel. Li- access control decisions are restrictive2: the module nus Torvalds appeared to accept that a general can really only ever say “no” [30]. Functional errors access control framework for the Linux kernel is and classical security checks can result in an access needed. However, given the many Linux kernel se- request being denied before it is ever presented to curity projects, and Linus’ lack of expertise in so- the LSM module. This is the opposite of the way phisticated security policy, he preferred an approach mandatory access control systems are normally im- that allowed security models to be implemented as plemented. This design choice limits the flexibility loadable kernel modules. In fact, Linus’ response of the LSM framework, but substantially simplifies provided the seeds of the LSM design. The LSM the impact of the LSM on the Linux kernel. To do framework must be: otherwise would have required implementing many instances of the same hook throughout the kernel, to ensure that the module is consulted at every place • truly generic, where using a different security where a system call could “error out.” model is merely a matter of loading a different kernel module; Composition of LSM modules is another problem- • conceptually simple, minimally invasive, and atic issue. On the one hand, security policies do not efficient; and compose in the general case because some policies may explicitly conflict [12]. On the other hand, it • able to support the existing POSIX.1e capabil- is clearly desirable to compose some combinations ities logic as an optional security module. of security policies. Here, LSM effectively punts to the module writer: to be able to “stack” modules, To achieve these goals, while remaining agnostic the first module loaded must also export an LSM with respect to styles of access control mediation, interface to subsequent LSM modules to be loaded. LSM takes the approach of mediating access to the The first module is then responsible for composing kernel’s internal objects: tasks, inodes, open files, the access control decisions that it gets back from etc., as shown in Figure 1. User processes execute secondary modules. system calls, which first traverse the Linux kernel’s existing logic for finding and allocating resources, performing error checking, and passing the classi- cal Unix discretionary access controls. Just before the kernel would access the internal object, an LSM hook makes an out-call to the module posing the question “Is this access ok with you?” The mod- ule processes this policy question and returns either “yes” or “no.” 1The glib answer is the Linux kernel already provides those features and there would be nothing for us to do :-) 2Caveat: the capable() hook, which is needed to sup- One might ask why LSM chose this approach rather port POSIX.1e capabilities, can override DAC checks, see than system call interposition (mediating system Setion 3.7. User Level process User space open system call Kernel space Look up inode error checks LSM Module DAC checks Policy Engine "OK with you?" Examine context LSM hook Does request pass policy? Yes or No Grant or deny Complete request Access inode Figure 1: LSM Hook Architecture 3 LSM Interface policies to label a task with a policy specific security label. Having discussed the high-level design philosophies The LSM task hooks have full task life-cycle cov- of LSM in Section 2 we now turn to the implementa- erage. The create() task hook is called verifying tion of the LSM interface. At the core, the LSM in- that a task can spawn children. If this is successful, terface is a large table of functions, which by default a new task is created and the alloc security() are populated with calls that implement the tradi- task hook is used to manage the new task’s security tional superuser DAC policy. The module writer field. When a task exits, the kill() task hook is is then responsible for providing implementations consulted to verify that the task can signal its par- of the functions that they care about. This section ent. Similarly, the wait() task hook is called in the provides a detailed analysis of those functions.3 Sec- parent task context, verifying the parent task can tions 3.1 through 3.7 are organized by kernel object receive the child’s signal. And finally, the task’s se- and discuss the LSM interface available to mediate curity field is released by the free security() task access to each object. hook. During the life of a task it may attempt to change 3.1 Task Hooks some of its basic task information. For example a task may call setuid(2). This is, of course, man- aged by LSM with a corresponding setuid() task The task struct structure is the kernel object hook. If this is successful the kernel updates the representing kernel schedulable tasks. It contains task’s user identity and then notifies the policy mod- basic task information such as: user and group ule via the post setuid() task hook. The notifi- id, resource limits, and scheduling policies and cation allows the module to update state, and for priorites.