feat(system): persist kernel.yama.ptrace_scope=0 so the keylog spin capture can attach

[ZacxDev]

Staged /etc/nixos change (Claude can't sudo nixos-rebuild), run with:

sudo bash nix/system/apply-ptrace-scope.sh

Why

keylog-spin-capture uses py-spy to dump keylog.service — a sibling systemd --user unit, never a descendant of the capture. Yama's default scope=1 ("descendants only") blocks both PTRACE_ATTACH and process_vm_readv, so the watcher hits its sysctl gate and exits silently every 5 minutes. It is enabled and structurally incapable of ever succeeding.

The workbench read 0 for most of 2026-07-30 only because of a manual echo 0 | sudo tee during the investigation. That was never persisted, so the 2026-08-04 reboot reset it to 1 and the watcher went inert.

An earlier revision of the perf script had this as a prompted step. The audit removed it — correctly, since the live value was already 0 and it would have bought nothing. That reasoning is now stale; the reboot is what changed the facts.

The trade, stated rather than buried

scope=0 is the traditional Linux default: any process may ptrace another running as the same UID. It grants no cross-user or root access. But on a box routinely running agent-spawned code as this user, it widens what a compromised same-user process can read from other processes' memory — browser sessions, kubeconfigs loaded into a running tool, ssh-agent.

Two narrower alternatives, rejected with reasons in the script header:

• CAP_SYS_PTRACE on the capture unit — systemd --user services can't gain capabilities. It would have to become a root system unit, which is a larger privilege grant, not a smaller one.
• Run py-spy as root ad hoc — works, but defeats the point: the mechanism exists to catch a spin that appears unpredictably over 24h+, precisely when you aren't there to run something.

If you'd rather not take the trade, the honest alternative is to drop the watcher — it degrades safely (detects scope!=0, exits quietly, no dump/toast/retry), but it will never fire.

Includes the systemd-sysctl restart — and here it's warranted

nixos-rebuild switch does not restart systemd-sysctl (nixpkgs#289174), so a new boot.kernel.sysctl edit stays inert on the running kernel. The earlier perf script deliberately dropped this restart because nothing was pending. Here something is.

Verification

Tested against a scratch copy of the live configuration.nix:

non-TTY run          rc=0, completes (no mid-edit abort)
second run           "[1/3] ptrace_scope already declared — skipping"
resulting diff       exactly one attribute, inside boot.kernel.sysctl
nix-instantiate      parses clean after two runs

Backs up first, restores on any failure before validation, prompts before nixos-rebuild (skipped safely on non-TTY), prints a rollback line — including if the rebuild itself fails.

🤖 Generated with Claude Code