diff options
author | Kees Cook <kees@outflux.net> | 2011-11-01 17:20:01 -0700 |
---|---|---|
committer | James Morris <jmorris@namei.org> | 2011-11-16 12:37:27 +1100 |
commit | e163bc8e4a0cd1cdffadb58253f7651201722d56 (patch) | |
tree | 66570af9c0304cf53350e8e67c67e407e92ee12f /Documentation | |
parent | 1933ca8771585d43d3d2099c0c9ba7ca6b96e303 (diff) | |
download | op-kernel-dev-e163bc8e4a0cd1cdffadb58253f7651201722d56.zip op-kernel-dev-e163bc8e4a0cd1cdffadb58253f7651201722d56.tar.gz |
Documentation: clarify the purpose of LSMs
Clarify the purpose of the LSM interface with some brief examples and
pointers to additional documentation.
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: James Morris <jmorris@namei.org>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/security/00-INDEX | 2 | ||||
-rw-r--r-- | Documentation/security/LSM.txt | 34 | ||||
-rw-r--r-- | Documentation/security/credentials.txt | 6 |
3 files changed, 39 insertions, 3 deletions
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX index 19bc494..99b85d3 100644 --- a/Documentation/security/00-INDEX +++ b/Documentation/security/00-INDEX @@ -1,5 +1,7 @@ 00-INDEX - this file. +LSM.txt + - description of the Linux Security Module framework. SELinux.txt - how to get started with the SELinux security enhancement. Smack.txt diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt new file mode 100644 index 0000000..c335a76 --- /dev/null +++ b/Documentation/security/LSM.txt @@ -0,0 +1,34 @@ +Linux Security Module framework +------------------------------- + +The Linux Security Module (LSM) framework provides a mechanism for +various security checks to be hooked by new kernel extensions. The name +"module" is a bit of a misnomer since these extensions are not actually +loadable kernel modules. Instead, they are selectable at build-time via +CONFIG_DEFAULT_SECURITY and can be overridden at boot-time via the +"security=..." kernel command line argument, in the case where multiple +LSMs were built into a given kernel. + +The primary users of the LSM interface are Mandatory Access Control +(MAC) extensions which provide a comprehensive security policy. Examples +include SELinux, Smack, Tomoyo, and AppArmor. In addition to the larger +MAC extensions, other extensions can be built using the LSM to provide +specific changes to system operation when these tweaks are not available +in the core functionality of Linux itself. + +Without a specific LSM built into the kernel, the default LSM will be the +Linux capabilities system. Most LSMs choose to extend the capabilities +system, building their checks on top of the defined capability hooks. +For more details on capabilities, see capabilities(7) in the Linux +man-pages project. + +Based on http://kerneltrap.org/Linux/Documenting_Security_Module_Intent, +a new LSM is accepted into the kernel when its intent (a description of +what it tries to protect against and in what cases one would expect to +use it) has been appropriately documented in Documentation/security/. +This allows an LSM's code to be easily compared to its goals, and so +that end users and distros can make a more informed decision about which +LSMs suit their requirements. + +For extensive documentation on the available LSM hook interfaces, please +see include/linux/security.h. diff --git a/Documentation/security/credentials.txt b/Documentation/security/credentials.txt index fc0366c..8625705 100644 --- a/Documentation/security/credentials.txt +++ b/Documentation/security/credentials.txt @@ -221,10 +221,10 @@ The Linux kernel supports the following types of credentials: (5) LSM The Linux Security Module allows extra controls to be placed over the - operations that a task may do. Currently Linux supports two main - alternate LSM options: SELinux and Smack. + operations that a task may do. Currently Linux supports several LSM + options. - Both work by labelling the objects in a system and then applying sets of + Some work by labelling the objects in a system and then applying sets of rules (policies) that say what operations a task with one label may do to an object with another label. |