the trusted computing base
Imagine the security of a whole bank rests on a handful of things: the vault door, the guards who hold its keys, and the rules they follow. If every one of those is sound, the bank is safe; if any one of them is corrupt or broken, no amount of careful behavior elsewhere can save it. In a computer, that small, all-important core is the trusted computing base, or TCB: the set of hardware, firmware, and software components that absolutely must work correctly for the system's security to hold.
Concretely, the TCB usually includes the CPU's protection hardware (the rings and the memory-management unit), the boot firmware, the operating-system kernel, and the few privileged programs that enforce the security policy. The defining property is not that these components are trustworthy by virtue, but that we are forced to trust them — a flaw in any TCB component can defeat security no matter how careful everything outside is. Within the TCB sits a special idea, the reference monitor: the component that mediates every access to every protected object, checking it against the policy. For a reference monitor to do its job it must be three things — always invoked (no access can sneak around it, the property called complete mediation), tamper-proof (attackers cannot disable or modify it), and small enough to be verified (so we can actually convince ourselves it is correct). The kernel's permission checks are the everyday reference monitor in a real OS.
The TCB is one of the most clarifying ideas in security because it focuses effort where it counts and yields a sharp design rule: keep the TCB as small as possible. Every line of code inside the TCB is code that must be correct, so the larger it grows, the more places a single bug can shatter the whole system's security. This is exactly the argument behind microkernels and small verified kernels like seL4 — by pushing most code out of the privileged core, they shrink the TCB to something one can hope to make correct, even formally prove correct. The honest reality is that on a mainstream OS the TCB is enormous (a monolithic kernel with millions of lines plus countless drivers), which is sobering: it means there are a great many places where one mistake could undermine everything, and it is why reducing privileged code is a recurring security goal.
When a process calls open("/etc/shadow", O_RDONLY), the kernel's permission check — part of the TCB, acting as the reference monitor — verifies the caller's rights before returning a descriptor. Because that check is always invoked and runs in the protected kernel, an ordinary process cannot bypass it. A bug in that check, though, would be a TCB flaw affecting every file.
The reference monitor must be always invoked, tamper-proof, and small enough to verify.
Trusted does not mean trustworthy — it means the system has no choice but to rely on it. That is why the goal is to keep the TCB small: every component inside it is a place where a single bug can defeat all of security.