[BUG] Workspace-write provisioning leaves a persistent Low integrity label on the workspace root — executables built in the workspace run at Low IL and fail all writes outside the sandbox

[corlane]

Summary

When the Windows ACL sandbox provisions a workspace (workspace-write mode), it applies three standing entries to the workspace root: the workspace capability-SID grant, an Everyone delete-deny, and a Mandatory Label\Low Mandatory Level with (OI)(CI) propagation. The Low integrity label inherits down the entire tree — including into bin\ build output and onto the built .exe itself.

Windows sets a process's integrity level from the mandatory label on its image file. So any executable built inside a DSH workspace and launched outside the sandbox (double-click, Visual Studio F5, dotnet run) starts at Low integrity, and Mandatory Integrity Control then denies every write to normal Medium-IL locations — %TEMP%, %LOCALAPPDATA%, anywhere. The failure looks like random UnauthorizedAccessExceptions in an unrelated app and is extremely hard to trace back to the harness.

Environment

• Windows 10/11 desktop (user is a member of BUILTIN\Administrators, standard filtered token)
• @deepseek-ai/dsh-sandbox-windows-acl 0.2.0-rc.2 (via npx)
• Affected project: .NET 10 WPF app (net10.0-windows), built with Visual Studio 2022 inside the DSH workspace

Symptoms

• System.UnauthorizedAccessException: Access to the path 'C:\Users\<user>\AppData\Local\Temp\WPF\<random>.rzf' is denied. — thrown during WPF measure, right after window.Show()
• Same exception writing the app's own settings file under %LOCALAPPDATA%\<app>\ (.tmp write + move)
• All write attempts fail, regardless of target folder
• Running the app from an elevated (High-IL) context works; deleting bin/obj and rebuilding does not help (the fresh exe re-inherits the label)
• Side effect: deletes inside the workspace root are also blocked by the inherited Everyone:(CI)(DENY)(S,DC)

Evidence

Workspace root (icacls, entries explicit, not inherited):

C:\...\myapp\myapp
    Everyone:(CI)(DENY)(S,DC)
    S-1-4-415224645-56445664:(OI)(CI)(W,D,DC)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(F)
    DESKTOP-070C76I\<user>:(I)(OI)(CI)(F)
    Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

The parent folder (one level up, outside the workspace) is clean — the trio was applied to the workspace root itself. The S-1-4-… SID matches the deterministic workspaceWriteSid, tying it to this workspace path.

Inherited all the way onto the built image:

C:\...\bin\Debug\net10.0-windows\myapp.exe
    S-1-4-415224645-56445664:(I)(W,D,DC)
    ...
    Mandatory Label\Low Mandatory Level:(I)(NW)

The diagnose-windows-sandbox-acl skill run on the failing path returned verdict NOT_THIS_CLASS / nextAction=stop (the Temp\WPF chain is clean — correctly, since the problem is the process IL, not the target ACL). The module README itself notes the diagnostic deliberately preserves integrity labels and cannot fix Low-labeled executables affecting programs launched outside DSH — which is exactly this failure class, and there is no supported user-facing reclaim path for the workspace label (manual icacls removal of the capability ACE also fails with ERROR_NONE_MAPPED unless the *SID form is used).

How it happened here

An agent session was modifying files in the workspace; the harness provisioned the root on its first workspace-write command. The session was interrupted mid-stream (context full). The entries are standing by design (cached, never revoked), so they persisted — and the app, rebuilt many times since, kept inheriting the Low label.

Reproduction

1. Open any folder as a DSH workspace on Windows; run any tool command that writes into it (workspace-write).
2. icacls <workspace-root> → observe explicit Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) + capability grant + Everyone delete-deny.
3. Build any .NET (or native) app inside that workspace with VS or dotnet build.
4. Run the produced exe outside the sandbox → process runs at Low IL; writes to %TEMP%/%LOCALAPPDATA% fail with UnauthorizedAccessException.

Workaround used

Clean copy of the project to a non-workspace folder (copy creates fresh files with clean inheritance; rename would keep the label). Additionally hardened with a post-build event so the guard survives future provisioning:

icacls "$(TargetPath)" /setintegritylevel Level=Medium

Suggested mitigations

1. Detect and warn: at provisioning (or in the diagnostic), scan the workspace for PE images carrying the inherited Low label and surface a warning — the README already acknowledges this hazard, but the user has no way to discover it.
2. Supported reclaim: provide a first-class "unprovision workspace" command that removes the label/ACEs (the docs say manual cleanup can't reclaim them, but no reclaim path is exposed).
3. Reduce blast radius: consider not labeling the workspace root itself Low (e.g., label only the specific directories tools write to, or exclude build-output subtrees), so executables never inherit it.

[PerryLink]

结论先说：机制你描述得准确，而且我一字不差地核到了 README 与源码。但它的定性是「有意设计」，不是「未处理的缺陷」 —— 这个区别决定它会被当 bug 修还是当功能做。同时，「没有 reclaim 路径」这一半是真缺口，值得单列。

1. 一次 SetNamedSecurityInfoW 写三样：确认

packages/sandbox/sandbox-windows-acl/src/acl.ts:405-412 的那次 merge 同时落 deny + allow + label；Low 标签在 :180-181：

addMandatoryAce(..., SUB_CONTAINERS_AND_OBJECTS_INHERIT, SYSTEM_MANDATORY_LABEL_NO_WRITE_UP, lowLabelSidPtr)

常量对得上你 icacls 里看到的东西：win32-abi.ts:87 = 0x3 (OI|CI)、:55 = 1 (NW)、:61 = 66 (S-1-16-4096)、:22 = 0x40 (FILE_DELETE_CHILD)、:89 = 0x2 (CI)、:38 = 1 (Everyone)。

⇒ 你贴的 Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) 与 Everyone:(CI)(DENY)(S,DC) 完全吻合。

