Check out the new USENIX Web site. next up previous
Next: The Problem: Constrained Design Up: Linux Security Modules: General Previous: Linux Security Modules: General


Introduction

The critical role of operating system protection mechanisms in providing system security has been well-understood for over thirty years, yet the access control mechanisms of existing mainstream operating systems are still inadequate to provide strong security [2,39,28,17,26,6,30]. Although many enhanced access control models and frameworks have been proposed and implemented [9,1,4,41,23,10,29,37], mainstream operating systems typically still lack support for these enhancements. In part, the absence of such enhancements is due to a lack of agreement within the security community on the right general solution.

Like many other general-purpose operating systems, the Linux kernel only provides discretionary access controls and lacks any direct support for enhanced access control mechanisms. However, Linux has long supported dynamically loadable kernel modules, primarily for device drivers, but also for other components such as filesystems. In principle, enhanced access controls could be implemented as Linux kernel modules, permitting many different security models to be supported.

In practice, creating effective security modules is problematic since the kernel does not provide any infrastructure to allow kernel modules to mediate access to kernel objects. As a result, kernel modules typically resort to system call interposition to control kernel operations [18,20], which has serious limitations as a method for providing access control [41]. Furthermore, these kernel modules often require reimplementing selected kernel functionality [18,20] or require a patch to the kernel to support the module [10,3,15], reducing much of the value of modular composition. Hence, many projects have implemented enhanced access control frameworks or models for the Linux kernel as kernel patches [29,37,23,32,27].

At the Linux Kernel 2.5 Summit, the NSA presented their work on Security-Enhanced Linux (SELinux) [29], an implementation of a flexible access control architecture in the Linux kernel, and emphasized the need for such support in the mainstream Linux kernel. Linus Torvalds appeared to accept that a general access control framework for the Linux kernel is needed, but favored a new infrastructure that would provide the necessary support to kernel modules for implementing security. This approach would avoid the need to choose among the existing competing projects.

In response to Linus' guidance, the Linux Security Modules (LSM) [45,40] project has developed a lightweight, general purpose, access control framework for the mainstream Linux kernel that enables many different access control models to be implemented as loadable kernel modules. A number of existing enhanced access control implementations, including POSIX.1e capabilities [42], SELinux, and Domain and Type Enforcement (DTE) [23], have already been adapted to use the LSM framework.

The LSM framework meets the goal of enabling many different security models with the same base Linux kernel while minimally impacting the Linux kernel. The generality of LSM permits enhanced access controls to be effectively implemented without requiring kernel patches. LSM also permits the existing security functionality of POSIX.1e capabilities to be cleanly separated from the base kernel. This allows users with specialized needs, such as embedded system developers, to reduce security features to a minimum for performance. It also enables development of POSIX.1e capabilities to proceed with greater independence from the base kernel.

The remainder of this paper is organized as follows. Section 2 elaborates on the problem that LSM seeks to solve. Section 3 presents the LSM design. Section 4 presents the current LSM implementation. Section 5 describes the operational status of LSM, including testing, performance overhead, and modules built for LSM so far. Section 6 describes issues that arose during development, and plans for future work. Section 7 describes related work. Section 8 presents our conclusions.


next up previous
Next: The Problem: Constrained Design Up: Linux Security Modules: General Previous: Linux Security Modules: General
Chris Wright 2002-05-13