Proposal: Sandboy Windows backend for 007 gates and extension sidecars

[PhysShell]

Context

007 is moving toward gated agent execution: task contract, diff policy, gate steps, run records, judge/replay, and Sandboy-backed confinement.

Current Sandboy is a Linux MVP based on Landlock + seccomp. That is the right Linux design, but it does not help Windows-native gates such as:

MSBuild / dotnet / VS tooling
PowerShell gates
Roslyn analyzer test runs on Windows
FlaUI / UI automation
ClrMD / dump inspection
legacy .NET Framework checks

For these, running a Linux Sandboy inside WSL only confines Linux processes inside WSL. It does not confine Windows host processes spawned through pwsh.exe, MSBuild.exe, Visual Studio tooling, or UI automation. Locking the barn while the cow is in the office, basically.

Thesis

Sandboy should become a cross-platform process confinement facade with backend-specific enforcement and a shared policy/report contract.

sandboy-linux:
  Landlock + seccomp

sandboy-windows:
  Job Object
  Restricted Token
  Low Integrity / AppContainer-ish profile where feasible
  DACL-scoped worktree/temp directories
  environment allowlist
  timeout / process-tree kill
  best-effort or explicit network status

Do not try to port Landlock/seccomp to Windows. Keep the policy/report model stable and implement a Windows backend using Windows primitives.

Target use cases

1. 007 Windows gate steps

Example future gate manifest:

[[gate]]
name = "windows-roslyn-tests"
cmd = "pwsh -File ./build/test-roslyn.ps1"
env = "windows"
timeout_sec = 600
sandbox_policy = "windows-worktree-no-secrets"

Execution shape:

o7 gate runner
  -> sandboy run --policy <rendered-policy> --report gate/windows-roslyn-tests.sandbox.json -- pwsh -File ./build/test-roslyn.ps1

2. 007 extension sidecars

If 007 adopts a Koma-style sidecar extension protocol, Sandboy should be the process boundary:

o7 host
  reads extension manifest
  resolves grants
  resolves process policy
  launches extension through Sandboy backend
  records sandbox.json
  then accepts protocol handshake

Protocol grants define what an extension may ask 007 to do.
Sandboy defines what the extension process may do to the host.

These are separate layers and both matter.

Windows backend MVP

A practical MVP can start with process containment and hygiene before pretending to solve every Windows sandboxing problem.

Enforce in MVP

process tree killed on timeout / host close
restricted token, reduced privileges
clean environment with explicit allowlist
working directory confined by convention + DACL where feasible
stdout/stderr capture
machine-readable report

Best-effort / later

network block or restriction
full filesystem virtualization
AppContainer profile
per-process firewall/WFP integration
COM/UI automation constraints

Do not hide partial enforcement. Report it.

Required report contract

The Windows backend must emit an honest report.

Example:

{
  "schema": 1,
  "backend": "windows-job-restricted-token",
  "policy": "windows-worktree-no-secrets",
  "process_tree": "enforced",
  "timeout": "enforced",
  "environment": "enforced",
  "filesystem": "partial",
  "network": "not_enforced",
  "exit_code": 0,
  "duration_ms": 12345,
  "violations": [],
  "warnings": [
    "network policy not enforced by this backend"
  ]
}

Avoid a single secure: true boolean. That field is a bug wearing a badge.

Windows primitives to investigate

This issue is not an implementation commitment to any one mechanism yet, but likely building blocks are:

Job Objects:
  process tree lifetime
  kill-on-close
  CPU/memory/time limits where useful

Restricted Token:
  remove privileges
  reduce groups
  avoid ambient admin rights

Integrity Levels:
  Low integrity process where compatible

DACL-scoped temp/worktree:
  create a restricted user/token or scoped ACL so the child can write only intended dirs

Environment allowlist:
  clear inherited env by default
  pass only explicit variables

Handle inheritance hygiene:
  avoid leaking inherited file/socket handles into the child

Network:
  Phase 1 may report not_enforced
  later investigate Windows Firewall / WFP / AppContainer capabilities

Relationship to current Linux Sandboy

Current Linux Sandboy remains the model for policy/report discipline:

one command in
one process tree confined
one report out

The Windows backend should not weaken the Linux backend or overload Linux policy semantics. Instead:

policy authoring layer:
  common profile names and intent

backend renderer:
  produces linux policy or windows policy

runtime backend:
  enforces what that OS can actually enforce

report:
  says exactly what was enforced, partially enforced, or not enforced

Suggested phases

Phase W0: design note

Document sandboy-windows target shape:

backend name
policy fields
report schema
known non-goals
known partial guarantees

Phase W1: minimal runner

Implement:

sandboy-win run --policy <policy> --report <json> -- <cmd> <args...>

With:

clean env
timeout
process tree kill
stdout/stderr capture
restricted token if feasible
honest report

Phase W2: worktree/temp scoping

Add DACL-based scoping for:

worktree read/write
explicit temp dir
no inherited secrets by env
no inherited handles where possible

Phase W3: network story

Investigate and document one of:

not enforced, always reported
block all network for child token/profile
allowlist by profile
AppContainer/WFP-backed network policy

Phase W4: 007 integration

Wire into 007 gate steps:

GateStep.timeout_sec
GateStep.sandbox_policy
windows backend selection
run-record gate/<step>.sandbox.json

Acceptance criteria for first useful integration

A Windows gate step can run through Sandboy and produce a report that proves at least:

which backend ran
which command ran
which env vars were passed
whether timeout was enforced
whether process tree kill was enforced
whether filesystem/network were enforced, partial, or not enforced
exit code and duration

This is already useful even before perfect Windows sandboxing, because it replaces silent ambient execution with explicit evidence.

Non-goals

Do not promise VM-grade host escape resistance.
Do not claim parity with Linux Landlock/seccomp.
Do not mark partial network/filesystem control as secure.
Do not let 007 silently run a step bare when sandbox_policy is present but unsupported.
Do not depend on WSL for Windows-native gates.

Why this belongs in Own.NET

Own.NET / OwnAudit have Windows-native validation needs that sandboy-linux cannot cover. A Windows backend gives 007 a path to safely run real Windows gates while still preserving the same evidence-first model used by Linux gates.

This keeps the architecture honest:

Linux gates get Linux enforcement.
Windows gates get Windows enforcement.
Both produce comparable sandbox reports.
Unsupported guarantees are explicit, not quietly hand-waved.