Command sandbox: confine untrusted native command execution (Landlock + seccomp)

[ericeil]

What this is

A standalone command-sandbox mechanism — a Python seam + a small trusted Rust launcher — that confines a single command to an unprivileged, in-process kernel sandbox (Landlock + seccomp). It is the first of the stacked PRs splitting eric/crucible (see docs/pr-split-plan.md).

from composer.sandbox import run_local_command, rust_build_policy, SandboxPolicy

It has no composer dependencies outside composer.sandbox and is stdlib-only, so it can land and be consumed ahead of everything else on the branch.

Why this code exists

For the Solana ecosystem, AutoProver will need to run commands that compile and/or execute untrusted native code — LLM-authored harnesses (setup/action_*/build.rs), the analyzed program's own build.rs/proc-macros, and/or the Cruicible fuzzing harness, for example. Without a sandbox, those will run with the full ambient authority of the AutoProver process: ANTHROPIC_API_KEY, CERTORA*/AWS_* cloud tokens, PG* DB creds, the network route to 169.254.169.254 (IMDS → IAM role creds on EC2), and the entire bind-mounted host project.

The outer container protects the host from AutoProver. It does not protect AutoProver's own secrets, egress, and filesystem from code running inside it. A separate trust boundary already ensures the LLM authors only file contents, never the command line — but that says nothing about what a command, once running, can reach. This mechanism is that missing boundary: each RunCommand runs with no network, no inherited secrets, and only its declared inputs on disk, proven by an escape test.

Why we can't use an existing solution

Namespace sandboxes (bwrap / nsjail) — they fight the container. Their model (unprivileged user + mount + net namespaces, then pivot_root) is exactly what Docker's default seccomp + AppArmor block. Validated empirically (stock python:3.12-slim, uid 1000):

Approach under Docker defaults	Outcome
unprivileged bwrap	✗ userns creation blocked by default seccomp
bwrap, seccomp=unconfined	✗ mount --make-rslave blocked by AppArmor docker-default
bwrap, seccomp=unconfined + apparmor=unconfined	✓ works — but requires weakening the whole container's LSMs (rejected)
setuid bwrap	✗ capset blocked (Docker drops CAP_SETPCAP)

Making bwrap work means either stripping the container's own seccomp/AppArmor (widening the host-kernel attack surface across all of AutoProver — the opposite of the goal) or adopting a heavier runtime.

gVisor / Kata — wrong cost, wrong layer. They work, but (a) they impose their heaviest overhead precisely on our syscall/I/O-bound compile+fuzz workload, and (b) their benefit — protecting the host kernel — is an infrastructure boundary already provided on EC2 by the Nitro hypervisor. Not worth coupling this boundary to a deployment/runtime decision.

Off-the-shelf Landlock tools — close, but each misses the hard part.

