BibTeX:
@inproceedings{DBLP:conf/uss/WrightCSMK02,
author = {Chris Wright and
Crispin Cowan and
Stephen Smalley and
James Morris and
Greg Kroah-Hartman},
title = {Linux Security Modules: General Security Support for the
Linux Kernel},
booktitle = {USENIX Security Symposium},
year = {2002},
pages = {17-31},
ee = {http://www.usenix.org/publications/library/proceedings/sec02/wright.html},
crossref = {DBLP:conf/uss/2002},
bibsource = {DBLP, http://dblp.uni-trier.de}
}
@proceedings{DBLP:conf/uss/2002,
editor = {Dan Boneh},
title = {Proceedings of the 11th USENIX Security Symposium, San Francisco,
CA, USA, August 5-9, 2002},
booktitle = {USENIX Security Symposium},
publisher = {USENIX},
year = {2002},
isbn = {1-931971-00-5},
bibsource = {DBLP, http://dblp.uni-trier.de}
}Summary:
The paper describes the motivation, design, and some of the implementation of the Linux Security Modules framework. The LSM framework allows many security models to be implemented as loadable Linux kernel modules. Rather than only interposing on system calls, LSM provides hooks for modules asking whether an access to an internal kernel object should be granted or denied. Almost always, the LSM hooks are restrictive rather than authoritative. That is, they allow a module to deny a request that the Linux DAC mechanism would have allowed rather than override a denial.
To support POSIX.1e capabilities, LSM provides some minimal support for permissive hooks that do override a denial. LSM is limited to supporting the core access control functionalities needed by existing Linux security projects, rather than adding auditing and virtualization.
LSM add opaque void * security fields in various internal kernel objects that the module can use to label them. It also allows module stacking where the primary module has the final say on whether to allow or deny an access request.
To implement LSM, the kernel was modified in 5 main ways:
- Opaque Security Fields were added to objects, and hooks were defined to instantiate, free, and update them. Note that special handling is required for object the already exist before the security module is loaded.
- Security Function Hooks were added in key accesses in the kernel. These are implemented by the module.
- A security System Call was added to allow security aware userspace applications to interact with the security module. The system call implementation is up to the security module.
- Registering security modules requires a special API to activate the hooks. Other were added so that modules can register themselves with others and stack.
- Modify capabilities to reduce the capable call to a wrapper for a LSM hook. Moving the capabilities bit vector from the task_struct to the opaque security field and modifying the system call interface are the only steps left in making capabilities completely standalone.
Additional hooks were provided
- for working with tasks (nice, kill, setuid)
- for program loading and controlling inheritance of state across program executions (such as file descriptors)
- for IPC
- for file ops (read, write, sockets)
- for network ops (devices, syscalls, sk_buffs)
- for module operations (create, register, delete)
- for sytem operations (hostname, accessing I/O ports, process accounting)
LSM provides no persistent storage of security attributes to files since that requires extended attributes, a complex issue. They decided not to completely modularize the Linux DAC security checks since that would be too invasive.
The Good:
This is really cool. It is now very easy to implement new security models. While it's true that notall models are possible, it is still a great leap forward. The interface seems simple and workable and they have interposed on the major kernel functions.
The Bad:
Unfortunately, the paper makes the implementation look a little arbitrary. There does not seem to be a systematic approach into what needs to be looked at, how many hooks there are, and where they should be. They already mentioned that access control has yet to be completely modularized to provide authoritative hooks. LSM only provides access control, unfortunately there is no interposition except on access request. It is not clear whether there has been any interposition on context switching or on cache control. No mention of interposing on memory or CPU resource allocations either.
