feat(sandbox): default-on build jail

[colinhacks]

What this is

The first cut of the nub-sandbox engine crate — step 1 of the sandbox build sequence (.fray/sandbox.md engine architecture): the OS-enforced script sandbox.

"Script sandbox" is the umbrella — it confines the SCRIPTS nub runs on the user's behalf, and spans two profiles of one engine: (a) dependency lifecycle / install scripts (the profile shipping in this PR), and (b) nub run script execution (the planned runtime profile). Same {env, fs, net, pid} policy model, same per-OS backends; the profiles differ only in default scope. The crate name nub-sandbox is the umbrella; this PR ships its install/build-script profile.

That install-script profile is the drop-in successor to aube's bundled install-script sandbox, at or above parity. It is a default-ON sandbox over dependency lifecycle scripts (install/postinstall/preinstall/prepare): block the supply-chain attack canon (secret exfil, C2/beacon egress, out-of-package writes, persistence) while letting legitimate native builds (node-gyp / prebuild-install) through. Design + evidence base: .fray/script-sandbox-design.md (§3 net, §4 fs-read, §5 fs-write, §8.5 attack→capability→default table).

What's in this PR

• New crates/nub-sandbox workspace crate. The unified SandboxPolicy {env, fs, net, pid} schema (one model, both profiles), the install/build-script profile preset (script_sandbox) assembling the §3/§4/§5/§8.5 defaults, the secret deny-sets (classic creds + wallet/keystore + browser profiles + IDE/agent/persistence write-deny + recursive .env*), and the egress allowlist as DATA.
• Backends: macOS Seatbelt (fully implemented), Linux Landlock+seccomp (implemented; capability-probe + graceful-degrade, never bwrap), Windows (honestly scaffolded — env-scrub only, reports the gap).
• Enforcement posture: deny-by-default on env/fs-write/net; fail-SAFE — a missing OS primitive degrades the affected axis with a one-line warning, never silently drops a claimed guarantee, never hard-fails an install.

Verification

• 24 macOS tests green (17 unit + 7 e2e), clippy --all-targets -D warnings + fmt clean.
• Linux verified under Docker: 16 unit + 3 e2e enforcement tests green; clippy --all-targets -D warnings clean.
• Real e2e enforcement (not just policy-struct asserts): a malicious-shaped script cannot read a seeded ~/.ssh secret or a project .env, cannot write outside the package dir / into project source / into HOME, cannot egress — while a legit native-style build (read project, write package dir, write cold-cache ~/.cache/node-gyp) still succeeds. Includes a regression test that a parent-process secret env var does NOT leak into the sandboxed script.

Adversarially reviewed

Three independent Opus reviewers (enforcement soundness, per-OS backend correctness, breakage axis) + a Pullfrog review. Every critical/high finding fixed in this PR, including two the e2e tests then locked in:

• macOS sandbox-exec wrap was re-leaking the parent's full env past the scrub (fixed: env_clear the wrapped command + regression test).
• a broken *.s3.* wildcard + a *.githubusercontent.com entry that admitted attacker-controlled raw.githubusercontent.com (fixed: exact hosts, fail-closed multi-*, trailing-dot normalization).
• Linux falsely reported full fs enforcement while Landlock (allow-only) can't deny secret subpaths (fixed: surfaced as an honest fs-read-deny degradation; recursive read-carve is the tracked follow-on).
• Linux seccomp EINVAL'd the spawn when Landlock was absent (fixed: NNP-first + a safe syscall-based Landlock probe).
• Polish: documented write_deny_relglobs as not-yet-enforced (runtime-profile forward data), dropped unused deps (glob-match, macOS-target libc), documented the macOS .env-only glob limitation.

First-cut vs REMAINING (honest phasing)

This is the engine; it is intentionally not yet wired into the install lifecycle, and the default-ON flip is not in this PR:

1. Egress proxy not wired — macOS/Linux currently deny ALL direct egress (fail-safe coarse). Per-host allowlisting needs the §3 localhost HTTP+SOCKS5 proxy. Consequence both breakage and enforcement reviewers flagged: default-ON with net-full-deny would break uncached native fetches (node-gyp headers, prebuild-install binaries). So the embedder-wiring phase decides the net default (proxy, cache-prewarm, or net-permissive-but-fs/env-enforced) — next PR + a maintainer-owned default call.
2. aube embed-boundary spike — re-pointing vendor/aube/.../lifecycle.rs at this engine via the embedder hook (the .fray/sandbox.md de-risk gate). Next PR.
3. The nub run runtime profile (the sibling profile of the umbrella), Linux recursive secret-read carve, full (deny default) macOS profile, Windows restricted-token write-jail, per-pattern glob→SBPL translation, setrlimit from the pid policy, the breakage audit against real native deps.

