Threat Model & Security Philosophy

InterGenOS is a security-only-aligned, built-from-source Linux distribution. This page describes who and what the system is designed to defend against, the assumptions behind that design, and the concrete consequences those assumptions have for how InterGenOS is built and how it behaves on your machine.

The guiding principle is short: Security is not first. It is only. When a security control conflicts with convenience, security wins. The goal of every decision is a machine you understand, can modify, and can trust — because a machine you cannot trust is a machine you do not control.

This is version 1.0-dev (build id v1.0-dev1). Where a feature is planned rather than shipped, this page says so explicitly.

The adversary we assume

InterGenOS is built on the working assumption that adversaries have superhuman vulnerability-discovery capability. We do not design only for the casual attacker who needs a known, published exploit. We design for an attacker who can find the silent failure you did not know was there.

That assumption changes what counts as “safe.” A masked error, a blanket “ignore failures,” an unverified “known-good” claim, or a degraded-but-shipped feature is not a minor blemish. It is precisely the seam such an adversary pulls on. So throughout InterGenOS, the question asked of every control is not “is this convenient?” but “does this eliminate a silent failure and turn an unverified assumption into a checked gate?” If an option masks rather than verifies, it is treated as wrong.

This threat model spans several concrete adversaries:

A tampered or substituted system image — someone swapping the read-only system files underneath a validly signed kernel.
A tampered boot chain — an attacker trying to run an unsigned kernel, an unsigned bootloader, or an untrusted kernel module.
A compromised software supply chain — malicious code injected upstream into a language ecosystem package or a build dependency.
A tampered package mirror or man-in-the-middle on install — corrupted or substituted packages delivered when you install or update software.
A compromised system service — a daemon that gets exploited at runtime and tries to escalate or move laterally.
A coerced on-device AI assistant — an attacker using prompt injection to talk the local assistant into weakening the system’s own protections.
Silent data exfiltration — software phoning home with telemetry, analytics, or usage data you never agreed to send.

The rest of this page describes the design consequences of defending against each of these.

Defending the boot and integrity chain

InterGenOS builds a signed trust chain from the bootloader through the Unified Kernel Images, so the artifacts that boot your machine are present and cryptographically verifiable. When Secure Boot is enabled, that chain is enforced from power-on and a tampered system cannot quietly boot. On the current default — Secure Boot off — the same signatures are present and verifiable, but the firmware does not yet gate on them; enforcement begins once you enable Secure Boot and enroll your key.

Signed boot chain. A Microsoft-signed shim (the pre-signed shim from Fedora) validates the InterGenOS GRUB bootloader, which in turn verifies the Linux kernel and the Unified Kernel Images (UKIs). The signatures are always present; Secure Boot enforcement is optional and off by default in the current build, and with it enabled, unsigned kernel modules are not trusted.
Integrity-verified live image. dm-verity seals the live ISO and install media, not the installed root filesystem. The read-only system image (a squashfs) is built with a verified-integrity hash tree (dm-verity) generated over it, and each signed Unified Kernel Image carries that image’s root hash on its command line — and because the command line sits inside the signed envelope, the root hash is itself signed, so a tampered live image cannot present a valid signature. There is no unauthenticated boot fallback: a release UKI always seals the root hash, and if one is absent the init code refuses to boot the unverifiable image (the only unverified route is an explicit developer marker, which a sealed, signed UKI cannot carry). A whole-file filesystem.sha256 still ships, but purely as a user-facing media diagnostic — it is no longer a boot-trust input. Once you install to disk, Forge lays down a conventional ext4 root; the installed root is not a dm-verity device, and its integrity rests on the signed UKI (when Secure Boot is enforced) and on pkm’s recorded per-file SHA-256 hashes, which pkm verify can re-check at any time.
Signed end to end. One hardware-token signing step covers the bootloader and all of the unified kernel images. Signing only appends a signature; it never alters the payload. Inputs are re-staged and re-checked against the freshly built system image before every signing, and the signed outputs are verified afterward.
Your own keys for your own kernels. The InterGenOS release-signing key never leaves a hardware token under InterGenOS control. If you need out-of-tree modules such as proprietary drivers, the Forge installer walks you through enrolling a Machine Owner Key (MOK) on first boot. Installed systems regenerate and sign each kernel’s UKI with your machine’s local MOK at every kernel install or upgrade, so the same boot-time signature verification keeps applying to kernels you add after the original ISO.

