Security Handbook

Security is not first. It is only.

That sentence is the design constraint behind every default in this section. When a security control conflicts with convenience, the control wins. InterGenOS is built to be a machine you understand, can modify, and can trust, and the protections described here are enforced from the moment the system boots, not bolted on by a post-install hardening script.

This handbook is the reference spine for how InterGenOS protects you by default and how to reason about changes you make yourself. It is written for two audiences: end users who want to know what is guarding their machine, and contributors who need to verify those guarantees against the source tree.

What InterGenOS Enforces Out of the Box

InterGenOS does not rely on optional toggles or opt-out privacy menus. The baseline posture is:

• Signed boot chain. A Microsoft-signed shim validates the GRUB bootloader, which verifies the Linux kernel and Unified Kernel Images. Secure Boot enforcement is optional and off by default on the current fleet; with it enabled, unsigned kernel modules are not trusted. See Encryption, Keys & TPM2 and Verified Boot & Secure Boot.
• AppArmor in enforce mode. System daemons ship with profiles in enforce mode by default, not complain mode. See Sandboxing & Mandatory Access Control.
• Aggressive systemd sandboxing. System services run under extensive isolation directives (NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, syscall filtering, and more) to limit the blast radius of any single compromise. See Hardening Baseline.
• Safe network binds. Server packages bind to localhost by default and never listen on a public interface unless you deliberately change their configuration. See Network Security & Firewalling.
• No default passwords. InterGenOS ships no services with blank or default credentials. Initial secrets are randomly generated or require setup during installation.
• A signed binary mirror. pkm sync verifies the package index signature against a release-signing subkey held on a hardware token and certified by the offline master key, and pkm validates each package’s SHA-256 hash locally before installation. See Registry-Trust Boundary.
• A from-source, verifiable build chain. Every package is built from source in an isolated build VM that is reset to a known-good snapshot before each build, with reproducible vendoring for Rust and Go and a deterministic SPDX 2.3 JSON SBOM published for the Secure Boot shim, the trust anchor of the boot chain.

The complete system is assembled from source across six package tiers (toolchain, core, base, desktop, ai, and extra) through a 20-phase build that ends in a signed, dm-verity-protected ISO image.

What InterGenOS Does Not Do

• No telemetry. Zero analytics, crash reports, or usage statistics are collected.
• No auto-updates. Software does not change behind your back. Upgrades happen only when you run pkm upgrade.
• No opt-out privacy. There is no toggle to stop data leaving your machine, because the data never leaves to begin with.
• No forced proprietary firmware in core. The core system uses open-source drivers and firmware. Proprietary blobs are available only if your hardware strictly requires them.

How This Section Is Organized

Each page below goes deep on one layer of the defense-in-depth model. Read them in order for a full picture, or jump to the layer you are auditing.

• Hardening Baseline — the system-wide defaults applied to every service and daemon.
• Attack-Surface Minimization — what is installed, what is reachable, and how that surface is kept small.
• Sandboxing & Mandatory Access Control — AppArmor enforce-mode profiles and systemd confinement.
• Kernel Hardening — kernel-level protections and tunables.
• Encryption, Keys & TPM2 — Secure Boot, the MOK enrollment flow, UKI signing, and disk encryption.
• Network Security & Firewalling — localhost-by-default binds and network controls.
• Auditing & Logging — what is recorded and how to review it.
• Registry-Trust Boundary — the signed mirror, index-only signature trust, and supply-chain protections.
• Self-Hosting Securely — running your own mirror or services without weakening the trust model.

The Security Tooling That Ships

InterGenOS includes InterGen Sentinel, a pluggable security scanner. By default it runs entirely on your machine using its Local-Rules engine and the local InterGen assistant (a hardware-detected, offline-first local model based on Qwen, with zero telemetry). Sentinel can also use Phone-A-Friend (Frontier/Cloud Escalation), an explicitly opt-in path to one of six cloud providers: Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), or DeepSeek. Cloud escalation is never automatic and never the default; you choose it, per request, when you want a frontier model’s second opinion. The local-only posture is described in The AI Assistant: Privacy & Data Locality.

Reasoning About Changes You Make

Because InterGenOS gives you full control, you can relax any of these defaults. When you do, you own the consequences. Before changing a security default, read the page that documents it so you understand what protection you are trading away and how to compensate. The desktop that ships today is GNOME 49 on Wayland; security guidance in this section is written against that environment.

Where to Go Next

• New to the project? Start with the Threat Model & Security Philosophy.
• Installing now? See Install with FORGE and Verified Boot & Secure Boot.
• Building or verifying packages? See Reproducibility & Verification.
• Reporting a vulnerability or following the disclosure process? See the Security Review & Advisory Process and Security Advisories.