Windows default tier: a Low-IL VMM escapee reaches every sibling sandbox's run dir, disks and workspace — record it, scope #276 honestly, name lockdown as the separation

[Lupus]

What

Record — in the security register, in #276's scope, and in the daemon's Windows posture reporting — that in the default Windows tier a Low-IL VMM escapee reaches every sibling sandbox's Low-labelled surfaces: the sibling VMM's own vsock.sock (→ CONNECT 1025/1026 = the sibling guest's control and stream ports: exec, cp in/out, port relays), its writable disks (rw.img, named volumes), its console.log, and its workspace share. State plainly that izba lockdown (per-sandbox izba-sb-<name> account, DACL-separated) is the mechanism that separates siblings, and that #276 closes only izbad's two listeners.

Why

Spike #248 proved Windows AF_UNIX connect() needs write access, so the inheritable Low label izba applies to every VMM write surface (VmSpec::confined_write_surfaces) admits any same-user Low-IL peer. #276 gates the two listeners izbad owns (vsock.sock_1027/1028). But the sibling VMM's vsock.sock is the VMM's listener, not izbad's — izbad cannot gate it, and a Low-IL peer that connects to it gets full control of the sibling guest, which is strictly more than "egress as some other sandbox". Mandatory integrity control knows levels, not identities, so no label choice fixes this; only a per-VMM principal (lockdown) does. Without this being written down, #276 landing will be read as "cross-sandbox on Windows is fixed" when it is not, and the default tier's real posture (one shared pool of sandbox surfaces at Low IL) stays undocumented. The primary boundary (guest → VMM) is unaffected; this is the containment of an escaped VMM.

In Scope

• A register entry (new finding or an F-06 addendum) enumerating the reachable sibling surfaces in the default tier, the guest-control consequence via vsock.sock, and lockdown as the separation mechanism, with a pointer to Determine whether Windows AF_UNIX connect() requires write access on the socket file (MIC no-write-up vs the run-dir Low label) #248's spike doc.
• A scope note on Windows: gate vsock.sock_1027/1028 to the sandbox's own VMM — the run-dir Low label (which connect() needs) admits every same-user Low-IL process #276 (issue body + its eventual register text) saying it covers izbad's listeners only.
• The daemon startup / izba status Windows posture line names the default tier's sibling exposure honestly (wording only — no new enforcement).
• Threat-model B3/B2 rows updated to match.

Out of Scope

• Any new enforcement: gating the VMM's vsock.sock, changing the label scheme, or making lockdown mandatory (each would be its own item).
• Windows: gate vsock.sock_1027/1028 to the sandbox's own VMM — the run-dir Low label (which connect() needs) admits every same-user Low-IL process #276's accept-time gate itself.
• Linux (SO_PEERCRED + 0700 run dir already separate).

Acceptance Criteria

• The register has an entry that lists, per sibling sandbox, the surfaces a Low-IL escapee can reach in the default Windows tier and what each grants (guest control via vsock.sock, disk/log writes, workspace writes).
• The entry names izba lockdown as the separation mechanism and links Determine whether Windows AF_UNIX connect() requires write access on the socket file (MIC no-write-up vs the run-dir Low label) #248's spike doc and Windows: gate vsock.sock_1027/1028 to the sandbox's own VMM — the run-dir Low label (which connect() needs) admits every same-user Low-IL process #276.
• Windows: gate vsock.sock_1027/1028 to the sandbox's own VMM — the run-dir Low label (which connect() needs) admits every same-user Low-IL process #276's body carries a scope note that it gates izbad's listeners only and does not cover the sibling VMM's vsock.sock.
• The Windows posture line reported by izbad/izba status mentions the default-tier sibling exposure and points at lockdown (text change with a test pinning the wording, like the existing posture-line tests).
• Threat-model rows B2/B3 reference the entry.

INVEST Notes

Independent — documentation + a posture-line wording change; needs nothing unmerged (#248's PR #277 only for the link, and it is already CLEAN).
Negotiable — new finding vs F-06 addendum, and the exact posture wording, are open.
Valuable — prevents #276 from being misread as sibling isolation, and gives the Windows default tier an accurate written posture.
Estimable — one register entry, one issue edit, one string + test, two threat-model rows.
Small — effort S.
Testable — the posture wording is pinned by a unit test; the docs criteria are checkable by reading.