Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Auditing & Logging

InterGenOS keeps a clear record of what happens on your machine, and keeps that record on your machine. Logs exist so you can understand and trust your system, not so a vendor can study you.

This page covers where logs live, what is recorded by default, and the privacy boundary that governs all of it.

The Privacy Boundary First

Auditing and logging on InterGenOS operate under one absolute rule: log data never leaves your machine on its own.

  • No telemetry. InterGenOS collects zero analytics, crash reports, or usage statistics.
  • No opt-out required. You do not flip toggles to stop your OS from sending data to the cloud. The data never leaves to begin with.
  • No silent uploads. Logs are written locally and stay there until you choose to read, export, or delete them.

Everything below describes records held for you, on the system you control. See the Security Handbook overview for the full posture this rests on.

System Logs (journald)

InterGenOS ships GNOME 49 on Wayland over a systemd userland, so the system log is the systemd journal. The journal captures kernel messages, service output, boot records, and authentication events in a single queryable store.

Common queries:

# Everything since the last boot
journalctl -b

# Logs for a single service
journalctl -u <service-name>

# Follow new entries live
journalctl -f

# Only errors and above
journalctl -p err

# Scope an investigation by time
journalctl --since "2026-06-15 09:00" --until "2026-06-15 10:00"

What Is Audited By Default

Several InterGenOS security controls produce their own records, independent of any audit subsystem you might add later.

Mandatory Access Control (AppArmor)

InterGenOS ships AppArmor profiles for system daemons in enforce mode by default. When a confined daemon attempts an action its profile forbids, the denial is logged. These denial records are the primary signal that a service is behaving outside its expected envelope. See Sandboxing & Mandatory Access Control for how the profiles are structured.

Service Sandboxing (systemd)

System services run under extensive systemd isolation directives (NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, syscall filtering, and more). When a sandboxed service is blocked from a restricted operation, the failure appears in that service’s journal entries, giving you a direct view of the confinement working as intended. The full directive baseline is listed on the Hardening Baseline page.

Boot and Integrity Verification

The signed Secure Boot chain and dm-verity integrity protection both record their verification results during boot. A failed signature check or an integrity mismatch is a boot-time event, not a silent fallback. See Encryption, Keys & TPM2 for how the boot chain validates each stage and signs Unified Kernel Images.

Authentication Events

Login attempts, privilege escalation, and session lifecycle events are recorded through the journal in the usual way for a systemd system, so you can review who accessed the machine and when.

Package and Supply-Chain Records

Auditing on InterGenOS extends to the software you install, not just the running system.

  • Signed-index verification. 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 each package’s SHA-256 hash is validated locally before installation. A verification failure is surfaced, not skipped.
  • Software Bill of Materials. InterGenOS publishes a deterministic SPDX 2.3 JSON SBOM for the Secure Boot shim — the trust anchor the rest of the boot chain is verified through — describing its exact build inputs and source hashes, giving you a machine-readable provenance record for the boot chain’s root of trust.

See the Registry-Trust Boundary page for the full trust model behind these checks.

Reading and Managing Your Logs

Because the journal is local and queryable, routine auditing is a matter of asking the right questions of journalctl. To review security-relevant activity, combine the priority and unit filters shown above; to investigate a specific incident, scope by time with --since and --until.

When you export logs to share with someone, you are making a deliberate choice. Nothing on the system does that for you.

Further Reading

InterGenOS exists to give you a machine you understand, can modify, and can trust. Local, honest logging is part of that promise.