Decide whether privacy VMs get a LUKS-encrypted root to allow persistent storage #135

New issue

Open

opened 2026-10-06 16:10:01 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-06 16:10:01 +01:00

Primary goals:

State the gain precisely — today every libvirt guest gets a plain GPT image, vfat /boot plus ext4 / (allod/vm disk.nix, imported by nixosModules.qemuGuest for every guest). The qcow2 sits on the hypervisor's already-encrypted disk, so the image is protected while the hypervisor is powered off and exposed as plaintext while it is unlocked: a copy of the file, a backup, or a stray snapshot carries the guest's SSH host key, the Nix store with every ciphertext agenix will open with that key, and any user data the guest keeps on disk.
Decide what persistent privacy state we actually want — a privacy VM holding signing keys deploys them through agenix into RAM only, and that works without LUKS. The question is everything else: a browser profile, a wallet's chain state and labels, downloaded media, drafts. Under principle 9, everything rebuilds from a clone and only keys are precious, so persistent state on a VM is either disposable or it is a new backup obligation. Name which it is per privacy archetype before adding the mechanism that makes keeping it comfortable.
Pick a key-delivery model, or reject all of them — the LUKS passphrase has to come from somewhere at every boot, and each source is a different threat model (see below).
Keep provisioning and reprovision working — nixos-anywhere with disko supports LUKS, but the host-key injection, new-vm --replace, rebuild-vm, and the kexec installer path each need a stated behaviour.

Key-delivery options

Option	What it protects against	Cost
Interactive passphrase in the guest console at every boot	Image copies, and the hypervisor being unlocked but unattended	A human at the console for every privacy VM boot; incompatible with a headless hypervisor, consistent with the decision that privacy VMs stay on the laptop
Key file handed in by the hypervisor at boot (initrd secret, virtio channel, or kernel command line from libvirt)	Image copies only; the key lives beside the image on the hypervisor	No boot UX change; the hypervisor still holds everything, so the gain over today is hygiene for copies and offsite backups of the image, not a new boundary
Virtual TPM (swtpm) with measured boot	Image copies, with the key sealed to the guest's own boot chain	swtpm state is itself a file beside the image; adds a moving part to every rebuild (measurements change with the kernel)
Network unlock (tang on the hypervisor, clevis in the guest)	Image copies taken off the hypervisor's network	A service on the hypervisor; the guest unlocks whenever it can reach it, so same boundary as the key-file option with more parts

A root compromise of a running hypervisor reads guest memory regardless of any of these, so none of them changes the posture against that; the honest framing is at-rest protection for the image file, and whether that is worth a boot-time human step.

Interactions to settle

The guest's /etc/ssh/<name> is the agenix identity; inside LUKS it is protected at rest, which closes the specific exposure that motivated this issue: a copied image yielding the key that opens every ciphertext the guest consumes.
Swap is already off and the journal volatile on privacy profiles; LUKS does not change what is in RAM.
Backups: an encrypted image can be shipped offsite as ciphertext (principle 1), which plain images cannot, and that may be the strongest argument for the key-file option even though it adds no boundary on the hypervisor itself.
Scope: privacy archetype only, or every guest? Dev VMs hold clones and per-VM tokens, all regenerable or revocable, so the case there is weaker.

Scope

In: the decision, recorded here, and if yes a follow-up implementation issue naming the archetype(s), the key-delivery option, and the provisioning behaviour. Out: any change to disk.nix or the builders under this issue; backup tooling for guest images.

Decide whether privacy VMs should get a LUKS-encrypted root, which would make persistent storage on those machines acceptable where today it is either unencrypted or deliberately avoided. This is an exploratory issue: the artifact is a recorded owner decision on the options below, with a follow-up implementation issue only if the answer is yes. Primary goals: - **State the gain precisely** — today every libvirt guest gets a plain GPT image, vfat `/boot` plus ext4 `/` (`allod/vm` `disk.nix`, imported by `nixosModules.qemuGuest` for every guest). The qcow2 sits on the hypervisor's already-encrypted disk, so the image is protected while the hypervisor is powered off and exposed as plaintext while it is unlocked: a copy of the file, a backup, or a stray snapshot carries the guest's SSH host key, the Nix store with every ciphertext agenix will open with that key, and any user data the guest keeps on disk. - **Decide what persistent privacy state we actually want** — a privacy VM holding signing keys deploys them through agenix into RAM only, and that works without LUKS. The question is everything else: a browser profile, a wallet's chain state and labels, downloaded media, drafts. Under principle 9, everything rebuilds from a clone and only keys are precious, so persistent state on a VM is either disposable or it is a new backup obligation. Name which it is per privacy archetype before adding the mechanism that makes keeping it comfortable. - **Pick a key-delivery model, or reject all of them** — the LUKS passphrase has to come from somewhere at every boot, and each source is a different threat model (see below). - **Keep provisioning and reprovision working** — `nixos-anywhere` with disko supports LUKS, but the host-key injection, `new-vm --replace`, `rebuild-vm`, and the kexec installer path each need a stated behaviour. ### Key-delivery options | Option | What it protects against | Cost | | --- | --- | --- | | Interactive passphrase in the guest console at every boot | Image copies, and the hypervisor being unlocked but unattended | A human at the console for every privacy VM boot; incompatible with a headless hypervisor, consistent with the decision that privacy VMs stay on the laptop | | Key file handed in by the hypervisor at boot (initrd secret, virtio channel, or kernel command line from libvirt) | Image copies only; the key lives beside the image on the hypervisor | No boot UX change; the hypervisor still holds everything, so the gain over today is hygiene for copies and offsite backups of the image, not a new boundary | | Virtual TPM (swtpm) with measured boot | Image copies, with the key sealed to the guest's own boot chain | swtpm state is itself a file beside the image; adds a moving part to every rebuild (measurements change with the kernel) | | Network unlock (tang on the hypervisor, clevis in the guest) | Image copies taken off the hypervisor's network | A service on the hypervisor; the guest unlocks whenever it can reach it, so same boundary as the key-file option with more parts | A root compromise of a running hypervisor reads guest memory regardless of any of these, so none of them changes the posture against that; the honest framing is at-rest protection for the image file, and whether that is worth a boot-time human step. ### Interactions to settle - The guest's `/etc/ssh/<name>` is the agenix identity; inside LUKS it is protected at rest, which closes the specific exposure that motivated this issue: a copied image yielding the key that opens every ciphertext the guest consumes. - Swap is already off and the journal volatile on privacy profiles; LUKS does not change what is in RAM. - Backups: an encrypted image can be shipped offsite as ciphertext (principle 1), which plain images cannot, and that may be the strongest argument for the key-file option even though it adds no boundary on the hypervisor itself. - Scope: privacy archetype only, or every guest? Dev VMs hold clones and per-VM tokens, all regenerable or revocable, so the case there is weaker. ### Scope In: the decision, recorded here, and if yes a follow-up implementation issue naming the archetype(s), the key-delivery option, and the provisioning behaviour. Out: any change to `disk.nix` or the builders under this issue; backup tooling for guest images.

vnprc-agent referenced this issue

2026-10-07 02:21:09 +01:00

mkServiceVm: root-only guest with /var/lib on the data disk, LAN-only by default, and the Forgejo package pin #137