mirror of
https://github.com/joel16/android_kernel_sony_msm8994.git
synced 2024-11-30 15:41:27 +00:00
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
|
||||
- this file.
|
||||
LSM.txt
|
||||
- description of the Linux Security Module framework.
|
||||
SELinux.txt
|
||||
- how to get started with the SELinux security enhancement.
|
||||
Smack.txt
|
||||
|
34
Documentation/security/LSM.txt
Normal file
34
Documentation/security/LSM.txt
Normal file
@ -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
|
||||
|
||||
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.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user