35 lines
1.7 KiB
Plaintext
35 lines
1.7 KiB
Plaintext
|
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 https://lkml.org/lkml/2007/10/26/215,
|
||
|
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.
|