Linux Security Modules (LSM)
Relevant source files
The following files were used as context for generating this wiki page:
Linux Security Modules (LSM) provide a general framework for implementing security policies through hooks in the Linux kernel. The framework supports access control modules by providing infrastructure rather than specific security mechanisms. The LSM framework is optional and requires the CONFIG_SECURITY configuration option to be enabled. Sources: Documentation/security/lsm.rst:43-52, Documentation/userspace-api/lsm.rst:11-12
The LSM framework allows for the stacking of multiple security modules. It maintains security fields in kernel data structures and calls hook functions at critical points to manage these fields and perform access control. Sources: Documentation/security/lsm.rst:54-58, Documentation/admin-guide/LSM/index.rst:7-12
LSM Architecture and Stacking
The framework manages a list of security hooks called in a specific order. The system always includes the Linux capabilities module first, followed by "minor" modules like Yama, and finally one "major" module such as SELinux or AppArmor. Sources: Documentation/admin-guide/LSM/index.rst:19-28, Documentation/security/lsm.rst:104-106
Module Registration and Initialization
Individual modules register their hooks with the framework using security_add_hooks(). Each module passes a struct security_hooks_list to be added to the internal lists. Sources: Documentation/security/lsm.rst:108-112
The diagram shows the sequential registration of security modules during system initialization. Sources: Documentation/admin-guide/LSM/index.rst:22-28, Documentation/security/lsm.rst:49-52
Security Blobs and Data Structures
LSM uses "security blobs," which are void* pointers within kernel data structures. These blobs maintain security attributes for various kernel objects. The framework or individual modules manage these blobs. Sources: Documentation/security/lsm.rst:64-70
| Kernel Structure | Security Field Target | Description |
|---|---|---|
task_struct | Process | Security info for process execution. |
cred | Credentials | Security attributes for the task. |
super_block | Filesystem | Security information for the filesystem. |
inode | File/Pipe/Socket | Security attributes for the underlying object. |
file | Open File | Attributes for the specific file handle. |
sk_buff | Network Packet | 32-bit integer associated with security attributes. |
Sources: Documentation/security/lsm.rst:71-87
Hook Categories
LSM hooks fall into two primary categories: management hooks and access control hooks. Sources: Documentation/security/lsm.rst:116-118
Management Hooks
These hooks manage the allocation and deallocation of security structures. For example, security_inode_alloc() allocates security structures for inode objects, and security_inode_free() releases them. Sources: Documentation/security/lsm.rst:118-121
Access Control Hooks
These hooks enforce policy by checking permissions before a kernel operation completes. An example is security_inode_permission(), which validates access to an inode. Sources: Documentation/security/lsm.rst:121-124
The sequence diagram illustrates how a kernel core operation triggers an LSM hook to evaluate security policy before granting access. Sources: Documentation/security/lsm.rst:54-58, Documentation/security/lsm.rst:121-124
Userspace Interfaces
Userspace applications interact with LSM through specific filesystems and system calls.
Proc Filesystem
Major security modules maintain process attributes in /proc/.../attr. Specific files include:
/proc/self/attr/current: The active security context./proc/self/attr/exec: Context at the time of execution./proc/self/attr/fscreate: Context used for creating filesystem objects.
Sources: Documentation/admin-guide/LSM/index.rst:30-38, Documentation/userspace-api/lsm.rst:15-32
LSM System Calls
The framework provides specific system calls for retrieving and setting attributes:
sys_lsm_get_self_attr: Retrieves security attributes of the current process.sys_lsm_set_self_attr: Sets security attributes for the process.sys_lsm_list_modules: Lists active security modules.
Sources: Documentation/userspace-api/lsm.rst:50-62
Capabilities Module
The POSIX.1e capabilities logic is implemented as a standard security module in security/commoncap.c. It is always the first module registered. Unlike other LSMs, the capabilities module does not use general security blobs for performance and historical reasons. Sources: Documentation/security/lsm.rst:127-133, Documentation/admin-guide/LSM/index.rst:22-25
Development and Documentation Requirements
New LSMs are accepted into the kernel only when their intent and protection goals are documented in Documentation/admin-guide/LSM/. Extensive technical documentation for hook interfaces is maintained via kernel-doc comments in security/security.c. Sources: Documentation/security/lsm-development.rst:9-20
Linux Security Modules provide the essential infrastructure for Mandatory Access Control (MAC) in the Linux kernel. By separating the policy enforcement (hooks) from the policy logic (modules), LSM allows diverse security models like SELinux, AppArmor, and Smack to coexist and stack within the same system. Sources: Documentation/security/lsm.rst:43-52, Documentation/admin-guide/LSM/index.rst:14-18