The Limit of "Root"
To understand why LSM exists, you need to understand the fundamental weakness of the security model Linux inherited from Unix.
DAC — Discretionary Access Control is the standard Linux permission system: the rwx bits, owner, group, and sudo. It is called "discretionary" because the owner of a resource decides who can access it. If you own a file, you can chmod 777 it and share it with the world. The system trusts your judgment. This works well for multi-user systems where users are humans who can be held accountable. It breaks down when the "user" is a compromised daemon running as root.
Consider a web server running as root (or even as a dedicated www-data user). If an attacker exploits a vulnerability in that server — a buffer overflow, a remote code execution bug — they gain a shell with the same privileges as the web server process. Under DAC alone, that means they can read every file the web server user can read, write to every directory it can write to, and make every network connection it can make. If the server runs as root, the attacker effectively owns the machine. DAC has no concept of behavioral constraints — it cannot say "this process should only ever touch web content, regardless of what user it runs as."
MAC — Mandatory Access Control inverts the trust model. Instead of the resource owner deciding access, a system administrator writes a policy that defines exactly what each program is allowed to do. The program itself cannot override this policy, and neither can the user running it. Even root is subject to MAC policy (in SELinux's targeted policy, root running outside a confined domain is unconfined, but in strict policy, even root is constrained). This is the key insight: MAC constrains programs, not just users.
A concrete example: under a MAC policy, the Apache web server process (httpd) might be permitted to:
- Read files in /var/www/html/
- Write logs to /var/log/httpd/
- Bind to TCP ports 80 and 443
And explicitly denied from:
- Reading /etc/shadow (password hashes)
- Writing to /etc/cron.d/ (persistence mechanism)
- Connecting outbound to arbitrary IP addresses (data exfiltration)
If an attacker compromises Apache and tries to read /etc/shadow, the MAC system blocks the operation at the kernel level — before the read even reaches the filesystem — regardless of what user Apache runs as. The attacker has code execution but is trapped inside Apache's policy sandbox.
Key Point: DAC and MAC are complementary, not alternatives. A file must pass both DAC and MAC checks. You cannot use MAC to grant access that DAC denies. Think of DAC as the building's key system and MAC as the security guard — you need both the right key and the guard's approval.