core: replace the ptrace argv freeze with an exec relay

[congwang-mk]

When a policy_fn or an execve-bound handler inspects argv, the supervisor reads it from the child, judges it, and continues the execve; the kernel then copies argv from the same memory, which sibling threads and CLONE_VM peers can rewrite in between. Until now that window was closed by freezing every sandbox task with ptrace, which in turn needed ptrace fork-event tracking so the freeze knew every task. This PR removes both and keeps ptrace only in checkpoint capture, which has no other way to read a task's registers.

How it works now. An approved execve is redirected to a small freestanding static program, the relay (src/exec_relay/relay.c, x86_64/aarch64/riscv64, embedded with include_bytes!). The relay's image and the judged argv/envp go into one sealed memfd. The supervisor installs it at a free fd K just below the child's soft RLIMIT_NOFILE with SECCOMP_ADDFD_FLAG_SETFD, sets the soft limit to K so no dup2, open, F_DUPFD, SCM_RIGHTS or pidfd_getfd in the sandbox can put another file there, verifies the entry, and rewrites the child's path to /dev/fd/K. The relay, single-threaded with a fresh address space, reads the trailer with pread(K) and execs the target with exactly the argv the policy saw: execveat(dirfd, base) against a directory whose identity it checks for ELF targets in plain mode, and by path for #! scripts (so $0 is right) and under COW and chroot, where the existing exec handlers resolve the target against the now single-threaded relay. The relay's own execve is recognised by the caller's exe inode matching the memfd, restores the soft limit, and passes through without a second policy event.

What the caller sees. Targets the kernel would refuse fail the caller's execve with the same errno first (ENOENT, ENOTDIR, EACCES for DAC or a directory, E2BIG), so execvp's PATH walk still works. argv[0] and comm are preserved. The program that finally runs sees its original soft NOFILE limit. The relay's own syscalls between its two execs are dispatched but never emitted as policy events, so observers such as sandlock learn keep seeing the real program rather than the memfd. Costs and edges: one extra execve per policy-checked spawn; exec failures the supervisor cannot predict (a Landlock exec denial, ENOEXEC) surface as the child exiting 127 with a one-line stderr message; execve-bound extra handlers also see the relay's re-exec, flagged by HandlerCtx::relay_exec; a clone sharing the fd table without CLONE_THREAD is refused with EINVAL under argv policy, since its own rlimit would not pin the fd.

Why not the obvious alternatives. /proc/<supervisor>/fd/N is unreachable from a Landlocked child because Landlock scopes ptrace-mode access and procfs uses it for foreign fd directories (verified). A plain ADDFD'd fd is swappable by a sibling in the microseconds before the kernel opens it; the rlimit pin closes that. The in-place path rewrite has to stay within 16 bytes because CPython's subprocess puts the exec path 16 bytes before the argv pointer array, which cannot move, hence /dev/fd/K rather than /proc/self/fd/K.

Tests. tests/integration/test_exec_relay.rs: a fixture whose sibling thread flips argv between an allowed and a denied word while the process execs, run 40 times, asserting the denied word never runs and whatever runs equals what the policy judged (this test fails on the first attempt if the relay is bypassed); $0 for scripts; argv[0] and comm; ENOENT and EACCES parity; exactly one policy event per exec; 80 subprocess spawns from 8 threads; the restored NOFILE limit; the CLONE_FILES refusal; a chroot rootfs exec; a script written into the COW branch and executed. The existing policy_fn, fork and resource suites pass unchanged. The rewrite-scan fix from #224 is included because the relay path exercises it.

Cross builds of the relay for aarch64 and riscv64 could not be run locally (no cross toolchains here); CI covers both.

🤖 Generated with Claude Code

[congwang-mk]

This is broken, it closes the argv race but opens the path race.