Kees Cook | e163bc8 | 2011-11-01 17:20:01 -0700 | [diff] [blame] | 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 | |
Casey Schaufler | d69dece | 2017-01-18 17:09:05 -0800 | [diff] [blame] | 25 | A list of the active security modules can be found by reading |
| 26 | /sys/kernel/security/lsm. This is a comma separated list, and |
| 27 | will always include the capability module. The list reflects the |
| 28 | order in which checks are made. The capability module will always |
| 29 | be first, followed by any "minor" modules (e.g. Yama) and then |
| 30 | the one "major" module (e.g. SELinux) if there is one configured. |
| 31 | |
Pranith Kumar | 591bcb1 | 2014-06-09 11:55:23 -0400 | [diff] [blame] | 32 | Based on https://lkml.org/lkml/2007/10/26/215, |
Kees Cook | e163bc8 | 2011-11-01 17:20:01 -0700 | [diff] [blame] | 33 | a new LSM is accepted into the kernel when its intent (a description of |
| 34 | what it tries to protect against and in what cases one would expect to |
| 35 | use it) has been appropriately documented in Documentation/security/. |
| 36 | This allows an LSM's code to be easily compared to its goals, and so |
| 37 | that end users and distros can make a more informed decision about which |
| 38 | LSMs suit their requirements. |
| 39 | |
| 40 | For extensive documentation on the available LSM hook interfaces, please |
| 41 | see include/linux/security.h. |