Download General Security Support for the Linux Kernel and more Summaries Logic in PDF only on Docsity!
Linux Security Modules:
General Security Support for the Linux Kernel
Chris Wright and Crispin Cowan ∗
WireX Communications, Inc.
James Morris
Intercode Pty Ltd
Stephen Smalley †
NAI Labs, Network Associates, Inc.
Greg Kroah-Hartman ‡
IBM Linux Technology Center
August 17, 2002
Abstract
The access control mechanisms of existing mainstream operating systems are inadequate to provide strong sys- tem security. Enhanced access control mechanisms have failed to win acceptance into mainstream operating sys- tems due in part to a lack of consensus within the se- curity community on the right solution. Since general- purpose operating systems must satisfy a wide range of user requirements, any access control mechanism inte- grated into such a system must be capable of supporting many different access control models. The Linux Secu- rity Modules (LSM) project has developed a lightweight, general purpose, access control framework for the main- stream 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 Linux capabilities, Security- Enhanced Linux (SELinux), and Domain and Type En- forcement (DTE), have already been adapted to use the LSM framework. This paper presents the design and implementation of LSM and discusses the challenges in providing a truly general solution that minimally im- pacts the Linux kernel.
∗This work supported in part by DARPA Contract N66001-00-C- 8032 (Autonomix) †This work supported by NSA Contract MDA904-01-C- (SELinux) ‡This work represents the view of the authors and does not neces- sarily represent the view of IBM.
1 Introduction
The critical role of operating system protection mech- anisms 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, 37, 27, 16, 25, 6, 29]. Although many enhanced access control models and frameworks have been proposed and imple- mented [9, 1, 4, 39, 22, 10, 28, 35], mainstream oper- ating systems typically still lack support for these en- hancements. In part, the absence of such enhancements is due to a lack of agreement within the security com- munity 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 dy- namically loadable kernel modules, primarily for device drivers, but also for other components such as filesys- tems. 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 prob- lematic since the kernel does not provide any infrastruc- ture to allow kernel modules to mediate access to ker- nel objects. As a result, kernel modules typically re- sort to system call interposition to control kernel op- erations [17, 19], which has serious limitations as a method for providing access control [39]. Furthermore, these kernel modules often require re-implementing se- lected kernel functionality [17, 19] or require a patch to the kernel to support the module [10, 3, 14], reduc- ing much of the value of modular composition. Hence,
many projects have implemented enhanced access con- trol frameworks or models for the Linux kernel as kernel patches [28, 35, 22, 31, 26].
At the Linux Kernel 2.5 Summit, the NSA presented their work on Security-Enhanced Linux (SELinux) [28], an implementation of a flexible access control architec- ture in the Linux kernel, and emphasized the need for such support in the mainstream Linux kernel. Linus Tor- valds 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 sup- port to kernel modules for implementing security. This approach would avoid the need to choose among the ex- isting competing projects.
In response to Linus’ guidance, the Linux Security Mod- ules (LSM) [43, 38] project has developed a lightweight, general purpose, access control framework for the main- stream Linux kernel that enables many different ac- cess control models to be implemented as loadable ker- nel modules. A number of existing enhanced access control implementations, including POSIX.1e capabil- ities [40], SELinux, and Domain and Type Enforcement (DTE) [22], 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 ker- nel 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 func- tionality of POSIX.1e capabilities to be cleanly sepa- rated from the base kernel. This allows users with spe- cialized 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 de- scribes the operational status of LSM, including testing, performance overhead, and modules built for LSM so far. Section 6 describes issues that arose during devel- opment, and plans for future work. Section 7 describes related work. Section 8 presents our conclusions.
2 The Problem: Constrained Design Space
The design of LSM was constrained by the practical and technical concerns of both the Linux kernel developers and the various Linux security projects. In email on the topic, Linus Torvalds specified that the security frame- work must be:
- truly generic, where using a different security model is merely a matter of loading a different ker- nel module;
- conceptually simple, minimally invasive, and effi- cient; and
- able to support the existing POSIX.1e capabilities logic as an optional security module.
The various Linux security projects were primarily inter- ested in ensuring that the security framework would be adequate to permit them to re-implement their existing security functionality as a loadable kernel module. The new modular implementation must not cause any signif- icant loss in the security being provided and should have little additional performance overhead.
The core functionality for most of these security projects was access control. However, a few security projects also desired other kinds of security functionality, such as security auditing or virtualized environments. Further- more, there were significant differences over the range of flexibility for the access controls. Most of the secu- rity projects were only interested in further restricting access, i.e. being able to deny accesses that would or- dinarily be granted by the existing Linux discretionary access control (DAC) logic. However, a few projects wanted the ability to grant accesses that would ordinar- ily be denied by the existing DAC logic; some degree of this permissive behavior was needed to support the capabilities logic as a module. Some security projects wanted to migrate the DAC logic into a security module so that they could replace it.
The “LSM problem” is to unify the functional needs of as many security projects as possible, while minimizing the impact on the Linux kernel. The union set of desired features would be highly functional, but also so invasive as to be unacceptable to the mainstream Linux commu- nity. Section 3 presents the compromises LSM made to simultaneously balance these conflicting goals.
check, and allow the module to override the DAC restric- tion. Figure 2 shows a user access request where a failed user ID check can be overidden by a permissive hook. These hooks are limited to the extent that the kernel al- ready consults the POSIX.1e capable() function.
Although LSM was not designed to explicitly sup- port security auditing, some forms of auditing can be supported using the features provided for access con- trol. For example, many of the existing Linux security projects provide support for auditing the access checks performed by their access controls. LSM also enables support for this kind of auditing. Some security auditing can also be supported via existing kernel modules by in- terposing on system calls, as in the SNARE project [24].
Many security models require binding security attributes to kernel objects. To facilitate this, LSM provides for opaque security fields that are attached to various in- ternal kernel objects (detailed in Section 4.1.1). How- ever, the module is completely responsible for manag- ing these fields, including allocation, deallocation, and concurrency control.
Finally, module composition presented a challenge to the LSM design. On the one hand, there clearly is a need to compose some modules with complementary func- tionality. On the other hand, fully generic security pol- icy composition is known to be intractable [20]. There- fore, LSM permits module stacking, but pushes most of the work to the modules themselves. A module that wishes to be stackable must itself export an LSM-like in- terface, and make calls to subsequently loaded modules when appropriate. The first module loaded has ultimate control over all decisions, determining when to call any other modules and how to combine their results.
4 Implementation
This section describes the implementation of the LSM kernel patch. It begins with an overview of the imple- mentation that describes the types of changes made to the kernel in Section 4.1. Sections 4.2 through 4.7 dis- cuss the specific hooks for the various kernel objects or subsystems.
STRUCTURE OBJECT task struct Task (Process) linux binprm Program super block Filesystem inode Pipe, File, or Socket file Open File sk buff Network Buffer (Packet) net device Network Device kern ipc perm Semaphore, Shared Memory Segment, or Message Queue msg msg Individual Message
Table 1: Kernel data structures modified by the LSM kernel patch and the corresponding abstract objects.
4.1 Implementation Overview
The LSM kernel patch modifies the kernel in five pri- mary ways. First, it adds opaque security fields to cer- tain kernel data structures, described in Section 4.1.1. Second, the patch inserts calls to security hook func- tions at various points within the kernel code, described in Section 4.1.2. Third, the patch adds a generic secu- rity system call, described in Section 4.1.3. Fourth, the patch provides functions to allow kernel modules to reg- ister and unregister themselves as security modules, de- scribed in Section 4.1.4. Finally, the patch moves most of the capabilities logic into an optional security module, described in Section 4.1.5.
4.1.1 Opaque Security Fields
The opaque security fields are void* pointers, which enable security modules to associate security informa- tion with kernel objects. Table 1 shows the kernel data structures that are modified by the LSM kernel patch and the corresponding abstract object.
The setting of these security fields and the management of the associated security data is handled by the secu- rity modules. LSM merely provides the fields and a set of calls to security hooks that can be implemented by the module to manage the security fields as desired. For most kinds of objects, an alloc security hook and a free security hook are defined that permit the se- curity module to allocate and free security data when the corresponding kernel data structure is allocated and freed. Other hooks are provided to permit the security module to update the security data as necessary, e.g. a post lookup hook that can be used to set security data for an inode after a successful lookup operation. It is important to note that LSM does not provide any
locking for the security fields; such locking must be per- formed by the security module.
Since some objects will exist prior to the initialization of a security module, even if the module is built into the kernel, a security module must handle pre-existing objects. Several approaches are possible. The simplest approach is to ignore such objects, treating them as be- ing outside of the control of the module. These objects would then only be controlled by the base Linux access control logic. A second approach is to traverse the kernel data structures during module initialization, setting the security fields for all pre-existing objects at this time. This approach would require great care to ensure that all objects are updated (e.g. an open file might be on a UNIX domain socket awaiting receipt by a process) and to ensure that appropriate locking is performed. A third approach is to test for pre-existing objects on each use and to then set the security field for pre-existing objects when needed.
4.1.2 Calls to Security Hook Functions
As discussed in the previous subsection, LSM provides a set of calls to security hooks to manage the security fields of kernel objects. It also provides a set of calls to security hooks to mediate access to these objects. Both sets of hook functions are called via function pointers in a global security ops table. This structure consists of a collection of substructures that group related hooks based on kernel object or subsystem, as well as some top-level hooks, for system operations. Each hook is de- fined in terms of kernel objects and parameters, and care has been taken to avoid userspace pointers.
Figure 3 shows the vfs mkdir kernel function after the LSM kernel patch has been applied. This kernel func- tion is used to create new directories. Two calls to secu- rity hook functions have been inserted into this function. The first hook call, security ops->inode ops-
mkdir, can be used to control the ability to create new directories. If the hook returns an error status, then the new directory will not be created and the error status will be propagated to the caller. The second hook call, se- curity ops->inode ops->post mkdir, can be used to set the security field for the new directory’s in- ode structure. This hook can only update the security module’s state; it cannot affect the return status.
Although LSM also inserts a hook call into the Linux kernel permission function, the permission hook is insufficient to control file creation operations because
int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode) { int error;
down(&dir->i_zombie); error = may_create(dir, dentry); if (error) goto exit_lock;
error = -EPERM; if (!dir->i_op || !dir->i_op->mkdir) goto exit_lock;
mode &= (S_IRWXUGO|S_ISVTX); error = <-> security_ops->inode_ops->mkdir(dir, dentry, mode); if (error) goto exit_lock; DQUOT_INIT(dir); lock_kernel(); error = dir->i_op->mkdir(dir, dentry, mode); unlock_kernel();
exit_lock: up(&dir->i_zombie); if (!error) { inode_dir_notify(dir, DN_CREATE); <-> security_ops->inode_ops->post_mkdir(dir, dentry, mode); } return error; }
Figure 3: The vfs mkdir kernel function with one security hook call to mediate access and one security hook call to manage the security field. The security hooks are marked by<->.
an optional security module, as mentioned in Section 2. POSIX.1e capabilities provides a mechanism for par- titioning traditional superuser privileges and assigning them to particular processes.
By nature, privilege granting is a permissive form of ac- cess control, since it grants an access that would ordi- narily be denied. Consequently, the LSM framework had to provide a permissive interface with at least the same granularity of the Linux capabilities implementa- tion. LSM retains the existing capable interface used within the kernel for performing capability checks, but reduces the capable function to a simple wrapper for a LSM hook, allowing any desired logic to be imple- mented in the security module. This approach allowed LSM to leverage the numerous (more than 500) existing kernel calls to capable and to avoid pervasive changes to the kernel. LSM also defines hooks to allow the logic for other forms of capability checking and capabil- ity computations to be encapsulated within the security module.
A process capability set, a simple bit vector, is stored in the task struct structure. Because LSM adds an opaque security field to the task struct and hooks to manage the field, it would be possible to move the existing bit vector into the field. Such a change would be logical under the LSM framework but this change has not been implemented in order to ease stacking with other modules. One of the difficulties of stacking se- curity modules in the LSM framework is the need to share the opaque security fields. Many security modules will want to stack with the capabilities module, because the capabilities logic has been integrated into the main- stream kernel for some time and is relied upon by some applications such as named and sendmail. Leaving the capability bit vector in the task struct eases this composition at the cost of wasted space for modules that don’t need to use it.
The Linux kernel support for capabilities also includes two system call calls: capset and capget. To remain compatible with existing applications, these system calls are retained by LSM but the core capabilities logic for these functions has been replaced by calls to LSM hooks. Ultimately, these calls should be reimplemented via the security system call. This change should have little impact on applications since the portable interface for capabilities is through the libcap library rather than direct use of these calls.
The LSM project has developed a capabilities security module and migrated much of the core capabilities logic into it; however, the kernel still shows vestiges of the
pre-existing Linux capabilities. Moving the bit vector from the task struct proper to the opaque security field and relocating the system call interface are the only major steps left to making the capability module com- pletely standalone.
4.2 Task Hooks
LSM provides a set of task hooks that enable security modules to manage process security information and to control process operations. Modules can maintain pro- cess security information using the security field of the task struct structure. Task hooks provide control over inter-process operations, such as kill, as well as control over privileged operations on the current pro- cess, such as setuid. The task hooks also provide fine-grained control over resource management opera- tions such as setrlimit and nice.
4.3 Program Loading Hooks
Many security modules, including Linux capabilities, DTE, SELinux, and SubDomain require the ability to perform changes in privilege when a new program is ex- ecuted. Consequently, LSM provides a set of program- loading hooks that are called at critical points during the processing of an execve operation. The security field of the linux binprm structure permits modules to maintain security information during program load- ing. One hook is provided to permit security modules to initialize this security information and to perform access control prior to loading the program, and a second hook is provided to permit modules to update the task security information after the new program has been successfully loaded. These hooks can also be used to control inher- itance of state across program executions, for example, revalidating open file descriptors.
4.4 IPC Hooks
Security modules can manage security information and perform access control for System V IPC using the LSM IPC hooks. The IPC object data structures share a com- mon substructure, kern ipc perm, and only a pointer to this substructure is passed to the existing ipcperms function for checking permissions. Hence, LSM adds a security field to this shared substructure. To support security information for individual messages, LSM also adds a security field to the msg msg structure.
LSM inserts a hook into the existing ipcperms func- tion so that a security module can perform a check for each existing Linux IPC permission check. However, since these checks are not sufficient for some security modules, LSM also inserts hooks into the individual IPC operations. These hooks provide more detailed informa- tion about the type of operation and the specific argu- ments. They also support fine-grained control over indi- vidual messages sent via System V message queues.
4.5 Filesystem Hooks
For file operations, three sets of hooks were defined: filesystem hooks, inode hooks, and file hooks. LSM adds a security field to each of the associated kernel data structures: super block, inode, and file. The filesystem hooks enable security modules to con- trol operations such as mounting and statfs. LSM leverages the existing permission function by insert- ing an inode hook into it, but LSM also defines a num- ber of other inode hooks to provide finer-grained control over individual inode operations. Some of the file hooks allow security modules to perform additional checking on file operations such as read and write, for exam- ple, to revalidate permissions on use to support privi- lege bracketing or dynamic policy changes. A hook is also provided to allow security modules to control re- ceipt of open file descriptors via socket IPC. Other file hooks provide finer-grained control over operations such as fcntl and ioctl.
An alternative to placing security fields in the inode and super block structures would have been to place them in the dentry and vfsmount structures. The inode and super block structures correspond to the actual objects and are independent of names and names- paces. The dentry and vfsmount structures con- tain a reference to the corresponding inode or su- per block, and are associated with a particular name or namespace. Using the first pair of structures avoids object aliasing issues. The use of these structures also provides more coverage of kernel objects, since these structures also represent non-file objects such as pipes and sockets. These data structures are also readily avail- able at any point in the filesystem code, whereas the sec- ond set of structures is often unavailable.
4.6 Network Hooks
Application layer access to networking is mediated us- ing a set of socket hooks. These hooks, which in-
clude the interposition of all socket system calls, provide coarse mediation coverage of all socket-based protocols. Since active user sockets have an associated inode structure, a separate security field was not added to the socket structure or to the lower-level sock structure. As the socket hooks allow general mediation of net- work traffic in relation to processes, LSM significantly expands the kernel’s network access control framework (which is already handled at the network layer by Netfil- ter [34]). For example, the sock rcv skb hook allows an inbound packet to be mediated in terms of its destina- tion application, prior to being queued at the associated userspace socket.
Additional finer-grained hooks have been implemented for the IPv4, UNIX domain, and Netlink protocols, which were considered essential for the implementation of a minimally useful system. Similar hooks for other protocols may be implemented at a later stage.
Network data traverses the stack in packets encapsulated by an sk buff (socket buffer) structure. LSM adds a security field to the sk buff structure, so that security state may be managed across network layers on a per- packet basis. A set of sk buff hooks is provided for lifecycle management of this security field.
Hardware and software network devices are encapsu- lated by a net device structure. A security field was added to this structure so that security state can be main- tained on a per-device basis.
Coverage of low level network support components, such as routing tables and traffic classifiers is somewhat limited due to the invasiveness of the code which would be required to implement consistent fine-grained hooks. Access to these objects can be mediated at higher levels (for example, using ioctl), although granularity may be reduced by TOCTTOU issues.
4.7 Other Hooks
LSM provides two additional sets of hooks: module hooks and a set of top-level system hooks. Module hooks can be used to control the kernel operations that create, initialize, and delete kernel modules. System hooks can be used to control system operations, such as setting the system hostname, accessing I/O ports, and configuring process accounting. The existing Linux kernel provides some control over many of these operations using the capability checks, but those checks only provide coarse- grained distinctions among different operations and do
Process tests, times in μseconds, smaller is better: %overhead test type 2.5.2 2.5.2-lsm with LSM null call 0.50 0.49 -2.0% null I/O 0.82 0.84 2.4% stat 5.95 6.34 6.2% open/close 7.59 8.13 6.6% sig inst 1.26 1.25 -0.8% sig handl 3.86 3.92 1.5% fork proc 155 157 1.3% exec proc 917 924 0.8% sh proc 3834 3881 1.2% File and VM system latencies in μseconds, smaller is better: %overhead test type 2.5.2 2.5.2-lsm with LSM 0K file create 40 40 0% 0K file delete 6.737 7.258 7.2% 10K file create 104 105 0.1% 10K file delete 24 25 4.0% mmap latench 2641 2699 2.1% prot fault 1.014 0.985 -2.9% page fault 3.00 3.00 0% Local communication bandwidth in MB/s, larger is better: %overhead test type 2.5.2 2.5.2-lsm with LSM TCP bandwidth 216 219 -1.4% file reread 309 311 -0.6% mmap reread 368 372 -1.1% bcopy (libc) 191 195 -2.1% bcopy (hand) 149 158 -6.0% mem read 368 371 -0.8% mem write 197 201 -2.0%
Table 2: LMBench Microbenchmarks, 4 processor machine
Section 5.2.2.
5.2.2 Macrobenchmark: Kernel Compilation
Our macrobenchmark is the widely used kernel compi- lation benchmark, measuring the time to build the Linux kernel. We ran this test on both a single processor ma- chine (433 MHz Pentium 3, 128 MB RAM, IDE disk), and a 4-processor SMP (four 700 MHh Xeon processors, 1 GB RAM, ultra wide SCSI disk).
The single processor test executed the command time make -j2 bzImage and the 4-processor test ex- ecuted the command time make -j8 bzImage,
Process tests, times in μseconds, smaller is better: %overhead test type 2.5.2 2.5.2-lsm with LSM null call 0.70 0.72 2.7% null I/O 1.06 1.08 1.9% stat 45.9 46.8 1.9% open/close 47.5 48.6 2.3% sig inst 1.95 1.94 -0.5% sig handl 8.39 8.53 1.6% fork proc 455 459 0.9% exec proc 2024 2010 -0.7% sh proc 10000 9980 -0.2% File and VM system latencies in μseconds, smaller is better: %overhead test type 2.5.2 2.5.2-lsm with LSM 0K file create 111.6 113.2 1.4% 0K file delete 52.1 53.7 3.0% 10K file create 235.6 237.0 0.6% 10K file delete 71.1 72.2 1.5% mmap latench 469.0 437.0 -7.3% prot fault 1.497 1.520 1.5% page fault 4.75 4.25 -11.8% Local communication bandwidth in MB/s, larger is better: %overhead test type 2.5.2 2.5.2-lsm with LSM TCP bandwidth anomaly anomaly % file reread 149.0 148.8 0.1% mmap reread 247.4 247.4 0% bcopy (libc) 110.1 110.8 -0.6% bcopy (hand) 109.3 109.8 -0.5% mem read 247 247 0% mem write 153.2 153.6 -0.2%
Table 3: LMBench Microbenchmarks, 1 processor machine
with the results shown in Table 4. In all cases, the LSM kernel performed slightly better than the non-LSM ker- nel. As in our microbenchmark experiments in Sec- tion 5.2.1, we regard this as experimental error, and claim only that LSM overhead at the application level is not significant.
6 Discussion
Given that LSM set out to satisfy the needs of a collec- tion of other independent projects, it is understandable that the result produced some emergent properties.
%overhead Machine type 2.5.2 2.5.2-lsm with LSM 4 CPUs 98.38 98.26 -0.1% 1 CPU 659.36 649.78 -1.5%
Table 4: Linux Kernel Build Macrobenchmarks, time in seconds
Many security models require some way to associate se- curity attributes to system objects. Thus LSM attaches security fields to many internal kernel objects so that modules may attach and later reference the security at- tributes associated with those objects.
It is also desirable to persistently bind security attributes to files. To do so seamlessly requires extended attribute file system support, which enables security attributes to be bound to files on disk. However, supporting extended attributes is a complex issue, requiring both support for extended attributes in the filesystem [21], and support for extended attributes in the Linux kernel’s VFS layer. Rather than make LSM dependent on non-existent ker- nel features, we plan to add full extended attribute sup- port to LSM when extended attributes are added to the Linux kernel. Until then, modules that need persistent extended attributes can resort to meta-files [42, 28].
In attempting to provide a pluggable interface for secu- rity enhancements, it is tempting to consider completely modularizing all security policy decisions, i.e. move all kernel logic concerning access control out of the kernel and into a default module. This approach has significant benefits beyond simple modular consistency: in particu- lar, it would make it much easier to provide authoritative hooks instead of restrictive hooks, which in turn would enable a broader variety of modules (see Section 3).
However, we chose not to modularize all security deci- sions, for pragmatic reasons. Current Linux access con- trol decisions are not well isolated in the kernel; they are mingled with other error checking and transforma- tion logic. Thus a patch to the Linux kernel to remove all access control logic would be highly invasive. Im- plementing such a change would almost certainly entail security bugs, which would not be an auspicious way to introduce LSM to the greater Linux community.
Therefore, we deferred the complete modularization of all access control logic. The current LSM implements much less invasive restrictive hooks, providing a min- imally invasive patch for initial introduction into the Linux community. Once LSM is well established, we may revisit this decision, and propose a more radical modularization architecture.
Finally, in designing the LSM interface, we were dis- tinctly aware that LSM constitutes an API, and thus must present a logically consistent view to the programmer. The LSM interface constitutes not only the set of hooks needed by the modules we intended to support, but also the logical extension of such hooks, such that the inter- face is regular. Where possible, special cases were gen- eralized so that they were no longer special.
7 Related Work
Section 7.1 describes the general area of extensible ker- nels in the LSM context, and Section 7.2 describes work specifically related to generic access control frame- works.
7.1 Extensible Kernel Research
There has been a lot of operating systems research in the last 20 years on extensible systems. Following the ba- sic idea of microkernels (which sought to componentize most everything in the kernel) came extensive efforts to build more monolithic kernels that could be extended in various ways:
- Exokernel was really just a logical extension of the microkernel concept [15]. The base kernel pro- vided no abstraction of physical devices, leaving that to applications that needed the devices.
- SPIN allowed modules to be loaded into the ker- nel, while providing for a variety of safety prop- erties [7]. Modules were to be written in Modula- 3 [33], which imposed strong type checking, thus preventing the module from mis-behaving outside of its own data structures. SPIN “spindles” also were subject to time constraints, so they could not seize the CPU. Abstractly, spindles would regis- ter to “extend” or “specialize” kernel events, and would be added to an event handling chain, rather similar to the way interrupts are commonly han- dled.
- SCOUT was designed to facilitate continuous flows of information (e.g. audio or video streams), and allowed CODEC stages to be composed into pipelines (or graphs) of appropriate compo- nents [32].
like SELinux or RSBAC, this approach introduces a new level of indirection, so that even the general access con- trol architecture and the file labeling support would be encapsulated within the module rather than being di- rectly integrated into the kernel.
8 Conclusions
The Linux kernel supports the classical UNIX security policies of mode bits, and a partial implementation of the draft POSIX.1e “capabilities” standard, which in many cases is not adequate. The combination of open source code and broad popularity has made Linux a popular tar- get for enhanced security projects. While this works , in that many powerful security enhancements are available, it presents a significant barrier to entry for users who are unable or unwilling to deploy custom kernels.
The Linux Security Modules (LSM) project exists to ease this barrier to entry by providing a standard load- able module interface for security enhancements. We presented the motivation, design, and implementation of the LSM interface. LSM provides an interface that is rich enough to enable a wide variety of security mod- ules, while imposing minimal disturbance to the Linux source code, and minimal performance overhead on the Linux kernel. Several robust security modules are al- ready available for LSM.
LSM is currently implemented as a patch to the standard Linux kernel. A patch is being maintained for the latest versions of the 2.4 stable series and the 2.5 development series. The goal of the LSM project is for the patch to be adopted into the standard Linux kernel as part of the 2.5 development series, and eventually into most Linux distributions.
References
[1] Marshall D. Abrams, Leonard J. LaPadula, Kenneth W. Eggers, and Ingrid M. Olson. A generalized framework for access con- trol: An informal description. In Proceedings of the 13th Na- tional Computer Security Conference , pages 135–143, October
[2] J. Anderson. Computer Security Technology Planning Study. Report Technical Report ESD-TR-73-51, Air Force Elect. Sys- tems Div., October 1972. [3] Argus Systems. PitBull LX. http://www. argus-systems.com/product/white_paper/lx.
[4] L. Badger, D.F. Sterne, and et al. Practical Domain and Type Enforcement for UNIX. In Proceedings of the IEEE Symposium on Security and Privacy , Oakland, CA, May 1995. [5] Lee Badger, Daniel F. Sterne, David L. Sherman, Kenneth M. Walker, and Sheila A. Haghighat. A Domain and Type Enforce- ment UNIX Prototype. In Proceedings of the USENIX Security Conference , 1995. [6] D. Baker. Fortresses built upon sand. In Proceedings of the New Security Paradigms Workshop , 1996. [7] Brian N. Bershad, Stefan Savage, Przemysław Pardyak, Emin G¨un Sirer, Marc Fiuczynski, David Becker, Susan Eggers, and Craig Chambers. Extensibility, Safety and Performance in the SPIN Operating System. In Symposium on Operating Sys- tems Principles (SOSP) , Copper Mountain, Colorado, December
[8] M. Bishop and M. Digler. Checking for Race Conditions in File Accesses. Computing Systems , 9(2):131–152, Spring 1996. Also available at http://olympus.cs.ucdavis.edu/ ˜bishop/scriv/index.html. [9] W.E. Boebert and R.Y. Kain. A Practical Alternative to Hier- archical Integrity Policies. In Proceedings of the 8th National Computer Security Conference , Gaithersburg, MD, 1985. [10] Crispin Cowan, Steve Beattie, Calton Pu, Perry Wagle, and Virgil Gligor. SubDomain: Parsimonious Server Security. In USENIX 14th Systems Administration Conference (LISA) , New Orleans, LA, December 2000. [11] Crispin Cowan, Andrew Black, Charles Krasic, Calton Pu, Jonathan Walpole, Charles Consel, and Eugen-Nicolae Volan- schi. Specialization Classes: An Object Framework for Special- ization. In Proceedings of the Fifth International Workshop on Object-Orientation in Operating Systems (IWOOOS ’96) , Seat- tle, WA, October 27-28 1996. [12] “Solar Designer”. Non-Executable User Stack. http://www. openwall.com/linux/. [13] Antony Edwards, Trent R. Jaeger, and Xiaolan Zhang. Verifying Authorization Hook Placement for the Linux Security Modules Framework. Report RC22254, IBM T.J. Watson Research Center, December 2001. http://domino.watson.ibm.com/library/ cyberdig.nsf/1e4115aea78b6e7c85256b3600% 66f0d4/fd3bffacfd2bbd9385256b30005ec7ee? OpenDocument. [14] Nigel Edwards, Joubert Berger, and Tse Houng Choo. A Secure Linux Platform. In Proceedings of the 5th Annual Linux Show- case and Conference , November 2001. [15] Dawson R. Engler, M. Frans Kaashoek, and James O’Toole Jr. Exokernel: An Operating System Architecture for Application- level Resource Management. In Symposium on Operating Sys- tems Principles (SOSP) , Copper Mountain, Colorado, December
[16] M. Abrams et al. Information Security: An Integrated Collection of Essays. IEEE Comp., 1995. [17] Tim Fraser, Lee Badger, and Mark Feldman. Hardening COTS Software with Generic Software Wrappers. In Proceedings of the IEEE Symposium on Security and Privacy , Oakland, CA, May
[18] Timothy Fraser. LOMAC: Low Water-Mark Integrity Protection for COTS Environments. In Proceedings of the IEEE Symposium on Security and Privacy , Oakland, CA, May 2000. [19] Timothy Fraser. LOMAC: MAC You Can Live With. In Proceed- ings of the FREENIX Track, USENIX Annual Technical Confer- ence , Boston, MA, June 2001.
[20] Virgil D. Gligor, Serban I Gavrila, and David Ferraiolo. On the Formal Definition of Separation-of-Duty Policies and their Com- position. In Proceedings of the IEEE Symposium on Security and Privacy , Oakland, CA, May 1998. [21] Andreas Grunbacher. Extended Attributes and Access Control Lists for Linux. World-wide web page available at http:// acl.bestbits.at/, December 2001. [22] Serge Hallyn and Phil Kearns. Domain and Type Enforcement for Linux. In Proceedings of the 4th Annual Linux Showcase and Conference , October 2000. [23] Jon Inouye, Ravindranath Konuru, Jonathan Walpole, and Bart Sears. The Effects of Virtually Addressed Caches on Virtual Memory Design & Performance. Operating Systems Review , 24(4):896–908, October 1992. Also published as OGI technical report CSE-92-010, ftp://cse.ogi.edu/pub/tech-reports/1992/92- 010.ps.gz. [24] SNARE. World-wide web page available at http:// intersectalliance.com/projects/Snare/. [25] Jay Lepreau, Bryan Ford, and Mike Hibler. The persistent rel- evance of the local operating system to global applications. In Proceedings of the ACM SIGOPS European Workshop , pages 133–140, September 1996. [26] Linux Intrusion Detection System. World-wide web page avail- able at http://www.lids.org. [27] T. Linden. Operating System Structures to Support Security and Reliable Software. ACM Computing Surveys , 8(4), December
[28] Peter Loscocco and Stephen Smalley. Integrating Flexible Sup- port for Security Policies into the Linux Operating System. In Proceedings of the FREENIX Track: 2001 USENIX Annual Tech- nical Conference (FREENIX ’01) , June 2001. [29] Peter A. Loscocco, Stephen D. Smalley, Patrick A. Muckelbauer, Ruth C. Taylor, S. Jeff Turner, and John F. Farrell. The Inevitabil- ity of Failure: The Flawed Assumption of Security in Modern Computing Environments. In Proceedings of the 21st National Information Systems Security Conference , pages 303–314, Octo- ber 1998. [30] Larry W. McVoy and Carl Staelin. lmbench: Portable Tools for Performance Analysis. In USENIX Annual Technical Confer- ence , 1996. http://www.bitmover.com/lmbench/. [31] Medusa. World-wide web page available at http://medusa. fornax.sk. [32] David Mosberger and Larry L. Peterson. Making Paths Ex- plicit in the Scout Operating System. In Symposium on Operat- ing Systems Design and Implementation (OSDI) , pages 153–168, October 1996. http://www.cs.arizona.edu/scout/ Papers/osdi96/. [33] Greg Nelson. System Programming in Modula-3. Prentice Hall,
[34] Netfilter Core Team. The Netfilter Project: Packet Mangling for Linux 2.4, 1999. http://www.netfilter.org/. [35] Amon Ott. The Rule Set Based Access Control (RSBAC) Linux Kernel Security Extension. In Proceedings of the 8th Interna- tional Linux Kongress , November 2001. [36] Calton Pu, Tito Autrey, Andrew Black, Charles Consel, Crispin Cowan, Jon Inouye, Lakshmi Kethana, Jonathan Walpole, and Ke Zhang. Optimistic Incremental Specialization: Streamlin- ing a Commercial Operating System. In Symposium on Oper- ating Systems Principles (SOSP) , Copper Mountain, Colorado, December 1995. [37] Jerome H. Saltzer and Michael D. Schroeder. The Protection of Information in Computer Systems. Proceedings of the IEEE , 63(9), November 1975.
[38] Stephen Smalley, Timothy Fraser, and Chris Vance. Linux Se- curity Modules: General Security Hooks for Linux. http: //lsm.immunix.org/, September 2001. [39] Ray Spencer, Stephen Smalley, Peter Loscocco, Mike Hibler, David Andersen, and Jay Lepreau. The Flask Security Architec- ture: System Support for Diverse Security Policies. In Proceed- ings of the Eighth USENIX Security Symposium , pages 123–139, August 1999. [40] Winfried Trumper. Summary about POSIX.1e. http://wt. xpilot.org/publications/posix.1e, July 1999. [41] Eugen N. Volanschi, Charles Consel, Gilles Muller, and Crispin Cowan. Declarative Specialization of Object-Oriented Programs. In Proceedings of the Conference on Object-Oriented Program- ming Systems, Languages, and Applications (OOPSLA’97) , At- lanta, GA, October 1997. [42] Robert N.M. Watson. TrustedBSD: Adding Trusted Operating System Features to FreeBSD. In Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference (FREENIX ’01) , June 2001. [43] WireX Communications. Linux Security Module. http:// lsm.immunix.org/, April 2001. [44] Marek Zelem and Milan Pikula. ZP Security Frame- work. http://medusa.fornax.sk/English/ medusa-paper.ps.