This is the trust chain referenced elsewhere on this site as “the trust chain that keeps this machine yours.” For a deeper walkthrough, see the verified-boot pages under the installation guide.

Defending the supply chain and the mirror

A from-source distribution lives or dies by what goes into the compiler and what comes off the mirror.

Built from source in an isolated, deterministic environment. Every source is pinned and checksum-verified before it is used. Builds are deterministic by construction (a fixed source date, pinned checksum-verified sources, deterministic ordering); full byte-identical output across independent builders is a documented 1.x goal.
Reduced exposure to language-ecosystem attacks. Every upstream source — including the Python packages fetched from PyPI’s own content host — is pinned to a specific artifact URL and verified against a recorded SHA-256 hash before the build, rather than being resolved dynamically from a live package index at build time. Rust and Go dependencies are fetched, verified, and vendored ahead of an offline build. This removes the live-dependency-resolution window during compilation — a yanked or silently substituted version cannot slip in — and reduces exposure to an upstream compromise during the build. It does not, by itself, prove that a pinned dependency was benign at the moment it was selected.
A signed binary mirror. Software installs pull from repo.intergenos.org. The package index is the signed manifest of the whole repository. Every pkm sync cryptographically verifies the InterGenOS.db index signature against a release-signing subkey held on a hardware token and certified by the offline InterGenOS master key, and on download pkm validates each file’s SHA-256 hash locally before installation. Publishing regenerates and re-signs the complete index every time — incremental data transfer, never a partial signature — and the live repository is promoted by an atomic swap so clients never see a half-published state.
A Software Bill of Materials for the boot trust anchor. InterGenOS ships a deterministic SPDX 2.3 JSON SBOM for the Secure Boot shim — the Microsoft-signed binary every other boot component is verified through — attesting its exact build inputs and source hashes: the pinned upstream shim source, the base build image, the embedded InterGenOS Secure Boot CA certificate, and the SBAT entry. It is a real, machine-readable provenance record for the most security-critical binary in the chain, not a claim you take on faith.

For v1.0, InterGenOS uses an index-only signature trust model: a centralized, verifiable source of truth.

Defending the running system

Once booted, the system limits the blast radius of any single compromised component.

AppArmor mandatory access control. On the default ISO the two InterGenOS-authored profiles (intergen-mcp, pkm) ship in complain (learning) mode — logged, not blocked — graduating to enforce per-profile; server packages on the mirror ship enforce-mode profiles that activate when the server is installed.
Aggressive systemd hardening. System services run under layered sandboxing that shrinks the filesystem, devices, kernel interfaces, namespaces, address families, and system-call surface a daemon can reach if it is compromised. Baseline directives applied across system daemons include NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, PrivateDevices=true, the ProtectKernel* family, ProtectControlGroups=true, RestrictAddressFamilies limited to AF_UNIX AF_INET AF_INET6, RestrictNamespaces=true, MemoryDenyWriteExecute=true (except for packages that explicitly require a JIT), SystemCallArchitectures=native, and a @system-service system-call filter with @privileged @resources @mount @swap @reboot denied.
Safe network binds. InterGenOS configures the network-server packages it ships to bind the loopback interface (127.0.0.1) by default; no shipped service is intended to listen on a non-loopback interface without explicit user configuration. A package that ever bound a public interface by default would be a bug to fix, not the design.
No default passwords. InterGenOS does not ship databases or services with blank or default “admin” credentials. Initial credentials are randomly generated or require manual setup during installation.
Locked by default. A freshly installed system ships locked: no remote access enabled and a default-deny firewall.

Defending the privacy boundary

InterGenOS treats your data leaving the machine as a security event, not a settings preference.

No telemetry. Zero analytics, crash reports, or usage statistics are collected.
No auto-updates. The system does not change software behind your back. Upgrades happen only when you explicitly run pkm upgrade.
No opt-out privacy. There are no toggles to stop your OS from exfiltrating usage data, because it collects and sends none. The network is used only for things you initiate — package syncs, the one-time model download, a browser, a service you start, or an opt-in Phone-A-Friend request — never to report on you.
No proprietary applications forced into the core. The kernel drivers InterGenOS ships are open-source, in-tree drivers. The core does include the redistributable binary firmware blobs that real hardware needs to function — for example amdgpu, iwlwifi, and CPU microcode — but these are device payloads run by the hardware’s own microcontrollers, not host software. Proprietary vendor drivers and applications (NVIDIA’s userspace driver, Chrome, and the like) are kept out of the core archive entirely and installed only on your explicit, opt-in request. Nothing proprietary is forced on you.

