Privilege Separation
The pattern: split a system into a small privileged core (the kernel, the trusted enclave, the admin role) and a large unprivileged surface (user processes, untrusted code, regular users). Every dangerous operation crosses the boundary explicitly via a defined interface — syscalls, capabilities, signed requests. Compromise of the unprivileged surface should not implicitly grant access to the privileged core.
The trade-off: safety vs. performance. Each privilege boundary crossing has a cost (context switch, capability check, audit log). Smaller privileged surfaces are safer but slower; larger ones are faster but expand the blast radius of a compromise. Modern systems split privilege further — Linux capabilities split root into ~40 specific permissions; container namespaces scope a process’s view; OAuth scopes limit a token’s reach. The art is making the boundary fine-grained enough to matter without making every operation a syscall storm.
[Deepen this entry when first hit in Phase 1. Reinforced in Phase 6 (containers) and Year 2 Phase 12 (least-privilege at scale).]
Related patterns
- resource-virtualization — the mechanism that enforces the privilege boundary in hardware terms.
- mediation — privilege boundaries are policed by mediators (kernel, API server, mesh).
- layering-and-abstraction — each privilege boundary is also an abstraction boundary.
- least-privilege — the policy companion: the boundary exists, this pattern says how much each side gets.
- defense-in-depth — multiple stacked privilege boundaries make a single compromise insufficient.
- zero-trust-security — privilege separation extended to every network call.
- First touched: Year 1 Phase 1: OS Foundations.
- Reinforced in: Year 1 Phase 6: Containers, Year 2 Phase 12: Platform Engineering.