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