Hardening Baseline

InterGenOS is built on a single doctrine: security is not first. It is only. The goal is a machine you understand, can modify, and can trust. Where a security control conflicts with convenience, the control wins.

This page describes the hardening baseline that ships today in InterGenOS 1.0-dev (build id v1.0-dev1). Nothing here is an optional add-on or a post-install script. The environment is hardened from the moment the system boots.

At a glance

Out of the box, InterGenOS enforces:

A signed boot chain through the bootloader, kernel, and Unified Kernel Images; Secure Boot enforcement is optional (off by default on the current fleet), so the signatures are present and verifiable, enforced by firmware where you turn it on.
dm-verity integrity over the read-only system image.
AppArmor profiles for system daemons in enforce mode.
Extensive systemd sandboxing applied across system services.
A package mirror with an end-to-end signed index.
A strict zero-telemetry, zero-analytics, zero-auto-update privacy boundary.

Secure Boot, UKI signing, and dm-verity

The boot chain is signed end to end (Secure Boot enforcement is optional, off by default on the current fleet).

The chain is anchored by 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). Unsigned kernel modules are not trusted.
The InterGenOS release-signing key never leaves a hardware token under InterGenOS control.
Installed systems regenerate and sign each kernel’s UKI with your machine’s local Machine Owner Key (MOK) at every kernel install or upgrade, so the same boot-time signature verification continues to apply to kernels installed after the original ISO image. Only the MOK that Forge generates on your own machine signs the kernels you install.
If you need out-of-tree modules such as proprietary drivers, Forge walks you through enrolling a MOK on your first boot.
The system image is protected by dm-verity, so tampering with the read-only root is detected at boot.

For a deeper walkthrough, see the Verified Boot and Secure Boot guide.

AppArmor in enforce mode

Many distributions 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.

Systemd sandboxing

System services are sandboxed to minimize the blast radius of a potential compromise. The baseline directives applied across system daemons include:

NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true
ProtectControlGroups=true
ProtectHostname=true
ProtectClock=true
ProtectProc=invisible
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=true
RestrictRealtime=true
RestrictSUIDSGID=true
LockPersonality=true
MemoryDenyWriteExecute=true
RemoveIPC=true
SystemCallArchitectures=native
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources @mount @swap @reboot

MemoryDenyWriteExecute=true is relaxed only for packages that explicitly require a JIT. PostgreSQL is the documented example: its service unit sets MemoryDenyWriteExecute=false so the LLVM JIT compiler keeps working.

Network and credential defaults

Safe network binds: Any server package shipped by InterGenOS binds exclusively to localhost (127.0.0.1) by default. Services never listen on public interfaces unless you deliberately edit their configuration to allow it.
No default passwords: InterGenOS does not ship databases or services with blank or default “admin” passwords. Initial credentials are randomly generated or require manual setup during installation.

The signed binary mirror

When you install software, you pull from a signed mirror. The index is signed end to end to prevent tampering.

Every time you run pkm sync, your machine 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.
When downloading a package, pkm validates the file’s SHA-256 hash locally before installation.
InterGenOS enforces an index-only signature trust model for the 1.0 release, providing a centralized, verifiable source of truth.

For a deeper look at repository verification, see the Registry Trust Boundary.

The build chain

Every package is built from source in an isolated build VM that is reset to a known-good snapshot before each build. The build runs as 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 an optional publish step.

The resulting system is organized into six package tiers: toolchain, core, base, desktop, ai, and extra. The exact package count is derived live from the package definitions at build time and drifts as packages are added or updated. (The toolchain tier is used only to build the system and is not present on an installed machine.)

Supply-chain protections in the build chain include:

Zero-PyPI methodology: To protect the supply chain during active attack windows targeting Python packages, InterGenOS sources critical dependencies from verified GitHub release tags rather than relying on PyPI. The maturin package definition (packages/core/maturin/) is an example of this pattern.
Reproducible vendor pipelines: Rust and Go packages use a reproducible cargo-vendor (or equivalent) pipeline. Dependencies are fetched, verified, and packaged offline, so upstream ecosystem volatility cannot break the build or inject compromised code during a compile step.
Software Bill of Materials (SBOM): 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.

The desktop

The shipped desktop is GNOME 49 on Wayland. The hardening baseline above applies underneath it: system daemons are confined and sandboxed regardless of the desktop session running on top.

AI assistants and the privacy boundary

InterGenOS ships two local-first AI components, both built around the same privacy boundary as the rest of the system.

InterGen is a tiered, hardware-detected, offline-first local assistant built on Qwen models, with zero telemetry. It runs on your machine; nothing is sent to the cloud by default.
InterGen Sentinel is a pluggable security scanner. Its default backends are Local-Rules and Local-Qwen, which run entirely on-device. Six cloud providers (Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek) are available strictly opt-in, never on by default.

When Sentinel reaches a cloud provider, that escalation path is called Phone-A-Friend (Frontier/Cloud Escalation). It stays off until you turn it on, and it tells you when it is used.

What InterGenOS does not do

Silence is the default.

No telemetry: InterGenOS collects zero analytics, crash reports, or usage statistics.
No auto-updates: Your system will not update software behind your back. Upgrades happen only when you explicitly run pkm upgrade.
No opt-out privacy: You do not have to flip toggles in a settings menu to stop your OS from sending data to the cloud. The data never leaves to begin with.
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.

InterGenOS Wiki