Windows ACL 沙箱的 standing Low 完整性标签会使工作区内其他工具无法写入（Electron 构建静默退出）

[Kevin-studio-guan]

Summary

在 Windows 上，只要某个 DSH 会话以 read-only 或 workspace-write 在工作区目录中执行过任意一条 shell 命令，dsh-sandbox-windows-acl 就会给该目录写入一个**永久生效（standing，永不撤销）**的 Low 完整性强制标签（mandatory label）。该标签带 NO_WRITE_UP 且可继承，会立即传播到整棵目录树。

后果：工作区内任何以普通（Medium）完整性运行的进程都无法再写入这些路径。受影响的不只是 DSH——用户自己的构建与开发工具链全部受影响。本次实际表现是 Electron 应用启动时静默退出（exit 3），项目无法再 dev 启动，而 DSH 未提供任何撤销该标签的入口。

受影响的用户场景：任何把日常开发项目目录作为 DSH 工作区打开、并使用默认 workspace-write 预设的人。触发条件是该目录中执行过一次 shell 命令。

Reproduction

环境：Windows x64、dsh 0.1.7-rc.2、profile web。

1. 取一个普通项目目录，确认其 ACL 干净：

icacls 'G:\path\to\project'

预期：只有 BUILTIN\Administrators / SYSTEM / Authenticated Users / Users 等常规继承 ACE，无 S-1-4-*、无 DENY、无 Mandatory Label 行。

2. 在 DSH Web 中将该目录作为工作区打开，保持权限预设为 workspace-write，执行任意一条 shell 命令（bash 或 pwsh 工具均可，例如 echo ok）。

3. 再次检查该目录及其任一子目录：

icacls 'G:\path\to\project'
icacls 'G:\path\to\project\src'

4. 尝试在该目录中启动任何以 Medium 完整性运行的普通应用（Electron/Chromium 应用、需要写入该目录的构建脚本等）。

Current behavior

第 3 步后，目录 ACL 变为（实测输出，已脱敏）：

G:\path\to\project    Everyone:(CI)(DENY)(S,DC)
                      S-1-4-<a>-<b>:(OI)(CI)(W,D,DC)
                      <常规继承 ACE...>
                      Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

• Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) —— Low 完整性标签，NW 为 NO_WRITE_UP，(OI)(CI) 使其向下继承。
• 子目录显示 (I)(OI)(CI)(NW)，文件显示 (I)(NW)，即已全部继承。

实测继承范围：一个含 node_modules 的项目目录被标记后，icacls <dir> /setintegritylevel M /T 需要处理 85613 个对象，即整棵树都被写入。

第 4 步：Electron 应用启动时静默退出，exit code 3，无错误输出。原因推断为 Chromium 需要把 ICU 数据映射/写入工作区内的路径，而 Low 完整性标签与 NO_WRITE_UP 使完整性检查失败。

S-1-4-<a>-<b> 与 workspaceWriteSid() 由工作区路径推导的结果逐位一致，可确认为本后端所写（见下方证据）。

此外，撤销途径缺失：

• 工作区 ACE 与标签按设计为 standing，dispose() 不撤销它们。
• README 记载手动 icacls 清理在本平台会失败。实测确认：icacls <dir> /grant "*S-1-4-<a>-<b>:..." 返回 ERROR_NONE_MAPPED（1332），因为 sucount 无法映射该派生 SID。

Expected behavior

沙箱的写边界应当只约束被它启动的子进程，而不应使工作区对用户自己的普通进程变为只读/不可写。

至少应满足其一：

1. 提供受支持的撤销途径（公开 API 或命令），能移除工作区的 standing ACE 与 Low 标签；
2. 不对用户自有项目目录写入 standing 的完整性标签，或将其限制在 DSH 自身管理的目录内；
3. 在打标签前明确告知该目录将发生的不可逆文件系统变更。

Environment

• DSH：0.1.7-rc.2（dsh CLI 自 package.json 上报），profile web
• 平台：Windows x64（win32 / x64）
• 相关包：@deepseek-ai/dsh-sandbox-windows-acl、@deepseek-ai/dsh-sandbox-local、@deepseek-ai/dsh-sandbox-policy
• 会话预设：workspace-write（approval: ask）；read-only 同样触发
• 规避方式：会话改用 danger-full-access 预设后不再触发（该模式不经过 confine()）