2. ⚠️ 但「常驻」是写在 README 里的设计

packages/sandbox/sandbox-windows-acl/README.md：

• :128 → 「workspace ACEs, denies, and labels stand by design（the reuse cache, never revoked）」＋「manual icacls cleanup cannot revoke them (ERROR_NONE_MAPPED, 1332)」
• :129 → 「A standing Low label outlives DSH… The label is the price of the write boundary: without it the confined child cannot write at all, and revoking it per session would re-propagate the whole tree on every provision」
• :12 / :66 / :98 → standing 与"一次调用写三件事"的说明
• :175 → 「Diagnosis preserves integrity labels — it cannot fix Low-labeled executables affecting programs launched outside DSH.」（你引的这句逐字命中）
• :204 → 清理命令的处置状态是 undecided

而且更硬的一条：src/grant.ts:106 把 standing 与 revocable 分流，:116-124 的 dispose 只撤 revocablePaths —— 连模块自己都不撤 standing。

⇒ 所以这不是"忘了回收"。按"未处理的缺陷"提，会被 README :128/:129 直接挡回；按"有意设计，但缺少一条出口"提，才站得住。

3. ⭐ 真缺口：今天没有官方 reclaim 路径

这一点你可以放心主张，我核了导出面：

• packages/sandbox/sandbox-windows-acl/src/index.ts:58-61 的公开面只有 AclWriteGrant / assertTempRootOutsideWorkspace / tempWriteSid / workspaceWriteSid / ACL_DIAGNOSIS_SKILL / registerAclDiagnosisSkill
• 而 acl.ts:431-448 的 revokeWrite（它有能力清标签，无其它授权时会返回 { kind: 'clear' }，见 :443）没有从包入口导出

⇒ 能清标签的代码存在，只是没有对外通道。 建议把诉求写成："既然 revokeWrite 已具备清标签能力，请提供一条官方入口（CLI 子命令或 skill 参数），而不是让用户去手工 icacls" —— 这比"请让标签可以被撤销"具体得多，而且维护者一看就知道要做多少。

4. 诊断技能的"NOT_THIS_CLASS / stop"是预期行为，不是它失灵

assets/diagnose-windows-sandbox-acl/scripts/diagnose-windows-sandbox-acl.ps1：

• :191 → SetNamedSecurityInfoW(path, 1, 4u|…) —— 4 是 DACL，从不含 0x10（LABEL）
• :559 → 只观测 LOW_LABEL
• :609-610 → NOT_THIS_CLASS 的 reason
• :770 → nextAction = stop

⇒ 它的定位就是 README :175 那句：诊断保留完整性标签。所以你跑出 NOT_THIS_CLASS/stop 是它按设计工作，不是它坏了 —— 别把这条当成第二个 bug。

5. 一处需要收窄

你说「工作区根内的删除也被拦」。这与 README :123-124 冲突：

The user's ordinary deletes keep working because the workspace DACL grants them DELETE directly.

被拦的是以 FullControl / GENERIC_ALL 打开子目录（0x40 FILE_DELETE_CHILD ∈ FILE_ALL_ACCESS），以及依赖父目录 FILE_DELETE_CHILD 授权的删除路径。建议核对一下你那条证据是不是属于后者 —— 如果是"普通删除也失败"，那就是另一个（更严重的）问题，值得单独开一条；如果属于后者，就该改写成长路径下的删除失败。

6. 两条会影响你后续动作的提醒

• ACE 与完整性标签是两件事。 icacls /setintegritylevel Medium 只改标签、不清能力 ACE；反过来清 ACE 也不动标签。所以清理要分两步看。
• 清理后会复发：acl.ts:386-395 只有在精确的 ACE / deny / label 三者不齐时才跳过 SetNamedSecurityInfoW；你手工清掉标签后，下次 workspace-write 会再贴一遍。幂等检查帮不上你 —— 这也是"为什么要官方入口"的最好论据（官方入口至少能做成"记住用户的选择"）。

7. 版本：未过期，也未修

沙箱后端在 dsh-v0.2.0-rc.2 与 origin/master（= dsh-v0.2.1-alpha.2）之间逐字节相同：

git diff --stat dsh-v0.2.0-rc.2 origin/master -- \
  packages/sandbox/sandbox-windows-acl/src packages/sandbox/sandbox-local/src \
  packages/sandbox/sandbox/src packages/shell/pwsh-sandbox/src packages/shell/bash-sandbox/src
→ 空

⇒ 所以上述每一条都同时适用于你装的版本和最新线，不存在"升级就好了"。