Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Kernel Hardening

InterGenOS hardens the kernel and its boot path from the moment the machine powers on, not through post-install scripts you have to remember to run. The kernel is the most privileged code on the system, so the controls below exist to keep that privilege verifiable and contained.

The goal is a machine you understand, can modify, and can trust, starting at the layer everything else depends on.

Verified Boot Chain

The kernel only runs after every link above it has been cryptographically validated.

  • A signed boot chain (Secure Boot optional). The chain is built around a Microsoft-signed shim (the pre-signed shim from Fedora) that validates the InterGenOS GRUB bootloader, which in turn verifies the Linux kernel and Unified Kernel Images (UKIs). With Secure Boot enabled the firmware enforces this end to end; the current fleet ships with Secure Boot off, so the chain is present and verifiable but not firmware-enforced.
  • Unsigned kernel modules are not trusted. If your hardware needs out-of-tree modules such as proprietary drivers, the Forge installer walks you through enrolling a Machine Owner Key (MOK) on first boot.
  • Local UKI signing on every kernel change. Installed systems regenerate and sign each kernel’s UKI with your machine’s local MOK at every kernel install or upgrade, so boot-time signature verification continues to apply to kernels you install after the original ISO image.
  • The release-signing key stays offline. The InterGenOS release-signing key never leaves a hardware token under InterGenOS control. Only the MOK that Forge generates on your own machine signs the kernels you install.

Image Integrity (dm-verity)

The shipped, read-only system image is protected by dm-verity, which provides block-level integrity verification. dm-verity uses a Merkle hash tree built with veritysetup (statically linked), with a whole-file SHA-256 check retained as a fallback for any image whose signed command line lacks the verity root hash; this lets tampering be detected at the granularity of individual blocks as they are read rather than silently executed, which keeps the trust established by the verified boot chain intact at runtime. The tree’s root hash is sealed into the signed UKI kernel command line, so the integrity anchor for each image is itself covered by the boot-chain signature. UKI signing and dm-verity are produced as dedicated phases of the build pipeline, so integrity protection is part of the image itself rather than something layered on afterward.

Kernel-Surface Protections for System Services

Beyond the boot path, InterGenOS narrows what the running kernel exposes to the userspace daemons that talk to it. System services are sandboxed with systemd isolation directives, and several of those directives specifically reduce the kernel attack surface available to a compromised service:

  • ProtectKernelTunables=true — services cannot modify kernel tunables under /proc/sys, /sys, and related paths.
  • ProtectKernelModules=true — services cannot load or unload kernel modules.
  • ProtectKernelLogs=true — services cannot read or write the kernel log ring buffer.
  • ProtectControlGroups=true — the cgroup hierarchy is protected from modification.
  • RestrictNamespaces=true — creation of new namespaces is restricted.
  • RestrictRealtime=true — services cannot acquire realtime scheduling.
  • LockPersonality=true — the execution-domain personality is locked.
  • MemoryDenyWriteExecute=true — write-and-execute memory mappings are denied (except for packages that explicitly require a JIT).
  • SystemCallArchitectures=native — only native-architecture syscalls are permitted.
  • SystemCallFilter=@system-service with ~@privileged @resources @mount @swap @reboot — privileged, resource-control, mount, swap, and reboot syscall groups are filtered out.

These sit alongside the broader service-sandboxing baseline (NoNewPrivileges, ProtectSystem=strict, PrivateDevices, ProtectProc=invisible, and others). The full default set is documented in Hardening Baseline.

Mandatory access control complements the syscall filtering: AppArmor ships in enforce mode for system daemons by default, so a service that steps outside its profile is denied rather than merely logged. See Sandboxing and MAC for how AppArmor and systemd confinement work together.

Why This Matters

A kernel you cannot verify is a kernel you cannot trust. By signing the kernel and its UKI at every change, refusing unsigned modules, verifying image integrity with dm-verity, and tightly scoping the kernel interfaces each service can reach, InterGenOS keeps the most privileged layer of the system auditable and contained. You remain in control: enrolling your own MOK and choosing which out-of-tree modules to trust are deliberate, owner-driven steps, not defaults imposed on you.

Further Reading