Attack-Surface Minimization

The most reliable way to defend a machine is to give an adversary fewer things to attack. InterGenOS treats every running service, every open port, every trusted key, and every package on disk as a liability to be justified rather than a default to be accepted. On a machine you understand, can modify, and can trust, the parts that are not present cannot be exploited.

This page describes the attack-surface posture InterGenOS ships today, and the principles behind it.

The principle

A from-source distribution has an unusual advantage: nothing is on the system unless it was deliberately compiled in and packaged. There is no vendor add-on layer, no pre-enabled “convenience” daemon, and no opaque firmware blob pulled in to make first boot smoother. Every component is the result of an explicit decision, run through the project’s lenses before it ships: does it eliminate silent failure, does it keep the machine transparent and under your control, and does it serve the actual goal of the work. A component that cannot pass those tests is not present to be attacked.

Minimization is therefore not a hardening pass applied after the fact. It is a property of how the system is built.

Locked by default

InterGenOS does not rely on post-installation hardening scripts. The environment is hardened from the moment the system boots, and the live ISO ships locked: no remote access enabled, and a default-deny firewall, out of the box.

No listening on public interfaces. Any server package shipped by InterGenOS binds exclusively to localhost (127.0.0.1) by default. Services never listen on a public interface unless you deliberately edit their configuration to allow it.
No remote access enabled. The shipped posture exposes nothing to the network until you turn it on yourself.
No default or blank 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.
No proprietary firmware in core. The core operating system relies exclusively on open-source drivers and firmware. Proprietary blobs are available if your hardware strictly requires them, but they are never forced on you.

Confinement and sandboxing

Reducing the count of running things is the first move. Containing what does run is the second. InterGenOS assumes any single component can be compromised and works to keep the blast radius small.

AppArmor in enforce mode. Unlike many distributions that leave mandatory access control in complain mode or disabled for third-party packages, InterGenOS ships AppArmor profiles for system daemons in enforce mode by default.
Aggressive systemd sandboxing. System services are confined with extensive isolation directives so that a compromised daemon cannot reach the rest of the system. The baseline applied across system daemons includes NoNewPrivileges=true, ProtectSystem=strict, ProtectHome=true, PrivateTmp=true, PrivateDevices=true, the ProtectKernel* family (tunables, modules, logs), ProtectControlGroups=true, ProtectProc=invisible, RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6, RestrictNamespaces=true, RestrictRealtime=true, RestrictSUIDSGID=true, LockPersonality=true, MemoryDenyWriteExecute=true (except for packages that genuinely require JIT), RemoveIPC=true, SystemCallArchitectures=native, and a SystemCallFilter restricted to @system-service with privileged, resource, mount, swap, and reboot call groups denied.

Together these mean a service that is breached cannot trivially write outside its sandbox, escalate privileges, read other users’ files, load kernel modules, or open arbitrary network families. The full set of these defaults is covered in the Hardening Baseline.

A small, signed package set

The fewer packages on disk, the fewer code paths an attacker can reach. InterGenOS ships a deliberately scoped package set, organized into six build tiers (toolchain, core, base, desktop, ai, and extra). As of this writing the catalog totals on the order of 850 packages across those tiers; the exact counts drift as the catalog evolves, so derive the live figure from the build manifest rather than treating any single number as fixed.

Everything in that set is built from source in an isolated, snapshot-restored build environment, and the supply chain itself is treated as attack surface:

Zero-PyPI methodology. To protect against attack windows targeting Python packages, InterGenOS sources critical dependencies from verified upstream release tags rather than relying on PyPI.
Reproducible vendor pipelines. Rust and Go packages use a reproducible offline vendoring pipeline: dependencies are fetched, verified, and packaged ahead of time, so upstream ecosystem volatility cannot break the build or inject compromised code during a compile step.
Software Bill of Materials. InterGenOS publishes a deterministic SPDX 2.3 JSON SBOM for the Secure Boot shim — the boot chain’s trust anchor — detailing exactly which build inputs and source hashes comprise it.

Software is installed with pkm, the InterGenOS package manager, which pulls from a signed binary mirror. Every pkm sync cryptographically verifies the repository index signature against a release-signing subkey held on a hardware token and certified by the offline master key, and every package download is validated against its SHA-256 hash locally before installation.

A verifiable boot and integrity chain

Attack surface is not only what runs after boot — it is also everything that decides what is allowed to run. InterGenOS closes that gap with a chain you can verify yourself.

Signed boot chain. A Microsoft-signed shim validates the InterGenOS bootloader, which verifies the kernel and Unified Kernel Images (UKIs). Secure Boot enforcement is optional and off by default on the current fleet, so the chain is signed and verifiable but not firmware-enforced unless you enable it; with it enabled, unsigned kernel modules are not trusted.
UKI signing on your own key. The InterGenOS release-signing key never leaves a hardware token under project control. On an installed system, each kernel’s UKI is regenerated and signed with a Machine Owner Key (MOK) that the Forge installer generates on your own machine, so boot-time signature verification keeps applying to kernels you install after the original ISO. If you need out-of-tree modules such as proprietary drivers, Forge walks you through enrolling that MOK on first boot.
dm-verity integrity. The read-only system image is covered by a verified-integrity hash tree, and that root hash is sealed into the signed kernel command line. With Secure Boot enabled, a tampered system image cannot boot under a validly signed kernel. A whole-file checksum path backs this up, and both are asserted non-empty at build time and verified again at boot.

The full build process that produces this chain runs as 20 ordered phases, from source validation through toolchain, the package tiers, kernel, bootloader, image assembly, squashfs, the UKI and integrity step, and ISO assembly, with an optional publish to the signed mirror. See Verified Boot for the boot-time view of this chain.

What is deliberately absent

The strongest reduction of attack surface is the data and the network traffic that never exists.

No telemetry. InterGenOS collects zero analytics, crash reports, or usage statistics.
No auto-updates. Your system will not change software behind your back. Updates happen only when you explicitly run them.
No opt-out privacy. You do not flip toggles to stop your OS from phoning home. The data never leaves to begin with.

This extends to the optional AI layer. InterGen, the tiered, hardware-detected local assistant, is offline-first and built on local Qwen models with zero telemetry. InterGen Sentinel, the pluggable security scanner, defaults to Local-Rules and a local Qwen model. Any escalation to a frontier model — the six opt-in cloud providers, surfaced as “Phone-A-Friend” (Frontier/Cloud Escalation) — is exactly that: opt-in, never a default, and never a path your data takes without your decision.

InterGenOS Wiki