sandbox(windows): dedicated-account + WFP backend for agent-sandbox

[colinhacks]

Windows agent-sandbox needs three things the AppContainer backend cannot express: a generous-read base, a deny carved inside a granted directory, and per-host egress. This spike adds a second Windows path that expresses all three — a dedicated local account fenced by Windows Filtering Platform filters keyed on that account's SID.

The existing per-run AppContainer path is untouched. It is build-jail's mechanism and stays administrator-free end to end.

Why a second backend

The AppContainer path is a pure allowlist: reachable only where an object's ACL names the per-run AppContainer SID. Two things defeat agent-sandbox there.

• Generous-read-minus-secrets is inexpressible. An allowlist cannot say "read everything except these", so the policy degrades to the explicit allow-set.
• Deny-inside-allow does not hold. A secret under a directory carrying an inherited ALL APPLICATION PACKAGES grant is readable regardless of the allow-set — that grant satisfies the LowBox check before default-deny is reached.

Both dissolve when the child runs as a separate local principal. The invoking user's own profile is denied by default with no ACE authored at all, no ALL APPLICATION PACKAGES grant ever covers a user SID, and an explicit deny ACE on a secret inside a granted tree wins on canonical DACL order.

Per-host egress was never administrator-free on Windows regardless — there is no unprivileged per-host mechanism, so the full grammar always implied WFP, which always implied elevation. Given elevation is required anyway, the dedicated account buys the whole grammar rather than a subset. That is what collapsed the deny-strip's reason to exist, and it is dropped rather than finished: no SE_DACL_PROTECTED, no DACL journal, no copy-on-deny.

The privilege split

This is the product decision the design turns on. Every WFP write requires administrator, so a filter carrying the run's ephemeral proxy port would mean a UAC prompt on every run. Instead the one-time elevated setup pre-authorizes a narrow loopback port window, and the egress proxy binds into that window at launch.

nub run --sandbox-admin setup      # elevated, once per machine
nub run --sandbox <policy> <cmd>   # unelevated, every time after

The per-run launch uses CreateProcessWithLogonW, which hands the credential to the Secondary Logon service and therefore needs no privilege in the caller — the unelevated broker never holds a foreign primary token. SRT and Codex converged on the same shape independently.

The honest cost is that the permit covers a ten-port loopback window rather than one exact port, and it is not user-scoped.

What routes where

Policy shape	Backend	Privilege
Default-deny allowlist, coarse or absent net (build-jail)	per-run AppContainer	none
Generous read, deny inside a grant, or per-host egress (agent-sandbox)	dedicated account + WFP	one-time elevated setup

Selection is needs_account_backend(). Unit tests pin build-jail's shape to the AppContainer path specifically, because a regression there would make nub install demand elevation.

Mechanism

Egress — four persistent filters in one nub-owned sublayer. A BLOCK on ALE_AUTH_CONNECT_V4/V6 conditioned on FWPM_CONDITION_ALE_USER_ID, and a higher-weight PERMIT for loopback inside the port window. Keying on the token's user is what defeats surrogate-spawn: a process-keyed filter loses the moment the child launches a helper.

Filesystem — inheritable ALLOW aces for the account on granted subtrees, explicit DENY aces on secrets inside them. The grant masks deliberately exclude FILE_DELETE_CHILD, WRITE_DAC and WRITE_OWNER; each exclusion is a compile-time assertion naming the bypass it prevents. Removal hand-builds the ACL rather than calling SetEntriesInAclW(REVOKE_ACCESS), which does not remove explicit deny aces on Windows 11 25H2.

State — a versioned marker records the account SID and port window so an unelevated run can read what it may not enumerate (WFP gates even reading on administrator). An append-only ledger records every ACL'd path, written before the ace is applied, so crash residue can be swept.

Spike bounds

Carried deliberately and documented in LIMITATIONS.md rather than hidden:

• Single-hop launch. SRT and Codex add a second hop through a runner holding a restricted token; confinement here comes from the account's ACL reach plus SID-keyed WFP, neither of which needs that token.
• The child shares the caller's window station and desktop rather than getting a private one. It is granted access to both, which on an interactive WinSta0 gives the sandbox account input injection, keystroke and screen capture, and clipboard read against the user's own session for the run's duration. lpDesktop stays NULL, since setting it was verified not to help. The masks are the ones the VM diagnosis confirmed working; narrowing them needs a bisect on a real box, because that surface fails by hanging in loader init rather than erroring.
• Job-Object whole-tree kill is best-effort — seclogon's own job refuses cross-session nesting.
• Concurrent runs share one account, so one run's teardown can revoke a grant another still needs.
• Child-created files are owned by the sandbox account. Access is preserved; ownership changes.
• Egress coverage is ALE_AUTH_CONNECT only — inbound and bind are unfiltered. DNS still resolves through the Dnscache service under a different token.

Verification

Driven end to end on a real Windows Server 2022 box, from an unelevated session
(IsInRole(Administrator) = False, Medium integrity), against a machine provisioned once by an
elevated setup:

  CHILD USERNAME=nub-sandbox USERPROFILE=C:\Users\nub-sandbox
