feat(enforce): seccomp user-notify enforcement tier (E4)

[gnanirahulnutakki]

Summary

Implements E4: the seccomp user-notify enforcement tier, the common-case fallback for hosts where BPF-LSM never loads — stock distros ship CONFIG_BPF_LSM=y but don't put bpf in the boot lsm= list, so the BPF-LSM tier (#101, merged) silently isn't active. Part of Epic A (#63). Builds on the merged E1 (#101, privileged CI), E2 (#96, apply_policy wiring), and E3 (#100, enforce_events correlation hardening).

• ardur-exec-shim (new binary): installs a connect(2)-scoped SECCOMP_RET_USER_NOTIF filter, hands the notification listener fd to the daemon over a dedicated Unix socket via SCM_RIGHTS, then execve()s into the target — the filter (installed before exec, inherited across it) covers the whole process tree from there with no per-child re-registration.
• Daemon supervisor (daemon_seccomp_linux.go): services notifications using the same policy tables and net_allow CIDR matching as the BPF-LSM tier (SeccompPolicyStore mirrors bpf_policy_apply.go's schema), re-validates the notification id via SECCOMP_IOCTL_NOTIF_ID_VALID both before and after each /proc/pid/mem read (the standard seccomp-notify TOCTOU mitigation), and fails closed (EPERM) on any ambiguous or error case — SECCOMP_USER_NOTIF_FLAG_CONTINUE is only ever set on a confirmed, policy-resolved ALLOW.
• Tier selection: the daemon attempts BPF-LSM at startup; if it doesn't load, it falls back to seccomp and advertises the active tier (bpf_lsm / seccomp / none) on health responses, so a launcher knows whether routing through ardur-exec-shim is necessary. apply_policy keeps the seccomp policy store in sync regardless of which tier is active, and reports genuine success (applied_seccomp_tier, not degraded) when the active tier fully covers the request.
• Evidence pipeline: processEnforceEvent now takes an explicit tier parameter (previously derived internally, always bpf_lsm:*) so seccomp-tier events are correctly labeled seccomp:enforce/seccomp:permissive in TierCoverage, sharing the same hash-chained receipt format.
• Claim boundary, stated plainly, not left implicit: seccomp user-notify is weaker than an in-kernel LSM against a racing multithreaded adversary — the supervisor's decision happens in a userspace round-trip, not synchronously in the syscalling thread. This is a real, load-bearing enforcement mechanism for single-threaded or cooperative targets (the overwhelming majority of AI-agent subprocess trees this project governs), documented in seccomp_policy.go's header comment, not a theoretically-airtight guarantee against an adversarial multithreaded target.

Two real bugs found only by kernel-in-loop verification

Neither pure-Go tests nor go vet could catch these — both were found by actually running the shim + daemon against a real kernel:

1. Shim self-deadlock: the shim's own connect() to the daemon's handoff socket was trapped by the filter it had just installed (seccomp intercepts by syscall number only, with no socket-family awareness) — since nothing was servicing that listener yet, the connect blocked forever. Fixed by dialing the handoff connection before installing the filter (see ardur-exec-shim/main.go's run() comment).
2. errno sign bug: SendSeccompNotifResp wrote a positive errno (e.g. unix.EPERM = +1) into the kernel's seccomp_notif_resp.error field, which requires the raw syscall-return convention (-errno). A non-negative raw return is treated as success by the kernel — so a policy-denied connect() was silently let through with a nonsense return value instead of being blocked. Fixed by negating internally in buildSeccompNotifResp, with a regression test (TestBuildSeccompNotifResp_NegatesErrno) and a permanent kernel-in-loop smoke test (see below) guarding it going forward.

Testing

• Pure-Go / cross-platform: seccomp_sockaddr_test.go, seccomp_policy_test.go — sockaddr decoding, policy store semantics (ALLOW/DENY/ALLOWLIST, CIDR + bare-IP matching, enforce vs permissive, fail-closed on unknown action, nil-store handling), tier-refactor coverage in daemon_enforce_test.go/daemon_apply_policy_test.go.
• Linux-only, no kernel required: seccomp_notify_linux_test.go — ioctl number pinning against known runc/containerd values, sock_fprog kernel-ABI layout, and a small classic-BPF interpreter that runs the actual assembled filter program against synthetic seccomp_data to prove its three-way decision logic (arch mismatch → kill, matching arch + wrong nr → allow, matching arch + connect's nr → user-notify).
• Real kernel, both platforms confirmed green: go build/go vet/go test -race ./... pass on darwin and Linux (verified in a Docker container matching an unprivileged CI runner — no --privileged, no extra capabilities, CONFIG_BPF_LSM present but bpf not in the active LSM list, exactly the scenario this tier targets).
• New CI job (seccomp-smoke in kernel-enforce.yml): runs ardur-seccomp-smoke, a permanent kernel-in-loop harness that starts a real daemon (BPF-LSM unavailable → seccomp fallback engages), runs the real shim against a real target process, and asserts a policy-denied connect(2) gets EPERM while a policy-allowed one reaches the kernel's real connect handling (observed as ECONNREFUSED, proving the syscall wasn't blocked). Unlike kernel-smoke (BPF-LSM tier), this needs no KVM/virtme-ng custom kernel boot — confirmed empirically that seccomp(SECCOMP_SET_MODE_FILTER, SECCOMP_FILTER_FLAG_NEW_LISTENER, ...) works under an ordinary PR_SET_NO_NEW_PRIVS-only process, so it runs on a plain ubuntu-24.04 runner. Set as a required check (not soft-gated like kernel-smoke) since it needs no unproven VM-boot machinery.

Honest gaps / what's not in this PR

• The CI job itself has not yet run on an actual GitHub-hosted runner — it's manually verified end-to-end in a local Docker container configured to match those conditions (unprivileged, no BPF-LSM), but the first real CI run on this PR is the true confirmation that GitHub's runner environment behaves the same way.
• Exec/file-open enforcement is out of scope for this tier by design (documented in seccomp_policy.go) — a seccomp filter can trap execve, but by the time a SECCOMP_RET_USER_NOTIF notification is serviced the new program image hasn't loaded yet, and SECCOMP_USER_NOTIF_FLAG_CONTINUE for execve carries TOCTOU hazards beyond what connect's fixed-size sockaddr argument has. BPF-LSM remains the only tier that governs exec and file ops.
• No ardur run / launcher-side wiring to actually invoke ardur-exec-shim based on the daemon's advertised tier — that's launcher-side follow-on work, not part of this daemon/shim-side PR.

Ref: #63