---

给维护者的补充材料

证据链

1. 派生 SID 由本后端算法产生。 workspaceWriteSid() 对规范路径做 SHA-256 后取两个 30 位子权限：

// packages/sandbox/sandbox-windows-acl/src/workspace-sid.ts:35 (签名) / :36 (摘要计算)
export function workspaceWriteSid(workspaceRoot: string): string {
  const digest = createHash('sha256').update(workspaceRoot, 'utf8').digest()
  const first = (digest.readUInt32LE(0) % (2 ** 30 - 1)) + 1
  const second = (digest.readUInt32LE(4) % (2 ** 30 - 1)) + 1
  return `S-1-4-${first}-${second}`
}

以实测路径代入该函数（workspaceRoot 摘要计算位于 :36），结果与目录 ACL 中的派生 SID 完全一致（S-1-4-440924568-613075690）。

2. 三项改动与 grantWrite() 的一次性写入一致。 目录 ACL 同时出现了 capability-SID allow ACE、FILE_DELETE_CHILD 的 world deny、以及 Low no-write-up 标签，对应 README § Mechanism 所述的"一条 SetNamedSecurityInfoW 调用中应用全部三项编辑"。

根因

触发路径（均为只读确认）：

① 用户将项目目录作为 DSH 工作区打开（会记入 workspace 注册表）
② 会话预设为 workspace-write 或 read-only
③ 该会话执行任意 shell 命令
     → packages/sandbox/sandbox-local/src/index.ts:373  materializeAclGrant(sessionId, policy.workspaceRoot)
④ 工作区根取自会话的 cwd，未校验该目录是否属于 DSH 自身
     → packages/sandbox/sandbox-policy/src/index.ts:168
       workspaceRoot: resolveWorkspaceRoot(session?.header.cwd ?? this.workspaceRoot)
⑤ standing 授权与 Low 标签写入（不可撤销）
     → packages/sandbox/sandbox-local/src/index.ts:403  grant.add(workspaceRoot, true)
     → packages/sandbox/sandbox-windows-acl/src/acl.ts  grantWrite()

与既有决策记录的差异。 2026-09-19 决策记录 § Bought 记录的代价是：

the standing Low label widens the workspace tree for ANY other process running at Low integrity as the same user and outlives DSH

README § Known Limitations 同样表述为：

any other process running at Low integrity as the same user … can write and delete inside the workspace, where a Medium label would have denied it

两处描述的都是宽松化方向（Low 进程获得了写权限），属已知且被接受的边界放松。

但实际后果是反向的：Medium 完整性进程（Electron/Chromium、普通构建工具）因目标被标 Low 而被拒绝写入，导致工作区对用户自己的工具链变为不可用。这一方向未见于上述两处记录，也未见于决策记录 § Cost 列表。

换言之：已评估的代价是"边界变松"，未评估的代价是"用户工作区对普通进程变为只读，且不可撤销"。

建议修复方向

按影响从大到小：

1. 提供撤销 API/命令，至少能移除指定工作区的 standing ACE、world deny 与 Low 标签。当前完全没有清理入口，用户只能手工编辑 ACL。
2. 限制 standing 标签的适用范围。若工作区根来自用户项目目录而非 DSH 自管目录，考虑不写 standing 标签，或在会话结束后撤销。
3. 打标签前告知，或在文档中把"标签会破坏工作区内其他工具"列为显式限制，而非仅描述宽松化方向。
4. 顺带：icacls 无法处理 S-1-4-*（ERROR_NONE_MAPPED），使任何依赖 icacls 的清理脚本都失效；若提供清理命令，需走 Win32 API 而非 icacls。

用户侧规避与恢复（供其他遇到者参考）

规避：在该类目录中将会话设为 danger-full-access（不经过 confine()，不写标签）。

恢复（本次实测有效，在一个含 node_modules 的目录上处理了 85613 个对象、0 失败）：

# 先备份原始 ACL
icacls '<dir>' /save "$env:TEMP\acl-backup.icacls"

# 1. 移除 world deny（icacls 可处理）
icacls '<dir>' /remove:d "Everyone"

