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>
This commit is contained in:
parent
1933ca8771
commit
e163bc8e4a
|
@ -1,5 +1,7 @@
|
||||||
00-INDEX
|
00-INDEX
|
||||||
- this file.
|
- this file.
|
||||||
|
LSM.txt
|
||||||
|
- description of the Linux Security Module framework.
|
||||||
SELinux.txt
|
SELinux.txt
|
||||||
- how to get started with the SELinux security enhancement.
|
- how to get started with the SELinux security enhancement.
|
||||||
Smack.txt
|
Smack.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.
|
|
@ -221,10 +221,10 @@ The Linux kernel supports the following types of credentials:
|
||||||
(5) LSM
|
(5) LSM
|
||||||
|
|
||||||
The Linux Security Module allows extra controls to be placed over the
|
The Linux Security Module allows extra controls to be placed over the
|
||||||
operations that a task may do. Currently Linux supports two main
|
operations that a task may do. Currently Linux supports several LSM
|
||||||
alternate LSM options: SELinux and Smack.
|
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
|
rules (policies) that say what operations a task with one label may do to
|
||||||
an object with another label.
|
an object with another label.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue