Linux Security
Privilege model, mandatory access control, and syscall filtering
Security layers
Linux uses a layered security model:
Application
│
▼
Syscall entry
│
├── DAC (Discretionary Access Control): uid/gid/permissions ─── always
│
├── Capabilities: fine-grained privilege splitting ──────────── always
│
├── LSM hooks (SELinux / AppArmor / TOMOYO) ──────────────────── if enabled
│
└── seccomp BPF: syscall whitelist/blacklist ─────────────────── if installed
DAC (file permissions, uid/gid) is always enforced. LSM adds Mandatory Access Control policies on top. Capabilities split "root privilege" into 40 discrete permissions. seccomp restricts which syscalls a process can make.
Pages in this section
Access control
| Page |
What it covers |
| LSM Framework |
LSM hooks, SELinux, AppArmor architecture |
| SELinux |
Labels, policy, AVC — how MAC decisions are made |
| Landlock |
Unprivileged sandboxing from userspace |
| Capabilities |
Linux capability model, privilege dropping |
| Credentials |
struct cred, uid/euid/fsuid, credential lifecycle |
| User Namespaces |
Unprivileged containers and their attack surface |
Syscall & kernel hardening
| Page |
What it covers |
| seccomp BPF |
Syscall filtering, libseccomp, container profiles |
| Kernel Hardening |
Stack protector, CFI, mitigations landscape |
| Audit |
The audit subsystem, rules, and its cost |
Storage encryption
| Page |
What it covers |
| fscrypt |
Filesystem-level encryption (ext4/f2fs) |
| dm-crypt |
Block-level encryption, LUKS |
War stories
| Page |
What it covers |
| Security War Stories |
Four real CVEs — Dirty Pipe, the fs_context overflow, stale ptracer credentials, and nested user-namespace UID mapping — root-caused and traced through whatever real disclosure record actually exists for each |