Defending against a coerced AI assistant

InterGenOS ships an on-device assistant called InterGen: a tiered, hardware-detected, offline-first local assistant (built on an on-device model) with zero telemetry. Its permission model is part of the threat model, not an afterthought.

Two ideas drive its design.

Inherit the OS’s gate; do not invent a new one. InterGen mirrors the privilege model you already understand: you can freely touch your own things, and you need sudo/PolicyKit for system things. Every action is classified by zone and operation and resolved to one of three outcomes:

FREE — done immediately, no prompt: all reads of non-secret data, and actions confined to your own user space. Note that “your own user space” is not a synonym for “harmless” — it includes your dotfiles, your shell startup, your autostart entries, and your SSH keys. What makes an action free is who owns the target, not how sensitive it is; the consent gate covers system-level state, not everything with impact.
AUTH-PROMPT — InterGen triggers the OS’s real authorization (pkexec/PolicyKit), phrased plainly (“InterGen wants to restart Bluetooth. That needs admin rights. Authorize?”). Your password is the gate; the kernel enforces it. This covers writing or state-changing system configuration, and reading secrets such as the shadow file — because you yourself could do that with sudo, so InterGen does not pretend to be stricter than the OS.
FORBIDDEN — InterGen will not do it, and says so transparently, handing control back to you. It states plainly what it will not do and why, and confirms you can do it yourself.

InterGen is not authorized to modify its own substrate — and could not, even if it were. InterGen’s own code, model pins and signature, daemon units, PolicyKit policy, verified model store, and signing/provenance state are classified as system-critical (zone Z3) — the same protected class as the boot keys and the integrity hashes — so writing or modifying them is FORBIDDEN to InterGen, and the gate refuses such an action before it ever offers an authorization prompt. Two independent layers hold this line: the permission gate denies the write, and InterGen runs as an unprivileged user-session daemon (NoNewPrivileges, never root) that lacks the OS permission to write the root-owned substrate in the first place. This closes the most direct attack — a capable adversary’s whole game is to talk the assistant into rewriting its own gate, manifest, or guardrails, and that direct self-modification path is blocked. It does not make prompt injection harmless: authorization gating, the content-trust scanning layer (ingress and egress, including InterGen Sentinel), the audit log, and the OS privilege boundary each remain an independent defense. This is defense in depth, not one control that solves injection. Only you, acting manually and outside the assistant, can change those files.

A deliberate separation underpins this. Two orthogonal axes are evaluated by two independent mechanisms and are never conflated:

The privilege axis asks “would a human need sudo for this, and what does it touch?” On this axis an ordinary, non-secret read is free; a read that would itself require elevation — a secret such as the shadow file or key material — escalates to the same authorization prompt a human would hit, because InterGen never pretends to be stricter or looser than the OS.
The content-trust axis independently watches what crosses the boundary: injection on the way in, secrets on the way out. This is the job of the scanner and provenance layer, including InterGen Sentinel, a pluggable security scanner whose default configuration is local-only (Local-Rules plus a local Qwen model). Sentinel supports six opt-in cloud providers — Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek — none of which are engaged unless you choose to enable them.

Escalating a hard question to a frontier cloud model is called Phone-A-Friend (Frontier/Cloud Escalation). Like the Sentinel cloud providers, it is opt-in and never the default path. The default assistant stays on the device with zero telemetry.

Design consequences for the build itself

The threat model is not only a set of runtime controls; it shapes how a release is allowed to come into existence. The reasoning is simple: a build whose packages all compiled is not a build that is known-good. The expensive failures of a from-source distribution compile fine, package fine, and only manifest when the artifact is installed and booted on real hardware — a service locked down with no writable path, a directory omitted from a package’s file list, a hardware-detection heuristic wrong for a specific GPU, a first-boot race.

Several rules follow, and they are non-negotiable:

No silent failures. Every error surfaces; an unverified assumption becomes a checked gate or it is not trusted.
No stubs. Placeholder code that pretends to work does not ship — “a stub is a lie.”
No cheating around a build failure. A failing package is fixed in the source tree, never worked around by moving it to another tier, disabling a feature to dodge a missing dependency, or silently skipping a step.
Only a clean build counts. A fix is done when it lives in the source tree and a clean from-scratch build reproduces the corrected behavior with zero manual intervention. A fix that only works because of a hand-edit on the running target is a note about a fix, not a fix.
Validate on real hardware. The candidate loop always runs through the full bootloader → ISO → install → boot chain, and race-class issues must clear several consecutive cold boots on representative lower-end hardware.

A candidate becomes a stable release only when a complete from-scratch cycle runs end to end with zero triggers — nothing required a fix — with the hardware-token signing step as the only sanctioned human action.

The build runs as an ordered, reproducible lifecycle whose phases are defined in the build script and carry a candidate from source validation through toolchain, the package tiers, and image assembly to a signed, installable ISO, with publishing to the mirror as an optional final step. Packages are organized across seven tiers (toolchain, core, base, desktop, extra, compute, and ai). The exact phase list and the package count are derived live from the source tree and drift between builds, so this page deliberately pins neither number — for the current phase list, see The Build & Release Pipeline.

Assumptions, boundaries, and non-goals

A threat model is only honest if it also says what it takes for granted and what it does not try to defeat.

What the model assumes:

The hardware is functioning and behaves as specified.
The platform firmware below the verified-boot boundary — the UEFI/SMM layer beneath the shim — is not already compromised. Verified boot anchors trust at the signed shim; it cannot vouch for what runs before it.
The project’s own signing infrastructure — the offline master key and the hardware-token release subkey — stays under project control and uncompromised.

What it does not claim to defeat:

An authorized administrator who deliberately disables controls. The machine is yours: if you turn Secure Boot off, unlock the gate with your password, or remove a protection, InterGenOS does what you told it to. Control of your own machine is the goal, not a threat to guard against.
Hardware implants or malicious firmware living below the boot-trust boundary.
Denial of service. This model is about integrity, confidentiality, and containment — not keeping a service available under active disruption.
Unknown defects in the kernel or the rest of the trusted computing base. No system can claim immunity to a flaw it has not found.

Where a class of failure cannot be prevented outright, the design does not paper over it. It favors visible failure over silent trust, verifiable state over asserted state, a reduced blast radius over a single hard shell, and recoverability over irreversibility — so that when something does go wrong, you can see it, check it, and get back to a known-good state.

Assets and trust boundaries

The assets this model protects, roughly in order of blast radius:

Boot-chain integrity — the shim, GRUB, kernel, and UKI signatures.
OS integrity — the live image’s dm-verity seal and the installed system’s pkm verify records.
Package provenance — the signed mirror index and per-file hashes.
Signing keys — the offline master key and the hardware-token release subkey.
User data and credentials — your files, secrets, and SSH/MOK keys.
Authorization boundaries — the sudo/PolicyKit gate InterGen inherits rather than replaces.
InterGen’s control policy — its gate, model pins, and guardrails.
Privacy — the default that nothing leaves the machine unless you initiate it.

Trust flows outward along a single chain, each stage verified by the one before it; a compromise is contained by the next gate outward.

flowchart LR
    A[Platform firmware] --> B[shim / GRUB / UKI]
    B --> C[Kernel]
    C --> D[System services]
    D --> E[User session]
    E --> F[InterGen authorization broker]
    F --> G[Local model / opt-in cloud escalation]

What ships today versus what is planned

This page describes the system as it exists in 1.0-dev. To keep the threat model honest, the line between shipped and planned is drawn explicitly.

Shipped today:

pkm, the package manager, against the signed mirror.
Forge, the InterGenOS installer.
A signed Secure Boot chain, dm-verity integrity verification, and UKI signing.
The GNOME 49 desktop on Wayland.
The InterGen local assistant and InterGen Sentinel as described above.

Planned, not shipped (do not treat as current):

KDE/Plasma (Qt6) and switchable desktops.
The application campaigns (for example Kdenlive, OBS, Krita, Blender, FreeCAD, GnuCash, and Boxes).

InterGenOS Wiki