PASS the child runs AS the dedicated sandbox account, not the invoking user (exit 0)
PASS KEY: the denied secret inside the granted tree is UNREADABLE (exit 5)
PASS NC same run, same tree: the granted file still reads (the deny is surgical) (exit 0)
PASS NC unconfined: the secret is readable absent the sandbox (exit 0)
PASS write inside the granted tree succeeds (exit 0)
PASS write to the UNGRANTED sibling dir is denied (exit 5)
PASS NC unconfined: the sibling dir is writable absent the sandbox (exit 0)
PASS egress to a loopback endpoint OUTSIDE the permitted window is blocked (WSAEACCES) (exit 5)
PASS NC unconfined: the same endpoint is reachable (exit 0)
PASS a GRANDCHILD the sandboxed child spawns is fenced too (the filter keys on the SID) (exit 5)
PASS NC unconfined: the same grandchild reaches the endpoint (exit 0)
PASS a listener INSIDE the permitted window IS reachable from the sandboxed child (exit 0)
ALL WINDOWS ACCOUNT ENFORCEMENT PROBES PASSED

Every block is paired with a negative control that passed in the same run, and the identity
guard passed — so "no breakout" is not vacuous. Egress cases assert raw WSAEACCES (10013)
specifically; a plain ERROR_ACCESS_DENIED is a distinct exit code and fails the assertion, so
the WFP fence is confirmed as the mechanism rather than inferred. On an un-provisioned machine
the probe refuses and exits non-zero rather than passing hollow.

The probe is opt-in (--features windows-sandbox-probe) because it provisions a machine; bare
cargo test on a windows-latest runner will not build or run it.

scripts/rust-build.sh test -p nub-sandbox --no-run --profile fast \
  --target x86_64-pc-windows-gnu --features windows-sandbox-probe

Gates: host and x86_64-pc-windows-gnu clippy --all-targets --all-features -D warnings
clean, 113 lib tests plus every suite green, fmt clean.

Review

Two fresh-context reviews (correctness/security, impact-analysis) and two VM runs. Everything
they confirmed is fixed here, including three that changed the security outcome: the marker's
account name was trusted as the logon identity while only the hardcoded account's SID was
validated; the credential store's lock was additive, so ProgramData's inherited read survived,
and without an owner reset a pre-creating user could undo it; and add_ace would replace a
NULL DACL — which Windows reads as unrestricted — with one containing only its own ace,
locking out the object's owner.

Incidental fixes

Two pre-existing breaks are fixed here because the crate's lib unit tests and the Windows enforcement suite could not compile for the Windows target without them: a NetPolicy literal that never grew the MITM tier's fields, and an expect_err requiring a Debug bound Prepared does not have. CI builds only three named integration targets on windows-latest, which is why neither surfaced.

LIMITATIONS.md still carries a stale claim in its untrusted-tier section (an omitted axis is described as relaxed; it floors). That belongs to the config-grammar effort and is left alone here to avoid conflicting with the in-flight branch.

Verification

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
nub	Ready	Preview, Comment	Jul 25, 2026 8:20am

[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 — two user-facing error strings lost their line-continuation. Everything else is a deliberate, documented spike bound.

Reviewed changes — the new Windows dedicated-account + WFP backend for the agent-sandbox policy grammar, added alongside (not replacing) the existing per-run AppContainer backend.

• Second Windows backend under windows_account/ — runs the child as a dedicated nub-sandbox local account fenced by SID-keyed WFP egress filters and DACL grant/deny ACEs, expressing generous-read-minus-secrets, deny-inside-a-grant, and per-host egress — the three shapes the AppContainer allowlist cannot.
• Privilege split — one elevated nub run --sandbox-admin setup per machine (account + 4 persistent WFP filters over a loopback port window + %PROGRAMDATA%\nub\sandbox lock); every run after is unelevated via CreateProcessWithLogonW through seclogon.
• DACL surgery in acl.rs — canonical ACE ordering (explicit-deny before inherited-allow) is the whole fs mechanism; grant masks compile-assert the exclusion of FILE_DELETE_CHILD/WRITE_DAC/WRITE_OWNER; strip hand-rebuilds the DACL because SetEntriesInAclW(REVOKE_ACCESS) fails to remove deny ACEs on Win11 25H2; NULL-DACL writes fail closed.
• Credential + state — DPAPI machine-scope credential gated solely by a PROTECTED DACL + owner reset on the state dir; v2 marker drops the account-name field (v1 name-trust was a fixed vuln) and carries only the SID + port window, re-validated against the live account on every launch and sweep.
• WFP fence in wfp.rs — 4 transactional persistent filters keyed on ALE_USER_ID (defeats surrogate-spawn), loopback permit out-weighs the account block (const-asserted).
• Backend selection — needs_account_backend && is_provisioned gates the new route in apply; build-jail's shape is unit-tested to stay on the admin-free AppContainer path, and an un-provisioned machine falls through, so nub install never demands elevation.
• Enforcement probe — opt-in --features windows-sandbox-probe real-box test with a negative control paired to every confinement assertion; plus incidental fixes to two pre-existing Windows-target compile breaks.

This is a spike to the sandbox-win-net-parity feature branch, not main, and it is exceptionally documented and self-reviewed (two fresh-context reviews plus VM runs already applied, with three security-outcome fixes called out in the body). The security-critical invariants I checked — canonical DACL order, mask exclusions, NULL-DACL handling, credential lockdown, marker identity, SID-keyed WFP, and build-jail routing — are all backed in-code by compile-time assertions, unit tests, and the enforcement probe. The spike bounds (single-hop launch, shared account, broad window-station grant on an interactive session, DNS still resolving, inbound unfiltered, best-effort job reap) are deliberate and enumerated in LIMITATIONS.md; none is a defect to fix here.

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