Linux Security Architecture

The Linux Security Architecture is a multi-layered defense-in-depth framework designed to protect system resources, isolate untrusted applications, and enforce the principle of least privilege across processes, users, and containers.

Linux security has evolved through three distinct paradigms:

Discretionary Access Control (DAC): Traditional Unix permissions based on User IDs (UID), Group IDs (GID), and permission bitmasks (rwxrwxrwx).
Privilege Granularization (Capabilities): Splitting root's all-or-nothing power (UID 0) into granular privilege flags (CAP_NET_BIND_SERVICE, CAP_SYS_ADMIN, CAP_BPF).
Mandatory Access Control & Sandboxing (LSM, seccomp, Landlock): Enforcing non-bypassable kernel security policies (SELinux, AppArmor), restricting system call attack surfaces (seccomp), and unprivileged application sandboxing (Landlock).

┌────────────────────────────────────────────────────────────────────────┐
│                        User Space Application                          │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ System Call (open, execve, socket)
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│ 1. seccomp / seccomp-bpf Filter                                        │
│    Inspects syscall number & arguments; kills or returns EPERM/ENOSYS  │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ Allowed
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│ 2. Discretionary Access Control (DAC) & Capabilities                   │
│    Checks UID/GID against inode mode (0755) and checks struct cred     │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ Allowed
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│ 3. Linux Security Modules (LSM) Hooks                                  │
│    Calls active security modules (SELinux, AppArmor, Landlock, BPF)    │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │ Allowed
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│ 4. Kernel Subsystem Execution (VFS / Networking / Memory)              │
└────────────────────────────────────────────────────────────────────────┘

Core Security Layers

1. Linux Capabilities (Granular Root Privileges)

Traditional Unix granted absolute power if UID == 0. Linux Capabilities divide this monolithic authority into over 40 distinct flags stored in the thread's struct cred in kernel memory and in filesystem extended attributes (security.capability) on disk:

CAP_NET_BIND_SERVICE: Allows binding to reserved privileged ports (< 1024) without running as full root.
CAP_SYS_ADMIN: The legacy catch-all capability for system administration (mount, cgroups, namespaces).
CAP_BPF: Dedicated capability for loading eBPF programs and creating BPF maps (introduced in Linux 5.8).

Read the dedicated guide: Linux Capabilities.

2. seccomp & seccomp-bpf (Syscall Attack Surface Reduction)

Secure Computing Mode (seccomp) restricts the system calls a process is permitted to issue into the kernel. Using seccomp-bpf, container runtimes (like Docker and runc) attach a BPF filter program to every container process, blocking dangerous or unnecessary syscalls (such as reboot, kexec_load, or raw kernel module loading).

Read the dedicated guide: seccomp & seccomp-bpf.

3. Linux Security Modules (LSM)

The LSM Framework embeds authoritative security hooks across every critical kernel subsystem (inode lookups, file opening, socket creation, process execution). When a system call passes DAC and capability checks, the kernel invokes the active LSM hooks:

SELinux: Strict, label-based Type Enforcement (TE) and Multi-Category Security (MCS).
AppArmor: Path-based security profiles restricting file and network paths.
BPF LSM: Allows writing custom, dynamic security policies directly in eBPF (introduced in Linux 5.7).

Read the dedicated guide: Linux Security Modules (LSM).

4. Landlock (Unprivileged Application Sandboxing)

Introduced in Linux 5.13, Landlock is a stacked LSM that empowers unprivileged processes to create bespoke security sandboxes without requiring root or setuid binaries. A program (such as a web browser, document renderer, or microservice) can voluntarily drop access to all filesystem directories except its specific working folder.

Read the dedicated guide: Landlock LSM.

5. Container Isolation: Namespaces and Cgroups

Containers are not virtual machines; they are regular Linux processes constrained by two kernel mechanisms:

Linux Namespaces: Virtualizes system resources (PID, Mount, Network, IPC, UTS, User) so the process believes it has its own private operating system.
Control Groups (cgroups): Enforces resource limits on CPU, memory, block I/O, and process counts.

Security Architecture Comparison

Security Layer	Enforced By	Primary Target	Typical Error Code	Privilege Required to Configure
seccomp	Kernel BPF Filter	Syscall numbers & arguments	`SIGSYS` (kill) or `EPERM`	None (`PR_SET_NO_NEW_PRIVS`)
DAC	VFS / Kernel	Inode owner & permission bits	`EACCES`	File owner or `CAP_FOWNER`
Capabilities	Kernel `struct cred`	Specific kernel operations	`EPERM`	`CAP_SETPCAP`
LSM (SELinux/AppArmor)	Global LSM Hooks	Security contexts & labels	`EACCES` / `EPERM`	Root (`CAP_MAC_ADMIN`)
Landlock	Stacked LSM	Filesystem paths & TCP ports	`EACCES`	None (Unprivileged)

Frequently Asked Questions (FAQ)

What is the difference between DAC and MAC in Linux?

Discretionary Access Control (DAC) allows individual file owners to decide who can access their files via permission bits, whereas Mandatory Access Control (MAC) enforces system-wide security policies defined by the administrator that even root cannot bypass. In DAC, if an attacker compromises a user account, they have unrestricted control over all files owned by that user. In MAC (like SELinux), a compromised web server process is confined to its assigned security label and cannot access sensitive user files even if DAC permissions would allow it.

Why do container runtimes use seccomp if containers already have namespaces?

Namespaces only virtualize resource visibility (like PIDs and network interfaces), but they do not prevent a container from attacking the shared host kernel through vulnerable system calls. By attaching a seccomp-bpf filter, container runtimes block hundreds of unused system calls, drastically shrinking the kernel attack surface exposed to containerized code.

Can unprivileged users create security sandboxes in Linux?

Yes. Unprivileged users can create sandboxes using both seccomp and Landlock as long as PR_SET_NO_NEW_PRIVS is set first. Setting PR_SET_NO_NEW_PRIVS guarantees that child processes cannot acquire elevated privileges via setuid binaries, making it safe for the kernel to allow unprivileged processes to restrict their own execution environment.