# 2. 移除派生 SID ACE（icacls 不可处理，用 PowerShell ACL API）
$acl = Get-Acl -LiteralPath '<dir>'
$acl.Access | Where-Object { $_.IdentityReference.Value -eq 'S-1-4-<a>-<b>' } |
  ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -LiteralPath '<dir>' -AclObject $acl

# 3. 递归清除 Low 标签
icacls '<dir>' /setintegritylevel M /T

注：/setintegritylevel M /T 会把标签改为显式 Medium Mandatory Level:(NW)，与"完全无标签"不等价，但不再阻断 Medium 进程。恢复后新创建的文件不再继承 Low 标签。

[PerryLink]

⚠️ 请先确认一件事：挡住 Medium 进程的更可能是那条"拒绝"而不是 Low 标签

1. 你的现象与标签的语义之间有一处不一致

Windows 的强制完整性控制（MIC）规则是"不得向上写"（no write-up）：Medium 进程写 Low 对象是"向下写"，本该是允许的。而"Low 标签阻止 Medium 写入"不符合这条规则。所以请先排除另一个更可能的元凶。

2. 同一次授权其实写了三样

packages/sandbox/sandbox-windows-acl/README.md:90（原文）：

… Each grant therefore also denies FILE_DELETE_CHILD to the world SID … and labels the same directory Low in the one SetNamedSecurityInfoW call that applies all three edits.

⇒ 那三样是：能力 SID 的 allow ACE、对 world SID 的 FILE_DELETE_CHILD 拒绝项、以及 Low 完整性标签。其中：

• Low 标签位于 SACL，是完整性标签；
• FILE_DELETE_CHILD 拒绝项位于 DACL，而且拒绝 ACE 会传播到既有子对象，与进程的完整性级别无关。

你的症状（Electron 构建在启动时静默退出、项目无法 dev）恰好是"要删除/替换输出"这类操作 ⇒ 更像被那条拒绝项挡住。这也与同族报告完全一致：另一位报告者清掉 D:\DSH 上的"low 完整性标签"后 pnpm run build 恢复，但他很可能同时清掉了 DACL 上的拒绝项（常见工具是"重置继承/恢复默认权限"）。

3. 请做这一步来定案（一条命令）

用 icacls <工作区> 看该目录上的完整 ACL，重点找：

1. 是否有一条对 Everyone（或 world SID）的 (DENY)，且权限是 DELETE_CHILD/DE ⇒ 若在，它就是首要元凶；
2. 该目录的完整性标签（icacls 本身不显示标签；需要看 SACL，例如 Get-Acl -Audit 或专用工具）。

把这两项的输出贴进正文——这能把"标签 vs 拒绝项"一刀切开，也决定维护者该修哪一处。

4. 你这条的价值在于"跨出 DSH"

你指出**"受影响的不是 DSH 自己，而是用户自己的构建与工具链"——这一点很重要，而且同一天在另一条帖子里得到了独立印证（D:\DSH 曾作项目目录，离开 DSH 之后 pnpm run build 坏掉）。建议你与那两条互相引用（工作区内写不进 / 其他工具写不进 / DSH 之外也写不进），三条合起来才是完整的"常驻标签的代价"。包内 README :121 其实主动记录了**这条代价（"A standing Low label outlives DSH and widens the tree…"）——引它可以让你的报告从"抱怨"变成"已知设计缺了清理入口"。

5. 最该提的诉求

DSH 应当提供撤销该常驻授权（标签 + 那条 deny）的入口，或在授权时限定作用范围，使工作区目录不被永久改造成"只有 Low 能操作"的状态。

"没有撤销入口"是这条报告的核心——比争论标签还是 deny 更重要。

6. 版本

你在 dsh 0.1.7-rc.2——就是当前最新，无需升级。⚠️ 只是别把核换成 latest（仍停在 0.1.5-rc.3，更旧）。

一条边界

我确认的是包内文档对"三样一次写入"与"拒绝传播"的描述，以及MIC 允许向下写这条通用语义 ⇒ 因此"标签挡住 Medium 写入"这一说法可疑。到底是哪一样在你的机器上起作用，取决于第 3 节的 ACL 输出——我不想在没有它的情况下替你断言。