Next: Performance Overhead
Up: Testing and Functionality
Previous: Testing and Functionality
Modules
LSM provides only the mechanism to enforce enhanced access control
policies. Thus, it is the LSM modules that implement a specific policy
and are critical in proving the functionality of the framework. Below
are briefly described a few of these LSM modules:
- SELinux A Linux
implementation of the Flask [41] flexible access
control architecture and an example security server that supports Type
Enforcement, Role-Based Access Control, and optionally Multi-Level Security.
SELinux was originally implemented as a kernel
patch [29] and was then reimplemented as a
security module that uses LSM. SELinux can be used to confine
processes to least privilege, to protect the integrity and
confidentiality of processes and data, and to support application
security needs. The generality and comprehensiveness of SELinux
helped to drive the requirements for LSM.
- DTE Linux An implementation of Domain and Type
Enforcement [4,5] developed for
Linux [23]. Like SELinux, DTE Linux was originally
implemented as a kernel patch and was then adapted to LSM. With this
module loaded, types can be assigned to objects and domains to
processes. The DTE policy restricts access between domains and from
domains to types. The DTE Linux project also provided useful input
into the design and implementation of LSM.
- LSM port of Openwall kernel patch The Openwall kernel
patch [12] provides a collection of security features to protect
a system from common attacks, e.g. buffer overflows and temp file races.
A module is under development that supports a subset of the Openwall
patch. For example, with this module loaded a victim program will not
be allowed to follow malicious symlinks.
- POSIX.1e capabilities The POSIX.1e
capabilities [42] logic was already present in the
Linux kernel, but the LSM kernel patch cleanly separates this logic
into a security module. This change allows users who do not need this
functionality to omit it from their kernels and it allows the
development of the capabilities logic to proceed with greater
independence from the main kernel.
Next: Performance Overhead
Up: Testing and Functionality
Previous: Testing and Functionality
Chris Wright
2002-05-13