feat(keylog): PR_SET_PTRACER_ANY opt-in — narrower alternative to #334 (no host-wide ptrace_scope=0)

[ZacxDev]

Narrower alternative to #334. Do not merge alongside it — these are two ways to solve the same problem; pick one.

The problem (same premise as #334)

keylog-spin-capture uses py-spy to dump keylog.service, a sibling systemd --user unit — never a descendant of the capture. Yama kernel.yama.ptrace_scope=1 (the fleet default) blocks both PTRACE_ATTACH and process_vm_readv for a non-descendant even at the same UID, so the watcher hits EPERM and is inert. Live workbench reads 1.

What #334 does vs. what this does

#334 persists ptrace_scope=0 system-wide and permanently — exposing every same-UID process (browser sessions, kubeconfigs in a running tool, ssh-agent) to memory-read, forever, and needs a root /etc/nixos edit + a systemd-sysctl restart.

This uses the strictly smaller mechanism #334 never considers: the tracee opts itself in via prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY). Yama scope=1 explicitly honours this. Result: ptrace_scope stays at its hardened 1, and exposure is exactly one process, only while it runs — no root, no /etc/nixos edit, no reboot-survival question, no fleet-wide hardening loss.

Changes

• keylog.py — _allow_any_ptracer() runs first thing in main(). Constants verified against <linux/prctl.h>: PR_SET_PTRACER=0x59616d61, PR_SET_PTRACER_ANY=(unsigned long)-1. Gated on KEYLOG_ALLOW_ANY_PTRACER; fail-soft (non-Linux / old kernel / missing libc / EINVAL logs and continues — never crashes the collector).
• home.nix — sets KEYLOG_ALLOW_ANY_PTRACER=1 on keylog.service, gated on enableKeylogSpinCapture (workbench-only). So a host not running the capture never opts its keystroke collector in. Stale "laptop reads 1 → py-spy can never attach" comments corrected (that rationale no longer holds; workbench-only is now purely a py-spy build-cost decision).
• keylog-spin-capture.sh — the hard scope != 0 → exit gate (what makes the watcher inert today) relaxed to bail only on scope >= 2 (which needs CAP_SYS_PTRACE the opt-in can't grant).
• tests/test_ptrace_optin.py — 6 regression tests. RED on origin/main (AttributeError, function absent) → GREEN after.

Trade-off, stated straight — not sold as free

PR_SET_PTRACER_ANY opens keylog — a keystroke collector, arguably the single most sensitive process on the box — to any same-UID tracer for its whole lifetime. Pinning one tracer PID isn't practical: the watcher is a oneshot whose PID changes every 5-minute tick. The mitigating fact (a boundary statement, not an excuse): a same-UID attacker can already read keylog's on-disk spool at ~/.local/state/activity/spool, so live-memory read does not cross a new trust boundary — it's the same same-UID boundary in a different shape. That, plus the env-gate keeping it workbench-only, is why the blast radius is far smaller than #334's.

Verification (all with ptrace_scope left at 1, on a live scope=1 kernel)

Rig — sibling (non-descendant, same-UID) tracer, negative control in each arm:

arm	process_vm_readv	PTRACE_ATTACH
tracee does NOT opt in	-1 EPERM	-1 EPERM
tracee calls PR_SET_PTRACER_ANY	n=29, read the canary CANARY-9f3a2b6c-deadbeef-rig	rc=0 ATTACHED

End-to-end with the real consumer — py-spy against a stand-in that called the real _allow_any_ptracer:

• opt-in ON: py-spy dump (plain) and --native both return full frames.
• opt-in OFF (real helper returns early): both get Permission Denied.

Regression matrix: test_ptrace_optin.py — 6 failed at origin/main, 6 passed at HEAD. Full keylog suite 67 passed.

Note on the ptrace_scope=0 history (#334 vs the perf script)

#334 attributes the earlier workbench 0 to a manual echo 0 | sudo tee; apply-perf-tuning-2026-07-30.sh:55-58 asserts the host "already reads 0 (nothing in /etc/sysctl.d sets it)". Discriminating signals: (a) the flake.lock nixpkgs pin last changed 2026-07-29 and is unchanged across the 2026-08-04 reboot — no bump in the window; (b) on a live host from this pinned nixpkgs, nothing (/etc/sysctl.d, systemd 50-default.conf, NixOS 60-nixos.conf) sets ptrace_scope, so the value is the kernel compile-time default; (c) CONFIG_SECURITY_YAMA=y with no override → mainline default YAMA_SCOPE_RELATIONAL=1. So the default was 1 both before and after; a reading of 0 had to come from a transient override. This supports #334's manual-echo explanation and refutes the perf script's "reads 0 as default" claim — the fleet's hardening posture did not silently flip via a nixpkgs default change. (Caveat: measured on a representative host from the same pin, not the workbench's own generation history, which I did not disturb.)

🤖 Generated with Claude Code