[Windows] workspace-write 会把工作区打成常驻 Low 完整性标签，用户自己启动的程序被降级、写不进 %TEMP% / %LOCALAPPDATA%

[addqi]

环境

• DSH 桌面版 0.2.0-rc.2（nightly 通道），Windows 10 22H2（10.0.19045.6456，x64）
• 沙箱后端：@deepseek-ai/dsh-sandbox-windows-acl（windows-acl 档）

摘要

自 d5ad3baeb5（"fix(sandbox): confine Windows deletes with a Low integrity label"，2026-09-19，首个发布版本 dsh-v0.1.7-alpha.1）起，Windows ACL 后端会给每一个被授权的工作区根目录写入可继承的 Low 强制完整性标签，同时把受限子进程的令牌降级为 Low。

由于 Windows 是按映像文件自身的强制完整性标签来决定新进程的完整性级别，工作区里所有可执行文件都会被降级为 Low —— 这不仅仅是 DSH 自己拉起的受限子进程，还包括用户自己启动的程序（在资源管理器里双击、自己的构建脚本、编辑器的工具链、游戏客户端）。这些程序随后写不进任何非 Low 的对象，其中就包括 %TEMP% 和 %LOCALAPPDATA%。

该标签是作为常驻（standing）工作区授权写入的，永远不会被撤销，因此这个影响会跨会话、跨 DSH 重启、跨开机持续存在。

改动前后对比（上游证据）

$ git grep -i -E 'low|integrity|S-1-16' d5ad3baeb5~1 -- packages/sandbox/sandbox-windows-acl/src
# 只有误命中（"lowercased"、参数名 "bytesLow"）
# -> 该提交之前完全没有强制完整性标签的逻辑

$ git log -S 'buildLowLabelAcl' --format='%ad %h %s' --date=short -- packages/sandbox/sandbox-windows-acl
2026-09-19 d5ad3baeb5 fix(sandbox): confine Windows deletes with a Low integrity label

$ git log -S 'restrictTokenIntegrity' --format='%ad %h %s' --date=short -- packages/sandbox/sandbox-windows-acl
2026-09-19 d5ad3baeb5 fix(sandbox): confine Windows deletes with a Low integrity label

$ git tag --contains d5ad3baeb5 | head -3
dsh-v0.1.7-alpha.1

也就是说：Windows 沙箱本身早在 f64ba40f43（2026-08-08）就已存在，按工作区常驻授权的机制早在 5fea4b7c4b（2026-08-09）就已存在 —— 但这两次都没有降级用户进程。只有 d5ad3baeb5 引入了这个行为。

复现

1. 在 DSH 中，对工作区 W 用一个 workspace-write 会话执行任意一条命令（授权在此物化）。
2. icacls W 输出：
   Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
3. 把任意可执行文件复制进 W（我用的是 timeout.exe），然后从普通的、非 DSH 的命令行启动它。用 GetTokenInformation(TokenIntegrityLevel) 读取子进程令牌：

启动的二进制	进程完整性级别
W\_probe.exe（位于被打标签的目录树内）	Low —— S-1-16-4096
C:\Windows\System32\timeout.exe	Medium —— S-1-16-8192

同一份字节、同一个父进程 shell，唯一的差别是文件上的强制完整性标签。

4. 在一个真实项目上的后果（一个用于本地开发的游戏客户端/服务端仓库，所有工具链都存放在工作区内）：

   • client/tool/.../luajit-win32.exe 位于工作区内。构建过程会用它在 %TEMP% 目录里编译产物：

     RuntimeError: LuaJIT 编译失败：...\client\src\game\csv\talk.lua
     luajit: C:\Users\<user>\AppData\Local\Temp\talk_luajit_y276v1cs\talk.luac: Permission denied
     

     %TEMP% 没有标签（Medium），因此 Low 的 luajit 无法写入。

   • client/runtime_copy/win64/client.exe 位于工作区内。它把本地用户数据持久化到 %LOCALAPPDATA%\client\snail.dat，SQLite 写入失败，程序报保存错误。

   把同一棵目录树复制到被打标签的工作区之外，两者都正常。

为什么现在无法修复

• 随包发布的诊断技能在设计上就做不到。 SetDacl() 只传 DACL_SECURITY_INFORMATION，sacl 恒为 IntPtr.Zero：

  // Only the DACL and its inheritance protection are written: never owner, group or SACL.
  SetNamedSecurityInfoW(path, 1, 4u | (isProtected ? 0x80000000u : 0x20000000u),
      IntPtr.Zero, IntPtr.Zero, dacl, IntPtr.Zero);

  README 对此有明确说明："诊断保留完整性标签——它无法修复 Low 标签的可执行文件影响用户在 DSH 外启动程序的问题。"

