[Bug 报告] Windows 沙箱的 read-only 边界比宣传的更弱：受限令牌限制列表常驻 Everyone/登录 SID，read-only 仍可写世界可写目录

[truelove-dreamer]

建议分类：Bug report（若仓库 Discussions 有该分类）；如无则选 General / Ideas
环境：@deepseek-ai/dsh 0.1.0-rc.6，Windows（仅影响 Windows 的 dsh-sandbox-windows-acl 后端）
严重级别：我认为是 critical（Windows 专属）——权限标签与真实边界不符

摘要

Windows 上的沙箱后端（dsh-sandbox-windows-acl）用 WRITE_RESTRICTED 受限令牌做文件写入限制，但受限令牌 pass-2 访问检查的语义是"任一限制 SID 命中即放行"，而两个模式（read-only / workspace-write）的限制列表都常驻 Everyone（S-1-1-0）与登录会话 SID。因此：

• read-only 模式仍可写任何 DACL 授予 Everyone 或登录 SID 写权限的目录（如公共/共享目录、世界可写位置）；
• 受限进程新建的对象（文件/目录）默认 DACL 会被授予 Everyone FILE_ALL_ACCESS（read-only 下落到 worldSid）；
• 这与同一部署中 fs-sandbox 文件围栏的语义（read-only = 拒绝一切写，dsh-fs-sandbox/lib/index.js:161）直接矛盾——同一个"read-only"标签，两套边界。

证据（代码与行号）

代码根：node_modules/@deepseek-ai/（0.1.0-rc.6 构建产物）

1. 限制列表构成 — dsh-sandbox-windows-acl/lib/types-CNjZgO4h.js:1196-1202

   const restrictingSids = buildRestrictingSids(mode === "read-only" ? [logonSid, known.world] : ... [logonSid, known.world, ...writeSids]);

   read-only 与 workspace-write 都包含 logonSid 与 known.world（Everyone）。

2. 作者自认该语义 — 同文件 :1354-1359 注释原文：

   "the check ALSO inherits the ambient write ACEs of the other restricting SIDs — the keep-alive group logon SID + Everyone; Authenticated Users, INTERACTIVE, and LOCAL are absent from both lists …"

   即受限检查会继承"其他限制 SID"（Everyone、登录 SID）的环境写 ACE。作者为关闭 Public 树逃逸而专门从列表剔除 INTERACTIVE/LOCAL 的行为，也只有在"任一命中"语义下才有意义。

3. 默认 DACL 授予 Everyone 全权 — 同文件 :1493 + :1140
setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid) —— read-only 下两者均 undefined，落到 worldSid；setEntriesInAclW(..., buildExplicitAccess(sidPtr, 1, FILE_ALL_ACCESS), ...) 把 Everyone FILE_ALL_ACCESS 合并进令牌默认 DACL。受限进程新建对象默认 DACL = Everyone 全权（:1122 注释亦承认）。

4. fs 围栏语义相反 — dsh-fs-sandbox/lib/index.js:161：read-only 对一切写抛 FS_SANDBOX_DENIED。

复现步骤

说明：pass-2"任一命中"语义源自 Windows 文档与上述代码注释，属高置信；建议维护者在本机用 icacls 复核目标目录的 Everyone 写 ACE 后判定修复优先级。

1. 在 Windows 上用 read-only 权限模式运行 dsh（DSH_PERMISSION_MODE=read-only），或任意模式；
2. 找一个授予 Everyone 写权限的目录（例如某些公共目录、C:\Windows\Temp 类世界可写位置，或用户自建的共享目录）；
3. 通过 pwsh 工具在该目录执行写入（如 Set-Content / New-Item）：
   • 预期（按"read-only"标签）：被拒绝；
   • 实际：写入成功（受限检查被 Everyone 通道放行）；
4. 对比：同一模式下用 fs 工具写工作区外文件 → 被 FS_SANDBOX_DENIED 拒绝。两个工具对同一权限标签给出不同边界。

影响

• 权限模式标签（read-only / workspace-write）在 Windows 上不能按字面理解：它只挡住"DACL 对 Everyone/登录 SID 拒绝写"的对象；
• 新增文件默认 Everyone 可读写，若进程在共享位置创建文件（如 %TEMP% 派生目录之外的意外位置），其他本地用户可读取/篡改；
• 权限策略 UI（permission-presets）展示的模式与 shell 实际边界不一致，模型与用户都会误判。

建议修复（供讨论）

1. read-only：限制列表去掉 Everyone 通道——仅保留最小 keep-alive 集，并对目录写入采用逐目录 deny ACE 或改用非"任一命中"的机制；
2. read-only 不调用 setTokenDefaultDaclGrant（或改为最小权限默认 DACL）；
3. 让 fs-sandbox 围栏与 shell runner 对同一模式给出同一边界（或明确文档化差异）；
4. 在 README 的 Modes 一节如实描述该边界。

附注

• 已确认不是问题的部分：子进程永不在未受限令牌下启动（FAILS CLOSED）；workspace-write 的能力 SID 设计本身合理。
• 若该边界是刻意设计（"Windows 上 read-only 只防正常用户目录"），也请更新文档与 UI 文案，避免策略承诺与实际行为不一致。