Support per-path unix socket allowlisting on Linux

[shawnm-anthropic]

network.allowUnixSockets works on macOS only. On Linux the seccomp filter denies socket(AF_UNIX, ...) outright, so a command that talks to a local daemon over a unix socket has nothing between "blocked" and allowAllUnixSockets: true — which also hands it docker.sock, tmux, and anything else listening on the machine. This ports the setting to Linux.

How

seccomp-bpf cannot read a socket path out of user memory, so the allowlist is enforced one level up. With any entry configured, apply-seccomp installs a user-notification filter instead of the blocking one, and a supervisor process performs each connect()/bind()/listen() itself on the caller's socket, permitting a unix connect only when the canonical target is inside the allowlist.

It never answers SECCOMP_USER_NOTIF_FLAG_CONTINUE for those syscalls. Continuing re-executes the syscall from the caller's own memory and fd table, which a sibling thread can rewrite in between — inspect-then-continue is racy by construction. Instead the supervisor takes its own reference to the socket (pidfd_getfd, which shares the open file description, so O_NONBLOCK/EINPROGRESS stay the caller's), its own copy of the sockaddr (process_vm_readv, with the notification id as the pid-reuse guard), and connects through a pinned O_PATH handle of the target inode rather than walking the path again, so no symlink or rename swap after the check can redirect it.

Still refused with an allowlist configured:

• unix bind() and listen() — a sandboxed command connects to services, it does not publish them. listen() is refused separately because the kernel autobinds an abstract name behind bind()'s back when SO_PASSCRED is set and a connect fails.
• the abstract namespace, which has no path to match against
• datagram unix sockets, including the SOCK_RAW spelling the kernel maps onto SOCK_DGRAM, whose sendto() carries a destination path of its own
• seccomp(..., SECCOMP_FILTER_FLAG_NEW_LISTENER) and the seccomp notification ioctls — notifications go to the most recently installed listener, so without this a workload could install one, receive its own connect() traps and answer CONTINUE. Denying it is also what makes a dead supervisor fail closed (ENOSYS) rather than open.

The supervisor is forked before the PID-namespace unshare: after that unshare a fork lands inside the sandbox's own PID namespace and the kernel refuses CLONE_THREAD outright, leaving no way to service a blocking connect off the receive loop. So it is neither addressable nor signallable from inside the sandbox, sets PR_SET_DUMPABLE=0 so nothing can ptrace the listener fd out of it, and caps brokered calls in flight so a workload cannot exhaust it with parked connects.

Entries that do not resolve are dropped, and so are entries the sandbox can also write: link(2) works on socket inodes and fs.protected_hardlinks only stops linking another user's, so a writable allow-listed directory is one hard link away from every other socket the user owns. A denyWrite carve-out on the socket's directory allows it.

Where the sandbox restricts writes nowhere — no writeConfig, or filesystem.disabled (which is allowOnly: ['/']) — that rule has nothing to hold onto, so every entry is dropped with a warning naming the reason. Worth knowing for anyone force-enrolled into the sandbox without filesystem isolation: they get the old blocking behavior rather than an allowlist that cannot mean anything.

Compatibility

• Requires Linux 5.6 (pidfd_getfd). Older kernels print a warning and keep blocking unix sockets entirely — degraded, never permissive.
• With no allowlist configured the filter and the process layout are unchanged.
• TCP is unaffected in both modes; brokered calls cost ~100 µs each and the data path is untouched.
• The allowed server sees the supervisor's pid in SO_PEERCRED (uid/gid are the workload's), so servers that authorize by peer pid will not recognize the caller.

Verification

Driven end-to-end through the srt CLI on Linux, A/B against origin/main with the same config and fixture:

	origin/main	this branch
allow-listed socket	EPERM	connected
other socket	EPERM	EPERM

Race coverage: 6 s × 300k connects with a thread rewriting the sockaddr, and another run with the fd also dup2-swapped between AF_INET and AF_UNIX — the forbidden listener accepted 0, self-detected violations 0. The same harness pointed at a filter that allows everything lands ~40k accepts, so it does detect what it claims to.

New test/sandbox/unix-socket-allowlist.test.ts (19 tests, Linux-only) covers allow/deny, symlinks both directions, relative paths, abstract, bind/listen, dgram + SOCK_RAW pairs, the NEW_LISTENER deny, TCP staying intact, dropped entries, grandchildren, and brokering alongside violation observation (both share the one listener the kernel allows). Cross-compiled clean for x86-64 and arm64 with -Wall -Wextra.

[sylvesterkaczmarek]

broker_thread() still has an allocation-failure path that can wedge the sandbox: resp = calloc(...) is nullable, but broker_handle() runs regardless. If that connect succeeds, the duplicated socket is already mutated, then no SECCOMP_IOCTL_NOTIF_SEND occurs and the original syscall remains blocked indefinitely. Could the response buffer be allocated before brokering (or otherwise guarantee a reply) and avoid executing the syscall when that allocation fails?