[prabhu]

OpenAI's write-up on securing their model training environment (Securing our frontier model training environment) describes agents getting past containment without breaking any single rule:

• reusing an allowed connection to reach a blocked endpoint
• getting an allowed service to fetch a URL they supplied
• leaking through DNS
• signalling between isolated sandboxes by alternating disk writes or CPU load with idle periods

Most of these can't be blocked without breaking ordinary builds. So this PR makes safer-exec report them instead. All of these checks only add audit entries: they run when auditing is on, deny nothing, and need no new configuration.

What gets reported

• proxy-sni-mismatch: a tunnel's TLS server name doesn't match the host in its CONNECT. That is domain fronting through a CDN or a shared front end.
• proxy-embedded-url: a plain-HTTP request carries a URL for another host in its query or path. The entry names only the request's host and port, the parameter, and the embedded URL's host. Paths and values are never logged.
• proxy-upload-heavy: the workload uploaded at least 1 MiB to an allowed host, and at least four times what came back. An upload split across many targets is caught for the run as a whole. Tunnels the server keeps open are closed and counted at the end of the run.
• proxy-bypass-attempt (Linux): UDP sockets, and connections or sendtos that skip the proxy. The proxy only sees what is sent through it, Landlock doesn't confine UDP, and it confines TCP only by port. So DNS, QUIC, or a direct connect on an open port all go around the hostname allowlist today. To see these, the inner process installs a seccomp user-notification filter and hands the listener to the engine with SCM_RIGHTS. The engine records each call and always lets it continue.
• timing-channel-suspect (Linux, Windows): the sandbox's total CPU time (and IO, where the counter exists) switches between idle and busy at least 16 times in 10 seconds. The data comes from the run's cgroup on Linux and the job object on Windows.
• shared-write-path / shared-lock-file: another safer-exec run of the same user, running at the same time, can write the same path or holds the same lock. Runs register in a per-user directory under the user cache dir, and the macOS profile denies the workload access to it.

README has a section describing each entry, and THREAT-MODEL §3.21 lists what these checks can't catch. In short:

• cache-timing channels
• HTTPS request contents
• unconnected sendmsg destinations
• a sender that stays under the thresholds

THREAT-MODEL also corrects the row that called UDP evasion "Mitigated"; that only holds with disableNetwork.

Fixed along the way

Inside the PID namespace every --init is pid 1, so every Linux sandbox named its cgroup safer-exec-1. Concurrent runs with limits collided: one of them silently lost its limits, and the directory was left behind. Each run now gets a unique name on both cgroup v2 and v1, and the engine removes the directory when the run ends. The init thread is also locked to one OS thread now. That keeps Landlock and seccomp on the thread that execs the target.

Review

An independent adversarial review found real problems, and all of them are fixed here. The main ones:

• In the first version, when the engine couldn't take over the seccomp listener (Docker's default profile denies pidfd_getfd), the workload's own connects failed with ENOSYS. The handoff now uses SCM_RIGHTS, which needs no permission the engine could be refused.
• A macOS workload could put a FIFO in the run registry, which was then in $TMPDIR, and hang every later run. The registry moved to the user cache dir, the Seatbelt profile denies it, and records are read with no-follow, non-blocking, size and count limits.
• Embedded-URL entries could log secrets carried in the request path.
• Uploads could slip past the check in two ways: by keeping the tunnel open, or by spelling the port as 0443.

Version

Bumped to 1.3.0.

Testing

Each environment ran this branch and main side by side:

Environment	Result
macOS arm64	Go suite passes with -race. Two concurrent audited CLI runs: the second reported shared-write-path. A workload granted ~/Library/Caches can't list or write the registry.
Docker on OrbStack, arm64 (Debian privileged, Debian with the default seccomp profile, Alpine)	No new failures compared with main. The other failures there also fail on main (read-only /tmp, missing curl, test data outside the mount). Under the default profile, the workload still reaches the proxy, and UDP and direct connections are reported.
Ubuntu 24.04 x86_64, unprivileged	Go passes on both trees. Node unit, integration, security and hooks tests: 601 pass, 0 fail on both. The cgroup sampler test passes under systemd-run --user --scope -p Delegate=yes.
Windows 11 ARM64, MXC c6f301d (base-container tier)	go vet clean, all packages pass. An audited workload alternating CPU bursts with sleep is reported from the job object's counters.