nixos: block namespace creation in the instance units

[euoia]

Closes the kernel local-privesc class that the per-tenant isolation model is exposed to, independently of kernel version.

Why

A site's npm/bun dependency tree executes on the host — the checkout one-shot runs bun install (postinstall scripts) and the preview runs astro dev — all as the per-instance Unix user. Those users are what make the 0400 mode on an instance's deploy key, session secret and password hash actually isolate one instance from another, so a privesc out of one of them defeats the whole model.

Unprivileged user + network namespaces are a standing kernel privesc surface for exactly that code, and a recurring CVE class rather than one bug. A host running 6.18.38 was demonstrably exposed: it was missing the fix for CVE-2026-64581 (xfrm double-free, reachable by an unprivileged user through user and network namespaces, fixed in 6.18.39), and an instance user could both create the namespaces and autoload xfrm inside one:

$ sudo -u astroadmin-<instance> unshare -Urn true
RESULT: YES - unprivileged userns+netns available to instance users
$ sudo -u astroadmin-<instance> unshare -Urn sh -c 'ip xfrm state list'
xfrm-reachable

RestrictNamespaces=true blocks that with seccomp regardless of kernel version, so the class is closed rather than each bug waited out. Keeping the kernel current still matters — this is defence in depth, not a substitute.

What changed

• RestrictNamespaces = true in the shared hardening set → admin + preview units.
• RestrictNamespaces = true on the checkout unit directly. It deliberately does not take the shared set (that is scoped to the long-running units and is not validated against a package install), but it runs bun install — the least trusted code on the host — and the namespace restriction applies cleanly.
• Corrects a false security claim in nixos/README.md.

The README claim is worth a look on its own

It said:

No untrusted code runs on the host: the site code is first-party, and the npm dependency tree builds on Netlify (build-on-push), not here.

That contradicts this module's own header comment, which has always said the dependency tree executes on the host. Netlify builds the public site, which is a different thing. I confirmed the module is the accurate one by running bun install and astro build on a host directly.

A reassurance like that is the kind of sentence that stops someone bothering to harden, so it is a bug in its own right rather than cosmetic rot.

Verification — driven on a live host

Not reasoned about; applied with /run/systemd/system drop-ins, exercised, then removed so the host matched its declared config again.

check	result
vector without restriction (positive control)	entered user ns 4026532448 vs host 4026531837 — genuinely open
RestrictNamespaces=true	unshare: unshare failed: Operation not permitted
RestrictNamespaces=~user net	also blocked (either form works; true chosen as the broader one)
bun install (checkout unit)	Result=success ExecMainStatus=0
astro dev (preview)	HTTP 200, served the expected page
astro build (the Publish path)	9 page(s) built, exit 0
seccomp on running procs	Seccomp: 2 (filter mode) on admin and preview
HTTPS vhost + preview auth gate	unchanged
working tree after astro build	still clean, so it does not trip the ff-only pull guard from #42

An earlier version of the positive control "passed" only because true was not on the unit's minimal PATH — the unshare had actually succeeded. That would have been a false negative in the direction that matters, so the control was rewritten to compare namespace inodes instead of relying on an exit code. Similarly, a first attempt to apply the drop-ins under /etc/systemd/system silently failed (read-only on NixOS) and systemctl show reported RestrictNamespaces=no — caught by checking the property rather than trusting the write.

Deploying

Needs a flake pin bump in the ops repo to reach a host. Worth landing alongside a kernel update so both halves arrive together.

Follow-up, not in this PR

The checkout unit gets no other hardening at all, despite running the least trusted code — no ProtectSystem, ProtectHome, PrivateTmp or the rest. Extending the shared set to it looks feasible (its StateDirectory covers the writes it needs) but wants its own testing round against a real bun install.