Linux Security Module Framework Chris Wright and Crispin Cowan ∗ James Morris WireX Communications, Inc. Intercode Pty Ltd [email protected], [email protected] [email protected] Stephen Smalley † Greg Kroah-Hartman ‡ NAI Labs, Network Associates, Inc. IBM Linux Technology Center [email protected] [email protected] Abstract sign and implementation of the LSM frame- work, a discussion of performance and secu- Computer security is a chronic and growing rity impact on the kernel, and a brief overview problem, even for Linux, as evidenced by the of existing security modules. seemingly endless stream of software security vulnerabilities. Security research has produced numerous access control mechanisms that help 1 Introduction improve system security; however, there is lit- tle consensus on the best solution. Many pow- Security is a chronic and growing problem: as erful security systems have been implemented more systems (and more money) go on line, the as research prototypes or highly specialized motivation to attack rises. Linux is not immune products, leaving systems operators with a dif- to this threat: the “many eyes make shallow ficult challenge: how to utilize these advanced bugs" argument [25] not withstanding, Linux features, without having to throw away their systems do experience a large number of soft- existing systems? ware vulnerabilities. The Linux Security Modules (LSM) project An important way to mitigate software vul- addresses this problem by providing the Linux nerabilities is through effective use of access kernel with a general purpose framework for controls. Discretionary access controls (root, access control. LSM enables loading enhanced user-IDs and mode bits) are adequate for user security policies as kernel modules. By pro- management of their own privacy, but are not viding Linux with a standard API for policy sufficient to protect systems from attack. Ex- enforcement modules, the LSM project hopes tensive research in non-discretionary access to enable widespread deployment of security control models has been done for over thirty hardened systems. This paper presents the de- years [2, 26, 18, 10, 16, 5, 20] but there has ∗This work supported in part by DARPA Contract been no real consensus on which is the one N66001-00-C-8032 (Autonomix) true access control model. Because of this lack † This work supported by NSA Contract MDA904- of consensus, there are many patches to the 01-C-0926 (SELinux) ‡This work represents the view of the authors and Linux kernel that provide enhanced access con- does not necessarily represent the view of IBM. But that trols [7, 11, 12, 14, 17, 19, 24, 20, 32] but none sentence did. of them are a standard part of the Linux kernel. Ottawa Linux Symposium 2002 605 The Linux Security Modules (LSM) [30, 27, a different kernel module; 31] project seeks to solve this Tower of Ba- bel [1] quandary by providing a general- • conceptually simple, minimally invasive, purpose framework for security policy mod- and efficient; and ules. This allows many different access con- trol models to be implemented as loadable ker- • able to support the existing POSIX.1e nel modules, enabling multiple threads of secu- capabilities logic as an optional security rity policy engine development to proceed in- module. dependently of the main Linux kernel. A num- ber of existing enhanced access control im- To achieve these goals while remaining agnos- plementations, including POSIX.1e capabili- tic with respect to styles of access control me- ties [29], SELinux, Domain and Type Enforce- diation, LSM takes the approach of mediating ment (DTE) [14] and Linux Intrusion Detec- access to the kernel’s internal objects: tasks, tion System (LIDS) [17] have already been inodes, open files, etc., as shown in Figure 1. adapted to use the LSM framework. User processes execute system calls, which first traverse the Linux kernel’s existing logic The remainder of this paper is organized as for finding and allocating resources, perform- follows. Section 2 presents the LSM design ing error checking, and passing the classical and implementation. Section 3 gives a detailed UNIX discretionary access controls. Just be- look at the LSM interface. Section 4 describes fore the kernel attempts to access the internal the impact LSM has on performance and secu- object, an LSM hook makes an out-call to the rity, including a look at some projects that have module posing the question, “Is this access ok been ported to LSM so far. Section 5 presents with you?” The module processes this policy our conclusions. question and returns either “yes” or “no.” 2 Design and Implementation One might ask why LSM chose this approach rather than system call interposition (mediat- ing system calls as they enter the kernel) or de- At the 2001 Linux Kernel Summit, the NSA vice mediation (mediating at access to physi- presented their work on Security-Enhanced cal devices).1 The reason is that information Linux (SELinux) [19], an implementation of a critical to sound security policy decisions is flexible access control architecture in the Linux not available at those points. At the system kernel. Linus Torvalds appeared to accept that call interface, userspace data, such as a path a general access control framework for the name, has yet to be translated to the kernel Linux kernel is needed. However, given the object it represents, such as an inode. Thus, many Linux kernel security projects, and Li- system call interposition is both inefficient and nus’ lack of expertise in sophisticated security prone to time-of-check-to-time-of-use (TOCT- policy, he preferred an approach that allowed TOU) races [28, 6]. At the device interface, security models to be implemented as loadable some other critical information (such as the kernel modules. In fact, Linus’ response pro- path name of the file to be accessed) has been vided the seeds of the LSM design. The LSM thrown away. In between is where the full framework must be: context of an access request can be seen, and 1The glib answer is that the Linux kernel already pro- • truly generic, where using a different se- vides those features and there would be nothing for us to curity model is merely a matter of loading do :-) Ottawa Linux Symposium 2002 606 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 where a fully informed access control decision because some policies may explicitly con- can be made. flict [13]. On the other hand, it is clearly de- sirable to compose some combinations of se- A subtle implication of the LSM architecture curity policies. Here, LSM effectively punts to is that access control decisions are restric- the module writer: to be able to “stack” mod- 2 tive : the module can really only say “no” [31]. ules, the first module loaded must also export Functional errors and classical security checks an LSM interface to subsequent LSM modules can result in an access request being denied to be loaded. The first module is then responsi- before it is ever presented to the LSM mod- ble for composing the access control decisions ule. This is the opposite of the way manda- that it gets back from secondary modules. tory access control systems are normally im- plemented. This design choice limits the flex- ibility of the LSM framework, but substan- tially simplifies the impact of the LSM on the 3 LSM Interface Linux kernel. To do otherwise would have required implementing many instances of the same hook throughout the kernel, to ensure that Having discussed the high-level design the module is consulted at every place where a philosophies of LSM in Section 2, we now system call could “error out.” turn to the implementation of the LSM in- terface. At the core, the LSM interface is Composition of LSM modules is another prob- a large table of functions, which by default lematic issue. On the one hand, security are populated with calls that implement the policies do not compose in the general case traditional superuser DAC policy. The module 2Caveat: the capable() hook, which is needed writers are then responsible for providing to support POSIX.1e capabilities, can override DAC implementations of the functions that they checks, see Section 3.8. care about. This section provides a detailed Ottawa Linux Symposium 2002 607 analysis of those functions.3 Section 3.1 shows the LSM framework to remain simple, push- how to register a security module. Sections 3.2 ing the policy which defines composition into through 3.8 are organized by kernel object and the primary security module. discuss the LSM interface available to mediate access to each object. 3.2 Task Hooks 3.1 Policy Registration The task_struct structure is the kernel ob- The LSM interface is implemented as a struc- ject representing kernel schedulable tasks. It ture of callback methods, security_ops. contains basic task information such as user A security module is responsible for imple- and group ID, resource limits, and scheduling menting the callbacks according to the secu- policies and priorities. LSM provides a group rity policy it is enforcing. At boot time the of task hooks, task_security_ops, that security_ops structure is initialized with mediate a task’s access to this basic task in- default callbacks, which implement traditional formation. Interprocess signalling is mediated superuser semantics. by the LSM task hooks to monitor tasks’ abil- The security module can be built as a dynami- ities to send and receive signals. LSM adds a cally loadable module or statically linked into security field to the task_struct to allow the kernel.