Engine-only; safe to land independently (nothing consumes it yet).

https://claude.ai/code/session_01YRvztkcr4fzfg9rD5edUwa

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
nub	Ready	Preview, Comment	Jun 23, 2026 10:56pm

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[pullfrog]

ℹ️ No critical issues — a few polish items inline. The engine is well-scoped, honestly phased, and the e2e tests prove real enforcement; nothing consumes it yet, so blast radius is contained.

Reviewed changes — the first cut of the nub-sandbox engine crate and its default-ON build-jail profile (engine only; not yet wired into the install lifecycle).

• New crates/nub-sandbox crate — unified SandboxPolicy { env, fs, net, pid } schema (policy.rs) driving both the build-jail and a future runtime profile.
• Build-jail preset (build_jail.rs) — env allowlist + secret-deny substrings/anchored-tokens, generous-read + secret-deny fs with tight allow-only write, tight egress allowlist, pid caps.
• Deny-set DATA — secrets.rs (ssh/aws/wallet/browser-profile read-deny, .env* glob, persistence write-deny) and net_defaults.rs (egress allowlist deliberately excluding the github.com apex / *.github.io).
• Per-OS backends — macOS Seatbelt/SBPL via sandbox-exec (fully implemented), Linux Landlock v2 + seccomp with capability-probe + graceful-degrade (linux.rs), Windows/other env-scrub-only stub that reports the gap (stub.rs), all under the fail-safe-with-Degradation contract (mod.rs).
• Engine entry (lib.rs) — apply_env_scrub spawn-boundary filter + apply_to_command (pre-creates write roots, applies the OS backend).
• e2e tests — macOS + Linux spawn real sandbox-exec/Landlock'd processes asserting a malicious-shaped script is contained while a legit native build still succeeds.

ℹ️ write_deny_relglobs() is defined but never enforced

secrets.rs exports a persistence-write deny-set (.bashrc, .github/workflows/**, .claude/**, .cursor/**, .git/config) but no backend consumes it. For the build-jail this is harmless — the write_allow set is tight enough that none of these sinks are writable anyway — but as shipped the function is unreferenced, and its doc comment reads as an active layer.

The honest scoping (it's for a future runtime profile whose writable roots overlap a project tree) is fine; the risk is that a future reader assumes the persistence sinks are already denied. A one-line tracking note or an issue link would prevent that.

Technical details

# `write_deny_relglobs()` is dead code as shipped

## Affected sites
- `crates/nub-sandbox/src/secrets.rs:88` — `pub fn write_deny_relglobs()` is exported but has no consumer in any backend (`macos.rs` / `linux.rs` / `stub.rs` never reference it).

## Required outcome
- Make it unambiguous that the persistence-write-deny is NOT yet enforced — either via a tracked follow-on note next to the function or by deferring the function until the runtime profile lands.

## Open questions for the human
- Is the runtime-profile consumer close enough that landing the data now is the right call, or should it land with its enforcement?

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

✅ No new issues found.

Reviewed changes — the single new commit since the prior pullfrog review (12b653c) is eda7a1e, a test-only hardening that closes four hollow-test gaps in nub-sandbox. No engine or executable-logic change.

• Degradation fail-safe unit tests (backend/mod.rs) — assert warning() is None under full enforcement and Some (naming every lost axis plus the reason) when degraded, and that a lost axis still warns even when reason is None. These are the negative control against a future regression that silently no-ops the reduced-mode banner.
• Stub honesty test (backend/stub.rs) — a #[cfg(not(any(linux, macos)))] test that the Windows/other-OS stub reports fs+net lost and never reads as is_full(), guarding the "reports the gap rather than claiming enforcement" contract on the Windows CI leg.
• Real socket() egress test on Linux (tests/e2e_linux.rs) — replaces the /dev/tcp shell trick (which passed even with seccomp removed, since dash/busybox lacks /dev/tcp) with a cc-compiled C client that genuinely issues socket(AF_INET), plus a live loopback listener as negative control; asserts SOCKET_EPERM specifically so a routing/ECONNREFUSED failure can't masquerade as a seccomp deny.
• Two-sided macOS env-leak + loopback negative control (tests/e2e_macos.rs) — the net test gains a baseline-must-CONNECT proof against a live loopback listener; the env-leak test now asserts both the deny half (seeded secrets and a real process-env secret absent) and the allow half (npm_config_registry present, PATH non-empty), catching an over-nuking scrub that would pass a deny-only assertion while silently breaking builds.

All referenced APIs match the crate surface, the negative controls make each previously-hollow assertion real, and the prior pullfrog feedback remains addressed. The unsafe set_var in the macOS env test is acknowledged with a SAFETY note and its blast radius is nil — the variable name is unique and read only by its own test.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}