diff options
author | Kees Cook <kees@outflux.net> | 2011-11-01 20:20:01 -0400 |
---|---|---|
committer | James Morris <jmorris@namei.org> | 2011-11-15 20:37:27 -0500 |
commit | e163bc8e4a0cd1cdffadb58253f7651201722d56 (patch) | |
tree | 66570af9c0304cf53350e8e67c67e407e92ee12f /Documentation/security/LSM.txt | |
parent | 1933ca8771585d43d3d2099c0c9ba7ca6b96e303 (diff) |
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/security/LSM.txt')
-rw-r--r-- | Documentation/security/LSM.txt | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt new file mode 100644 index 000000000000..c335a763a2ed --- /dev/null +++ b/Documentation/security/LSM.txt | |||
@@ -0,0 +1,34 @@ | |||
1 | Linux Security Module framework | ||
2 | ------------------------------- | ||
3 | |||
4 | The Linux Security Module (LSM) framework provides a mechanism for | ||
5 | various security checks to be hooked by new kernel extensions. The name | ||
6 | "module" is a bit of a misnomer since these extensions are not actually | ||
7 | loadable kernel modules. Instead, they are selectable at build-time via | ||
8 | CONFIG_DEFAULT_SECURITY and can be overridden at boot-time via the | ||
9 | "security=..." kernel command line argument, in the case where multiple | ||
10 | LSMs were built into a given kernel. | ||
11 | |||
12 | The primary users of the LSM interface are Mandatory Access Control | ||
13 | (MAC) extensions which provide a comprehensive security policy. Examples | ||
14 | include SELinux, Smack, Tomoyo, and AppArmor. In addition to the larger | ||
15 | MAC extensions, other extensions can be built using the LSM to provide | ||
16 | specific changes to system operation when these tweaks are not available | ||
17 | in the core functionality of Linux itself. | ||
18 | |||
19 | Without a specific LSM built into the kernel, the default LSM will be the | ||
20 | Linux capabilities system. Most LSMs choose to extend the capabilities | ||
21 | system, building their checks on top of the defined capability hooks. | ||
22 | For more details on capabilities, see capabilities(7) in the Linux | ||
23 | man-pages project. | ||
24 | |||
25 | Based on http://kerneltrap.org/Linux/Documenting_Security_Module_Intent, | ||
26 | a new LSM is accepted into the kernel when its intent (a description of | ||
27 | what it tries to protect against and in what cases one would expect to | ||
28 | use it) has been appropriately documented in Documentation/security/. | ||
29 | This allows an LSM's code to be easily compared to its goals, and so | ||
30 | that end users and distros can make a more informed decision about which | ||
31 | LSMs suit their requirements. | ||
32 | |||
33 | For extensive documentation on the available LSM hook interfaces, please | ||
34 | see include/linux/security.h. | ||