Linux Security Modules (LSM) is a hook-based framework integrated into the Linux kernel since 2.6 (2003) that provides a general mechanism for implementing Mandatory Access Control (MAC) without modifying the core kernel. Its origin is the NSA’s presentation of SELinux at the 2001 Linux Kernel Summit: Linus Torvalds accepted the need for flexible access control but refused to hardcode a single security model, directing instead the development of a framework into which any security model could be plugged. The result is LSM: a set of strategically placed hook functions throughout the kernel’s execution paths — over 240 hooks in recent kernels — at points where security-relevant decisions occur: file open, process creation, capability checks, socket operations, IPC access, memory mapping, and more. Each hook is a call into the currently active security module(s), which examine the operation’s context and return allow or deny. The core kernel enforces whatever the security module decides.
LSM separates modules into two categories. Major LSMs implement a full MAC policy and have exclusive access to the kernel’s per-object security blobs — the opaque storage attached to inodes, tasks, credentials, and sockets where the security module stores its labels and policy state. Only one major LSM can be the primary module at boot (selected via the security= kernel parameter or compile-time default), though the stacking architecture introduced in kernel 4.x allows multiple major modules to coexist under specific conditions. The accepted major modules in the upstream kernel are SELinux, AppArmor, Smack, and TOMOYO. Minor LSMs implement narrower, non-policy security features and stack freely: Yama (restricts ptrace scope), Lockdown (controls kernel integrity under Secure Boot), LoadPin (restricts the origins from which the kernel loads modules and firmware), and SafeSetID (constrains setuid/setgid transitions). BPF LSM (kernel 5.7) is a stackable minor module that allows eBPF programs to attach to LSM hooks at runtime, implementing custom access control logic without loading a kernel module or configuring a major LSM — enabling programmatic, per-workload policy without the compile-time commitment to SELinux or AppArmor. LSM hooks are always evaluated after standard Linux Discretionary Access Control (DAC) — file permission bits and ACLs — so an LSM module can only further restrict what DAC has already permitted; it cannot grant access that DAC denies.
From an operational perspective, LSM is the reason that SELinux and AppArmor are mutually exclusive on a given system without kernel recompilation — both are major LSMs competing for the same hook slot. Distribution defaults encode this choice: RHEL, Fedora, and CentOS use SELinux; Ubuntu and Debian use AppArmor. Container runtimes interact with LSM directly: containerd and CRI-O apply AppArmor profiles and SELinux labels to containers via the OCI runtime spec’s linux.appArmorProfile and linux.seccomp fields, and the PSA Restricted profile mandates that a seccomp profile is set, which in turn passes through the kernel’s seccomp(2) syscall — a separate mechanism from LSM hooks but complementary to them. In confidential computing environments, LSM policies on the host remain relevant for KubeVirt and Kata Containers workloads: the host’s LSM confines the QEMU/virt-launcher process itself, providing a containment layer outside the VM boundary that bounds the damage from a QEMU vulnerability.