• 常驻工作区授权没有任何受支持的撤销路径。 README 说明这些常驻改动在设计上永不撤销，手工 icacls 清理无法回收（ERROR_NONE_MAPPED 1332），并提示"请通过本模块回收" —— 但这个入口并不存在；开发备注里仍把清理命令列为"尚未决定"。

• 目前找到的唯一绕法是 icacls W /setintegritylevel (OI)(CI)M /T，但它只能撑到下一次 workspace-write 供给重新物化授权为止（标签一旦不同，"精确标签跳过"就不再命中）。

诉求

d5ad3baeb5 的安全动机是清楚的，我并不是要求重新打开 FILE_DELETE_CHILD 那个洞。希望贵方能提供以下之一：

1. 一个受支持的、可以解除常驻工作区改动的方式（Low 标签 + world 删除拒绝 + 能力 SID 允许 ACE），用于用户不再希望被限制的目录 —— 例如基于 AclWriteGrant 的撤销接口或一个命令行工具，让一个项目目录能恢复成正常状态；
2. 约束标签的作用范围，使其不影响用户在 DSH 之外启动的程序（例如不要在工作区根目录上使用可继承标签；或者让诊断技能能够上报该问题，并在用户明确同意后修复）；
3. 至少把用户可见的后果写进已知限制：从被授权工作区启动的任何程序 —— 任何人启动的，包括用户自己 —— 都会以 Low 完整性级别运行，并且失去对 %TEMP%、%LOCALAPPDATA% 等 Medium 位置的访问。

[argszero]

Your reproduction and the source agree on every point, and the last of your three asks is the one that can be satisfied today — so this reply is mostly about making the consequence visible where it happens, plus two corrections in your favour.

What the source adds to your account. The three entries are standing by design and nothing revokes them: the backend's own dispose path is documented to revoke only the revocable (temp) grants and to leave "the standing workspace edits in place", and the fail-closed cleanup says it more plainly — those ACEs "are NOT revoked — they are the intended end state (the reuse cache), not an error artifact" (sandbox-windows-acl/src/grant.ts, src/index.ts). The label is (OI|CI)-inheritable and lives in the SACL, which is why icacls /reset does not take it off (that rebuilds the DACL), and removing an integrity label needs WRITE_OWNER — the same right the provisioning failure is about. The hard-link reach you did not need to mention and which is worth knowing anyway: an NTFS hard link is a second name for one file object, so both names share one security descriptor, and a pnpm workspace is largely hard links into a content-addressed store — an inheritable label written inside the tree can therefore land on the store's objects and stay there, after which every project building from that store gets Low-integrity executables and failures that name the build tool rather than DSH.

Your %TEMP% / %LOCALAPPDATA% case is the discriminator, and it is the one a reader will underestimate. Windows starts a process at the minimum of the user's and the image's integrity, so "an executable that happens to live in the workspace" is enough — nothing has to be launched by DSH, and nothing in the refusing process's output names DSH. That is precisely the shape your ask (3) is about.

A stopgap ships for it. @argszero/cordis-plugin-sandbox-grant-advisor — https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor — attaches a durable user-role advisory through additionalContexts in the step where the failure surfaces, and its first family's advisory states what the grant leaves behind before handing over the command that applies it: the three standing entries, the label living in the SACL, the process-integrity rule above, and the out-of-tree reach through hard links. It ships no removal command, deliberately and for the reason your own report gives: the maintainers' diagnosis skill reports the label and does not remove it, removing one needs WRITE_OWNER, and this project has no Windows host to verify a line on. Mount it with:

- insert:
    - id: sandbox-grant-advisor
      name: '@argszero/cordis-plugin-sandbox-grant-advisor'

Two corrections, both of them narrowing your report rather than widening it.

• diagnose-windows-sandbox-acl is not part of the line you are running. It is new in 0.2.0: measured on the published tarballs, 0.1.7-rc.2 names the skill zero times in either README, ships no assets/ directory and carries no registration symbol anywhere in its tree, while 0.2.0-rc.2 ships assets/diagnose-windows-sandbox-acl/{SKILL.md,scripts/…}. So the README sentence you quoted is a 0.2.0-era document, and a reader who goes looking for it on 0.1.7-* is looking for something that release never had.
• The label does not make a workspace "unwritable"; it makes it writable only for Low-integrity children, which is the point of the design. The confined child's token is lowered to Low too, so the directory's Low label is what lets that child write there at all under no-write-up — dropping the label usefully means dropping the token lowering with it, which is why "decline the label" is a mechanism this backend cannot express rather than a policy it declines.

On your ask (1) — a supported way to release the standing edits, or at least the user-visible consequence documented — the documentation half is exactly the right minimum, because the consequence is invisible from inside the workspace that causes it.