Skip to main content

Security & trust model

This page states plainly what xcon OS protects against today, what it does not yet, and how the trust chain works — so you can decide what to run on it.

The update trust chain​

  • Every release is a manifest (version, notes, file hashes) plus an Ed25519 signature. The signing key is offline; the public key is baked into every image. The box verifies the signature before trusting anything, so a compromised update server cannot push an unsigned or modified image.
  • Artifacts are additionally checked against their SHA-256 hashes from the signed manifest.
  • Downgrade/replay protection: the box refuses any release that is not strictly newer than what it runs, so a compromised channel cannot replay an older, signed-but-vulnerable release.
  • The cloud bootstrap script is itself signed (.sig published alongside it). Verify it before running — see Install on Hetzner.

What immutability does and does not give you​

The base OS image is read-only and versioned: it is never modified in place and cannot silently drift. This prevents accidental and in-band tampering of the running system.

It does not, on its own, protect against an attacker with offline disk access rewriting the system partition — the image is verified at install/update time, not re-verified block-by-block at boot time. Cryptographic boot-time verification (dm-verity) and Secure Boot are on the roadmap; until then, treat physical/hypervisor disk access as outside the current threat boundary.

Accounts and access​

  • A single account, xcon, is sudo-capable; root is locked (no password, no direct login).
  • The installer sets one password, used for the console, SSH, and webadmin. Because that one credential reaches three surfaces, protect it accordingly — prefer SSH keys and rotate the password.
  • The webadmin login is rate-limited (repeated failures from a source are locked out briefly). Sessions use short-lived signed tokens.
  • System-critical services (the management agent, firewall, SSH, networking) cannot be stopped or disabled from the console, and the management agent cannot be killed — the appliance cannot be trivially bricked from its own UI.

First-connection TLS​

The box generates a unique self-signed certificate on first boot, with your box's IP in the certificate. The certificate's SHA-256 fingerprint is printed on the console at boot. On your first webadmin visit, compare the fingerprint your browser shows against the console value before trusting it. You can later replace the certificate with your own CA-issued one.

On the roadmap​

dm-verity boot-time integrity, Secure Boot, disk encryption for the data partition, SSH key management and per-service SSH toggle, and an audit log. (Boot-failure auto-recovery via a watchdog is already shipped.)