| 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. |