• landrun (Go, MIT): great for Landlock FS + env, but blocks network via Landlock TCP-only rules (kernel ≥6.7) — it does not block UDP/DNS, fails open on older kernels, and has no rlimits. It would need a seccomp companion anyway, so it doesn't save the hard part.
• sandlock (Python+Rust, Landlock+seccomp): the closest match, but requires kernel ≥6.12 (above Amazon Linux 2023's 6.1), ships an unstated license, and carries far more surface than we need (MITM proxy, COW, notification supervisor).

The chosen model: the process sandboxes itself

Instead of building a namespace around the command, the command restricts itself using two unprivileged kernel facilities — the model Chrome, OpenSSH, and systemd use. It needs no namespaces, no capabilities, no root, and no --security-opt, and runs in a stock container. The launcher composes two mature, permissively-licensed crates rather than hand-rolling primitives:

• landlock — default-deny FS ruleset; grant rw to the workdir, r+x to toolchain paths; closes the /proc/<parent>/environ secret leak.
• seccompiler (AWS Firecracker's seccomp-BPF compiler) — deny inet sockets (TCP and UDP/DNS and IMDS) and the same-uid secret vectors (ptrace, process_vm_readv).
• plus an env allowlist (scrubbed execve) and rlimits (RLIMIT_AS/CPU/NPROC/FSIZE).

Both confinements are preserved across execve and inherited across fork, so every descendant (cargo, rustc, each build.rs, the linker) runs confined. It wins for now on kernel floor (5.13), license clarity, and minimal surface — and the SandboxProvider seam keeps landrun/sandlock swappable later with no change to the policy or the gate. Because it needs nothing from the container, the identical code path runs on a dev laptop, EC2, ECS, EKS, Fargate, and under runc or gVisor alike.

What's in the PR (20 files, +2.4k)

• Python composer/sandbox/ (stdlib-only): policy.py (tool-agnostic seam: SandboxPolicy/SandboxProvider/LaunchSpec, none passthrough, provider registry, fail-closed helpers), command.py (run_local_command — the RunCommand primitive), launcher.py (the launcher provider), recipes.py (rust_build_policy + DEFAULT_ENV_PASSTHROUGH), config.py.
• Rust rust/run-confined/: the trusted launcher; workspace root trimmed to members = ["run-confined"] (the pyo3 framework crates rejoin in later PRs), Cargo.lock regenerated for that subset.
• Packaging/docs: scripts/Dockerfile builds run-confined onto PATH; .dockerignore/.gitignore exclude the Rust build output; docs/command-sandbox.md (full design + threat model).

Testing

tests/test_sandbox{,_command,_config,_launcher,_run_confined,_escape}.py → 42 passed, 0 skipped. The escape gate exercises every vector (write outside workdir, read host files, read /proc/<parent>/environ, ptrace the parent, open an inet socket) — all denied — plus an unconfined control. The run-confined binary was built and genuinely exercised (Landlock ABI present on the CI kernel), not skipped.

Notes for reviewers

• Base: branches from a clean ancestor of master; verified zero file overlap with the commits master has since gained, so it merges cleanly and the diff shows only the 20 sandbox files.
• Stacked-PR context: this is PR 1 of 4 (sandbox → ecosystem → rust framework → crucible app). The framework/Crucible consumers land in later PRs; this PR stands alone.

[shellygr]

in Solidity AP we already have a split between the 'dependency fetch' task and actual building, using a separate builder container that is not in this repo. does it make sense to move cargo fetch steps into the builder repo as well? let's sync over DM

[ericeil]

Oh, that's interesting. Yes, if we can build the user's code separately in a more locked-down container, that would be ideal. I think we will still need the sandbox (both in the "builder" container, and later when we build the LLM-generated code), but some more defense-in-depth would be great here. Will track this as a separate workitem for now.

[ericeil]

Security audit summary

Focused review of PR #73 against the guarantees in docs/command-sandbox.md §2:

1. No network (incl. DNS / IMDS)
2. No secrets (env scrub + no out-of-band recovery)
3. Minimal filesystem
4. Resource caps
5. Offline builds

I probed a live run-confined binary on this host (kernel 7.0, Landlock enforcing). Several intended vectors are correctly closed (env scrub, Landlock outside-workdir, /proc/<ppid>/environ, ptrace/process_vm_*, hardlink-out, direct socket(AF_INET)).

However, guarantee #1 is fully breakable today, and several same-uid control-plane gaps remain. Highest severity first.

Issue counts by severity

• bugs (security): 4
• suggestions: 2
• nits: 1

Verified with live probes

Vector	Result under sandbox
socket(AF_INET)	DENIED (EPERM) — as designed
io_uring IORING_OP_SOCKET + CONNECT to 1.1.1.1:80	SUCCESS — full network bypass
io_uring connect to 169.254.169.254:80	SUCCESS (TCP connect)
Abstract Unix socket to same-uid listener outside sandbox	SUCCESS
kill(SIGKILL) any same-uid process	SUCCESS
Read planted file under RO-granted cargo home (credentials.toml)	SUCCESS
AF_NETLINK / AF_VSOCK socket()	SUCCESS
Landlock outside file via normal open / io_uring OPENAT	DENIED
Env canary / ptrace / process_vm_readv	DENIED

Bottom line: untrusted code inside the sandbox can reach the network (including IMDS) today via io_uring, despite the seccomp deny-list on socket(). That is a direct violation of the stated threat model.

[ericeil]

Oh, that's interesting. Yes, if we can build the user's code separately in a more locked-down container, that would be ideal. I think we will still need the sandbox (both in the "builder" container, and later when we build the LLM-generated code), but some more defense-in-depth would be great here. Will track this as a separate workitem for now.

[ericeil]

Did security reviews and testing with both Grok and Opus, and fixed the problems they found. Added a CI test to verify the sandbox against Amazon Linux 2023.

[chandrakananandi]

Had a couple of small questions.

[chandrakananandi]

why not use Clap: https://rust-cli.github.io/book/tutorial/cli-args.html#parsing-cli-arguments-with-clap? That's usually the way to do CLI arg parsing in rust. Maybe ask claude about it?

[jtoman]

Chandra, would you say there you're...

...clapping back?

[ericeil]

Yep, that's probably a better choice

[chandrakananandi]

do we know what these limits are needed for?

[ericeil]

Their meanings are described in comments on the new Clap-based CLI options. These are here so we can e.g. limit the memory usage of the Crucible process so it doesn't interfere with the main service. I suspect we'll want more control over this some day, but these particular limits are easy to implement. :)

[jtoman]

typed dict imo

[jtoman]

it seems like this check is sufficient andyou can skip the p.is_absolute / .. in p.parts check above?

[ericeil]

yep

[jtoman]

claude loves to narrate these pointless "why" and "what we didn't do" details. No one needs this justification.

[jtoman]

claude loves to keep mentioning this fail-closed term, I have never heard of it.

[ericeil]

Heh, yeah, I wondered about that. Says Claude:

"Fail-closed" is a security design principle: when the safety mechanism can't do its job, the system refuses to run rather than running unprotected.

Here at command.py:122, ensure_available(prov) checks whether the selected sandbox provider can actually confine the child process (e.g. for the launcher provider: is run-confined present, does the kernel support Landlock + seccomp, etc.). If it can't, ensure_available raises SandboxUnavailable before the command is ever spawned. So the command never runs unsandboxed.

The contrast is fail-open: if confinement were unavailable, quietly fall back to running the command with no sandbox. That's the dangerous default — you'd get a working command and silently lose the security boundary, which is exactly what you don't want for something running potentially-untrusted toolchains.

[jtoman]

more compact

async with (sem if sem is not None else contextlib.nullcontext)):
   return await _run()

or, if you prefer to abuse or syntax:

async with (sem or contextlib.nullcontext):
   ...

but I personally hate abusing or like this

[ericeil]

cool

[jtoman]

this lets you expression nonsense like Availability(ok=True, reason="everything is broken"). Python typing does allow sum types, so you could go type Availability = Literal["ok"] | Reason where:

@dataclass
class Reason
   reason: str

or sth

[jtoman]

uh?

[ericeil]

Will simplify this

[jtoman]

probably want extend

[chandrakananandi]

Thanks for getting this started!

[jtoman]

All the other python changes look quite cromulent. One glaring hole, which could be attributable to me failing to read...

[jtoman]

at the risk of asking a stupid question: ... where is this function? I don't see get_provider in composer.sandbox.policy and I scanned all the files in composer.module and didn't see any entry point magic. Did you forget to patch that in perhaps?