Windows sandbox: per-workspace capability SIDs may not isolate workspaces due to Everyone restricting SID

Note: This is based on code analysis of the Windows sandbox implementation, not empirical testing. The behavior described below may be incorrect if there are runtime mechanisms not visible in the source.

Summary

The Windows sandbox uses per-workspace capability SIDs (cap.rs, workspace_by_cwd) intended to isolate concurrent workspace sessions from each other's writes. However, the restricted token also includes the world SID (Everyone, S-1-1-0) as a restricting SID, and writable paths receive Everyone ACEs to satisfy the WRITE_RESTRICTED check.

If this analysis is correct, any sandbox session — regardless of which workspace capability SID it carries — can write to any workspace directory that has an Everyone ACE, because the WRITE_RESTRICTED kernel check passes via the world SID.

Expected behavior

Session A (with workspace A's capability SID) should not be able to write to workspace B's directory, even if both sessions run concurrently.

Possible behavior (based on code reading)

Session A can write to workspace B because the Everyone ACE on B satisfies the WRITE_RESTRICTED check through the world SID restricting SID, bypassing the per-workspace capability SID isolation.

Suggested fix

Replace the world SID (Everyone) restricting SID with the sandbox user's own SID. The sandbox user already has explicit allow ACEs on writable paths (set by the elevated setup helper), so those ACEs would satisfy both the normal DACL check and the WRITE_RESTRICTED check. Per-workspace capability SIDs would then provide real isolation — only the session whose token includes workspace A's capability SID could write to workspace A.

This also tightens the general write restriction: with the world SID, any object with an Everyone ACE (common on shared directories) is writable during the session. With the sandbox user's SID, only objects with explicit sandbox user ACEs are writable.