Privileged enforcement mechanism
A security kernel is the hardware and software mechanism that implements a reference-monitor policy at a system boundary. It runs with enough privilege to control subjects' access to memory, devices, processes, and communication. A microkernel can serve this role, but small size alone does not make a kernel a security kernel.
Relationship to the reference monitor
The reference monitor is an abstract requirement: mediate every relevant access, resist tampering, and support analysis. The security kernel is one concrete implementation. It must define which objects and operations it mediates, which policy state it trusts, and which paths remain outside its scope.
An operating-system kernel can enforce process memory and file access. It does not automatically mediate database rows, cloud API actions, or a physical bus. Other reference-validation mechanisms remain necessary at those layers.
Mechanism and policy
Keep the privileged mechanism narrow. It should provide isolation, controlled communication, identity for protected subjects and objects, and enforceable capabilities or labels. Put changeable application policy in a less privileged component when the design can do so without creating a bypass.
The interface must not let an untrusted subject manufacture authority, relabel data, map protected memory, attach a debugger, load code into the kernel, or reach a device outside policy. Administrative operations are security-kernel operations and need separate authority and evidence.
Failure and assurance limits
A device driver, hypervisor, firmware component, direct-memory-access device, or management processor can be more privileged than the kernel. Shared memory and confused interfaces can bypass intended mediation. Formal verification covers stated models and assumptions, not every hardware fault, side channel, configuration, or operational action.
A large general-purpose kernel has broad functionality and attack surface. A smaller kernel reduces review scope but moves more services into user space and creates more interfaces that the system design must secure.
Pomerium boundary
Pomerium is a route-level policy decision and enforcement system, not an operating-system security kernel. Its process depends on the host kernel and runtime for memory, file, process, network, and credential isolation. Operators must protect those lower layers and prevent direct paths around the proxy.
Evaluation checklist
- Which subjects, objects, operations, and communication channels does the kernel mediate?
- Can an untrusted subject change policy, labels, capabilities, privileged code, or enforcement state?
- Which drivers, firmware, devices, management paths, and recovery components remain in the TCB?
- Is the privileged mechanism small and structured enough for the required assurance?
- Which resource accesses still need a reference monitor above or below this kernel?
