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 anchors trust at power-on and carries it forward, so a tampered system cannot quietly boot.

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). Secure Boot enforcement is optional and off by default on the current fleet; with it enabled, unsigned kernel modules are not trusted.
Integrity-verified system image. The system files ship as a read-only image with a verified-integrity hash tree (dm-verity) generated over it. Each signed kernel image carries the root hash of that image on its command line, so with Secure Boot enabled, a tampered system image cannot boot under a validly signed kernel. A whole-file checksum path exists as a fallback, asserted non-empty at build time and verified again at boot.
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, reproducible 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. To protect against active attack windows targeting Python packages, InterGenOS sources critical dependencies from verified GitHub release tags rather than relying on PyPI. Rust and Go packages use a reproducible vendor pipeline: dependencies are fetched, verified, and packaged offline, so upstream ecosystem volatility cannot break the build or inject compromised code during a compile step.
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 in enforce mode. InterGenOS ships AppArmor profiles for system daemons in enforce mode by default, not complain mode or disabled.
Aggressive systemd hardening. System services run sandboxed with extensive isolation directives so that a compromised daemon has very little reach. 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. Any server package shipped by InterGenOS binds to localhost (127.0.0.1) by default. Services never listen on a public interface unless you deliberately change their configuration.
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 firmware forced into the core. The core operating system relies on open-source drivers and firmware. Proprietary blobs are available if your hardware strictly requires them, but they are never 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 Qwen models) 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 everything in your own user space.
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.

The assistant cannot edit its own restraints. InterGen’s own code, model pins and signature, daemon units, PolicyKit policy, verified model store, and signing/provenance state are treated as system-critical — in the same protected class as the boot keys and the integrity hashes. Writing or modifying them is FORBIDDEN to InterGen. This closes a specific attack: a capable adversary’s whole game is to talk the assistant into rewriting its own gate, manifest, or guardrails. If the assistant’s substrate is write-forbidden to the assistant, even a flawless prompt injection cannot make it weaken itself. 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?” On this axis, a read is always free.
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 of 20 phases (validate, verify-sources, setup, toolchain, chroot-prep, chroot-tools, core, config, core-extra, base, kernel, desktop, ai, extra, bootloader, image, manifest, squashfs, ukis-verity, iso), with publishing as an optional final step. Packages are organized across six tiers (toolchain, core, base, desktop, ai, and extra). Exact package counts are derived live from the source tree and drift between builds; as of this writing (2026-06-15) the total is in the neighborhood of 857 packages.

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