The "Plugin" System for Security
Think of the Linux kernel as a building with many doors. Standard Linux permissions are the locks on those doors — only people with the right key can enter. But what if you want a security guard standing at each door who can apply additional rules, like "no one from accounting can enter the server room, even if they have a key"? That security guard is what the LSM (Linux Security Module) framework provides.
Linux kernel developers realized early on that different organizations have radically different security requirements. A government agency needs military-grade mandatory controls; a desktop user needs simplicity. Rather than baking one opinionated security model into the kernel and forcing everyone to live with it, they designed LSM as a standardized hook system — a set of well-defined interception points woven into the kernel's core logic where external security modules can plug in and make their own decisions.
LSM is not security itself. It is the infrastructure that makes pluggable security possible. When a process attempts a sensitive operation — opening a file, binding a network port, creating a socket, sending a signal — the kernel first evaluates standard Unix permissions (DAC). If those pass, the kernel calls the active LSM hook: "Security module, do you approve this action?" The module then consults its own policy and returns allow or deny. This two-stage check means LSM decisions are always additive restrictions — an LSM can only make the system more restrictive than DAC, never less.
The major LSM implementations you will encounter in production are SELinux (Red Hat, CentOS, Fedora, Android), AppArmor (Ubuntu, Debian, SUSE), and Smack (embedded systems). They all use the same kernel hooks but implement completely different policy models on top. Only one "major" LSM can be active at a time (though minor LSMs like Yama and Lockdown can stack alongside them), and the choice is made at boot time via the kernel command line or compile-time default.
Interviewers often ask: "What is the difference between SELinux and AppArmor?" A weak answer compares syntax. A strong answer starts here: both are LSM implementations that provide MAC, but they differ in their security model — SELinux uses labels attached to every kernel object (files, processes, sockets), while AppArmor uses filesystem paths defined in per-application profiles. This architectural difference has real operational consequences: SELinux survives file renames and moves (the label travels with the inode), while AppArmor profiles break if a binary moves to a different path.