feat: harden Windows partial-shell Plan A after sealed Plan B

[ken-jo]

Current status

PR #1657 merged as 476afcd0034ae665d0967c52cbc4877b3f949b32 and updates the current source pin to ASRT 0.0.66. It deliberately selects safe Plan B for requested Windows partial-sandbox canonical Bash/PowerShell: a host-sealed plain / kind=none execution plan, force-modal allow-once only, and a command/cwd/tool-use-bound one-shot permit. It makes no partial-isolation claim and issues no path ACL lease.

ASRT 0.0.66 still provides no handle-bound, no-follow, reparse-safe per-execution Windows filesystem grant. This issue therefore remains open only for a future Plan A replacement; PR #1657 does not close its ACL/reparse-hardening acceptance criteria.

Purpose

When a verified upstream safety primitive exists, replace the Plan B host-shell fallback with a Windows partial-shell execution boundary that is actually confined per invocation. This is not the win32 default-on task.

Owner

• Owner: @ken-jo
• Area: Sandbox / Security

Future Plan A scope

• Define a host-owned, versioned ExecutionSandboxPlan with requested sandbox state, effective mode, fallback reason, canonical cwd/read/write paths, deny floor, trusted shell, and timeout.
• Use a unique holder/lease per invocation only after the grant is handle-bound, no-follow, canonical-path checked, and safe against reparse/junction/TOCTOU replacement.
• Bind wrapper cwd and spawn cwd identity; never share a main PID or holder PID across concurrent invocations.
• Prove revoke/cleanup on exit, spawn failure, abort, timeout, shutdown, and startup crash recovery; a failed recovery must not publish partial/active capability.
• Report partial only when filesystem and network confinement are demonstrably applied to that exact shell process. Otherwise retain the sealed Plan B none plan and exact user gate.

Non-goals

• Do not reclassify a plain host spawn as partial isolation.
• Do not weaken or remove fix(sandbox): seal host shell fallback plans #1657's sealed Plan B / exact allow-once permit until Plan A meets every acceptance criterion.
• Do not enable Windows default-on (2B), close Harden Windows per-machine installer uninstall smoke and release gates #1627, or treat packaged/signed release evidence as completed.

Acceptance criteria

• A handle-bound/no-follow/reparse-safe per-execution grant primitive, or equivalently independently verified safety mechanism, is available and documented.
• 3-OS execution-plan/effective-mode truth table and fallback reason coverage are fixed by tests.
• Windows lifecycle tests cover holder/lease/wrapper/spawn/cleanup order, concurrency isolation, mismatch fail-closed behavior, abort/timeout/shutdown, and crash recovery.
• NTFS reparse point/junction swap and canonicalization/TOCTOU bypass attempts are blocked.
• Packaged Windows ASRT E2E and signed candidate replay remain separate release gates and are linked when they begin.

Related: #19, #1627, #1617, #1618, #1628, #1657

[ken-jo]

Implementation decision for the current follow-up PR:

ASRT 0.0.66 still rejects Windows per-execution filesystem.allowRead / allowWrite overrides and exposes path-based ACL grants tied to a long-lived host PID; it does not provide a handle-bound, no-follow, reparse-safe one-shot filesystem grant.

Accordingly, this PR selects the safe Plan B for the current 2A scope: canonical Bash/PowerShell calls receive a sealed host execution plan, and a requested Windows partial sandbox is represented honestly as plain / kind=none with a host-verified exact allow-once permit. It issues no ACL path grant and makes no partial-isolation claim. Full ASRT remains wrapped; unsupported future partial substrates fail closed.

This PR blocks but does not close #1653. The ACL/reparse-safe Plan A described by this issue remains open until its safety primitive and lifecycle evidence are available.