Next: Conclusions
Up: Testing and Functionality
Previous: Performance Impact
Security Impact
Another key factor in the acceptance of the LSM framework is that it
provide some real security value. This can be viewed in two ways. First,
LSM must not create new security holes and needs to be thorough and
consistent in its coverage. Second, the LSM framework must be general
enough to support a variety of access control models.
Proving the correctness of the LSM framework has not been handled by the
LSM project directly. However, a project from
IBM [9]
has developed tools to do both static and dynamic analysis of the LSM
framework. These tools have, in fact, helped improve the LSM interface,
and can help with ongoing maintenance.
The real value of LSM is delivering effective security modules. Porting access control models to the LSM framework proves
that it is functional as a general purpose access control framework.
As the name suggests, LSM does not impact system security without
security modules. Presently, LSM supports the following security modules:
- SELinux A Linux
implementation of the Flask [28] 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 [19] 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 [3,4] developed for
Linux [14]. 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 [8] 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 [29] 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.
- LIDS (Linux Intrusion Detection System) started out as an
intrusion detection system, and then migrated towards intrusion
prevention in the form of an access control system similar to
SubDomain [7] that manages access by describing what
files a given program may access.
Next: Conclusions
Up: Testing and Functionality
Previous: Performance Impact
James Morris
2002-07-09