In 2023, a banking trojan modified the Windows kernel to hide its presence, evading antivirus and EDR for months. The breach cost millions because the security team didn't understand the Trusted Computing Base. This lesson dissects the core concepts that define whether an OS can actually enforce security: the TCB, security kernel, reference monitor, and protection rings. Without mastering these, no hardening measure will hold.
The TCB is the set of all hardware, firmware, and software components whose correct functioning is critical to security. A larger TCB introduces more attack surface. In modern OSes, the TCB includes the kernel, device drivers, and core system services. Linux's monolithic kernel puts the entire core in the TCB, while microkernel designs like seL4 minimize it. Every hardening decision should shrink the effective TCB—remove unused kernel modules, disable unnecessary services, and enforce strict driver signing.
💡 A practical way to think about TCB: If any component inside the TCB is compromised, the entire security model collapses. That's why we focus on kernel integrity, secure boot, and driver signing.
# Check loaded kernel modules (Linux) — each module extends the TCB
lsmod | wc -l # Count current modules
# Disable unnecessary module permanently
echo 'blacklist pcspkr' | sudo tee /etc/modprobe.d/nobeep.conf
sudo update-initramfs -uThe output shows how many modules are loaded. On a typical Ubuntu desktop, you may see 80+. Every module that you don't absolutely need widens the attack surface. After blacklisting and rebuilding the initramfs, that module can't be loaded even by accident. In a production server, aim for a lean kernel config with only required drivers.
The security kernel is the subset of the TCB that implements the reference monitor concept—a tamperproof, always-invoked, and verifiable mechanism that enforces access control. It must satisfy three properties: completeness (every access is mediated), isolation (it cannot be tampered with), and verifiability (its correctness can be proven). In practice, Windows enforces this through the kernel-mode security subsystem (SeAccessCheck), while SELinux implements a Mandatory Access Control monitor that can't be bypassed even by root.
Key insight: A reference monitor is not a specific piece of code; it's an architectural enforcement point. Any bypass of the reference monitor—like a kernel exploit that writes directly to memory—breaks the security model entirely.
This confirms that SELinux is in enforcing mode, meaning the reference monitor actively denies operations that violate policy. In permissive mode, violations are only logged—a dangerous misconfiguration. Ensuring the security kernel is active and non-bypassable is the foundation of all hardening.
| Concept | Definition | Compromise Impact |
|---|---|---|
| TCB | All trusted components | Total system compromise |
| Security Kernel | Core that implements reference monitor | Loss of access control enforcement |
| Reference Monitor | Mediation abstraction | Arbitrary access, policy bypass |
| Protection Rings | Hardware privilege levels (ring 0-3) | Kernel-mode arbitrary execution |
x86/ARM CPUs enforce privilege separation through protection rings. Kernel runs in ring 0, drivers in ring 1/2, and user applications in ring 3. Modern OSes mainly use ring 0 and ring 3. A successful privilege escalation attack crosses this boundary—from user-mode to kernel-mode—giving the attacker complete control. Defenses like Supervisor Mode Execution Prevention (SMEP) and Kernel Address Space Layout Randomization (KASLR) raise the bar. Hardening the boundary means enabling hardware protections and applying strict code-signing policies.
⚠️ Without SMEP, a kernel exploit can execute attacker-controlled code in ring 0. Always ensure your OS has SMEP/SMAP enabled (check /proc/cpuinfo flags on Linux, or Core isolation on Windows).
Verify exercises to earn ★ 120 XP and unlock next lab level.