DSH Windows 沙箱给工作区根目录打可继承的 Low 完整性标签，导致目录内构建的产物以低完整性运行、写不了工作区外的对象（造成多个人、多种工具的静默故障）

[1006er]

Summary (EN)

The Windows sandbox provisions the workspace root with an inheritable Low integrity label. Every file created or copied inside inherits it, and on Windows a process launched from an image labeled Low runs at Low integrity — so build outputs produced inside the workspace silently lose the ability to write Medium-integrity objects (paths outside the workspace, the user's own HKCU keys) even though the ACLs grant the user Full Control, because the mandatory-label check precedes the DACL. We hit several hard-to-diagnose failures this way: a service asserting on its startup self-check, RegOpenEx ACCESS_DENIED popups from a desktop tool, and processes that could not create their own log files (making failures invisible). It also fires when the user simply double-clicks an executable they built, i.e. the AI sandbox silently changes the runtime behavior of the product. Suggest not confining by labeling the workspace tree, and at minimum making it visible, documented and undoable.

环境

• Windows（NTFS 卷）；示例工作区记作 <workspace>（如 C:\work\repo），产物目录记作 <workspace>\out\bin
• 标签是持久化在文件系统上的，与当时的文件访问策略无关：策略设为“完全权限”时该标签依然存在

现象（均已复现）

1. 在工作区内构建的服务端程序 <app>.exe 启动自检时，往工作区之外的数据/资源目录（记作 D:\data\res）写一个探测文件 → Permission denied (errno 13) → assert 崩溃，服务无法启动。
2. 某桌面工具以 KEY_ALL_ACCESS 打开自己的设置键 HKCU\Software\<Vendor>\<Product> → RegOpenEx 返回 ACCESS_DENIED → 弹框。该键的 DACL 明确给了当前用户 FullControl（甚至还为受限令牌单独留了 ReadKey）。
3. 进程无法在自己的工作目录下创建日志目录/文件 → 服务“看起来起来了，但一条日志都没有”，故障全程不可见。
4. 以上在用户双击自己构建的 exe（完全不经过 agent）时同样发生 —— 也就是说这层沙箱状态改变了产品运行时行为。

根因（实测数据）

1. icacls <workspace> | findstr Mandatory → Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)（显式、可继承）。
2. 工作区内新建/拷贝的文件继承该标签（实测在工作区里新建的 exe：Low Mandatory Level:(I)(NW)）。
3. 从带 Low 标签的 exe 启动的进程，完整性级别就是 Low：
   • 用工作区里新建的 exe 启动 whoami /groups → Mandatory Label\Low Mandatory Level (S-1-16-4096)
   • 同一命令换成 C:\Windows\System32\cmd.exe（Medium 标签、同一父进程令牌）→ High Mandatory Level
4. 低完整性进程写 Medium 对象时，强制完整性标签检查先于 DACL：DACL 给了 FullControl 也照样被拒。实测从该进程执行 reg add HKCU\Software\<Vendor>\<Product> 失败；把产物目录 /setintegritylevel Medium 摘牌后同一命令立刻成功。
5. 摘牌后原有故障全部消失：启动自检通过、日志目录能创建、注册表可写。

为什么这反直觉、也和其他 agent 的做法不一致

• 其他 agent 工具通常只约束自己启动的进程（受限令牌 / job object / 容器），不会把持久化状态写到用户工作区的文件上。
• 这枚标签会：
  • 静默传播到用户自己构建的产物（可执行文件）；
  • 影响工作区之外的行为（用户自己的数据目录、HKCU 下用户自己的注册表键）；
  • 在不经 agent 的场景（双击 exe、打包、CI）继续生效；
  • 不给出任何提示、日志或文档，用户无从得知“我的产物从某天起以低完整性运行”；
  • 反复重新打上 —— 用户手工摘牌后，下次会话又会回来。
• 后果是排错成本极高：报错信息全部指向“目录权限坏了 / 注册表坏了 / 该软件没装好 / 外放版把代码编掉了”，全都不是真因。已经有多人在同一工作区作业后遇到这类问题。

建议

1. 不要用“给工作区根打可继承标签”来实现写入授权。改为只约束 agent 自己拉起的进程（受限令牌 / 低完整性令牌），或把需要受限的工作限制在专用目录（如 <workspace>\.dsh\），不要污染整棵工作区。
2. 如果这一步必需：
   • (a) 别让它继承到用户产物（至少排除 *.exe 与构建输出目录）；
   • (b) 打标签时给出可见提示；
   • (c) 提供受支持的查询/清除入口（如 dsh sandbox labels list|clear），而不是让用户去啃 icacls；
   • (d) 文档写明后果 —— “低完整性进程即使 DACL 给了 FullControl，也写不了非低完整性对象，包括 HKCU 下用户自己的键”。
3. 重新配置工作区时，若用户已手工清除标签，请至少提示“即将重新应用”。
4. 若设计上确实需要这一步，请在沙箱初始化时检测并警告：“本工作区/产物目录已带 Low 标签，目录内构建的 exe 将以低完整性运行”，并附一键恢复指引。

临时规避（供其他人参考）

# 自查：看到 Low Mandatory Level:(OI)(CI) 就是被打牌了
icacls "<任意目录>" | findstr Mandatory

# 只给“跑 exe 的产物目录”摘牌（推荐，影响面最小）
icacls "<workspace>\out\bin" /setintegritylevel Medium /T /C /Q

# 或给整个工作区摘牌（副作用：沙箱自己的受限进程会写不进工作区，谨慎）
icacls "<workspace>" /setintegritylevel Medium

（注意：沙箱下次配置该工作区时会重新打上。）

最小复现（可选，供维护者验证）

# 1) 确认工作区根带了可继承的 Low 标签
icacls "<workspace>" | findstr Mandatory

# 2) 在工作区内新建一个 exe，确认它继承了 Low 标签
$dst = "<workspace>\out\bin\ilprobe.exe"
[System.IO.File]::WriteAllBytes($dst, [System.IO.File]::ReadAllBytes("$env:WINDIR\System32\cmd.exe"))
icacls $dst | findstr Mandatory          # 期望：Low Mandatory Level:(I)(NW)

# 3) 从该 exe 启动进程，看它自己的完整性级别
& $dst /c whoami /groups | findstr "Mandatory Label"   # 期望：Low Mandatory Level (S-1-16-4096)

# 4) 对照：Medium 标签的 exe，同一父进程令牌
& "$env:WINDIR\System32\cmd.exe" /c whoami /groups | findstr "Mandatory Label"   # 期望：High

# 5) 低完整性进程写一个 Medium 的注册表键（DACL 允许、标签不允许）
& $dst /c "reg add HKCU\Software\<Vendor>\<Product> /v Probe /t REG_SZ /d x /f"  # 期望：被拒