[Security] Windows 沙箱 partial 边界对模型与运维不可见，pwsh 命令缺少强制批准门

[snzhongcheng]

现象

windows-acl 沙箱档（enforcement: 'partial'）在 README 中记录了其结构性边界
（WRITE_RESTRICTED 必须保留 Everyone；NTFS 硬链接跨路径别名），但：

1. 面向模型的 pwsh 结果没有呈现这些边界——受限运行看起来与完全受限无异，
   模型可能误判一次写入仍在工作区内；
2. 运维侧在工作区根目录本身已让限制失效时（Everyone/Authenticated Users
   写 ACE，或 FAT 系卷）没有任何信号；
3. 需要每条 pwsh 命令人工确认的部署没有开关。

建议修复（已实现，附 fork 代码）

1. partial 提示：pwsh 结果对 enforcement: 'partial' 的运行追加
   [sandbox: partial enforcement — ...]（exit 标记之前）；
2. 工作区根目录检查：inspectWritableRoot() 检测 Everyone/AU 写 ACE 与
   FAT 系卷，sandbox-local 每工作区一次输出 [sandbox: workspace warning — ...]；
3. pwsh 批准门：pwshRequireApproval（默认 false），每条前台/后台调用先经
   ctx.approval，非 allowed-once 一律失败关闭；实时值来自 pwsh settings
   命名空间（已纳入 dsh-apiproxy 的 Web 设置白名单），设置面板提供开关行。

实现：https://github.com/snzhongcheng/deepseek-harness
（提交 feat: pwsh 命令批准门与 Windows 沙箱边界提示）

验证

• 单元测试：tool-pwsh / sandbox-windows-acl / sandbox-local /
  ui-permission-presets / apiproxy，全部通过；
• pnpm run lint、typecheck、duplication、翻译配对等门禁全绿；
• Windows 实测：partial 提示每次受限运行出现；批准弹窗拦截/拒绝命令生效。

影响范围

仅 Windows 的 pwsh 路径；bash 与非 Windows 平台行为不变。

[weijiafu14]

你这份提案里第 1 条被低估了——它比另外两条更普遍，也更该单独提。另外补一条同平台的第三个边界，它可能需要进你那个提示框架。

一、"边界对模型不可见"是一条通用缺陷，不只是 Windows ACL 的事

面向模型的 pwsh 结果没有呈现这些边界——受限运行看起来与完全受限无异，模型可能误判一次写入仍在工作区内

这句话的一般形式是：一个执行环境向它的消费者谎报了自己的强度。 模型收到的信号是"命令成功了"，它据此推断"我在沙箱里，所以这次写入被约束住了"——而这个推断在 enforcement: 'partial' 下不成立，却没有任何东西告诉它。

这个形状最近在社区里出现得很密：

• #2485：Windows 上 hook 桥拿不到子进程真实退出码，一个 PreToolUse deny hook 被静默跳过——用户手里是一份"加载了、跑了、什么都没拦住"的配置；
• #1967：用户开着 workspace-write 却看到 agent 在 C:/tmp 建文件，完全不知道该怀疑哪一层。

共同点：执行/防护机制的实际强度，对它的消费者（模型、用户、运维）不可见。 而你的第 1、2 条正是在补这个可见性——[sandbox: partial enforcement — ...] 和 [sandbox: workspace warning — ...] 是同一个思想的两个落点。

我建议把第 1、2 条从"pwsh 提示"提升成一条通用原则："沙箱档在 enforcement 不是完全强制时，必须在每次受限运行的结果里如实声明。" 这样它不再是 Windows ACL 的特例，而是一条对所有沙箱档（包括将来新增的）都成立的契约要求。理由很实际：下一个 partial 档出现时，不会有人记得再打一遍这个补丁。

二、Windows 上还有第三个边界，而且它是完全绕过不是部分强制

#3045 报了一个已复现的洞：在 WSL2 上，workspace-write 沙箱可以被 WSL interop 完全穿透——沙箱内调 powershell.exe，启动的是一个 Windows 原生进程，不经过 bwrap 的挂载命名空间，以当前 Windows 账户身份运行，对所有盘符有完整读写权限。那份报告里实测删掉了 D 盘 26.8GB，零审批。

这和你说的 partial 不是一回事，但对用户来说结果更严重：partial 是"约束不完整"，interop 是"约束不存在"。而两者共享同一个缺陷——用户和模型都看不出来。

你那个提示框架正好是它的落点。建议在提案里加一句：enforcement 声明应该覆盖"这条执行路径根本不经过沙箱"的情况（比如 argv[0] 是 Windows 可执行文件、或检测到 interop 未禁用）。

（对读到这帖的 WSL 用户，当下的缓解在 WSL 那侧不在 DSH 侧：/etc/wsl.conf 里 [interop] enabled=false 然后 wsl --shutdown。关掉转发本身，比枚举 .exe 黑名单强一个量级——名字是无穷的。）

三、你的第 3 条（pwsh 批准门）方向对，理由值得写清楚

我想特意肯定一件事：你做的是 ctx.approval——人来批，不是"再叫一个模型判断这条命令安不安全"。这个区别在这类帖子里很关键。在这个威胁模型里，可能被 prompt injection 诱导的正是模型本身，让模型审批模型不构成边界。你选对了。

两个建议：

1. 默认 false 是对的，别改。每条命令都弹窗会迅速产生批准疲劳，用户开始无脑点"允许"——那时这个门的实际强度就回到了零，而且和第 1 条一样不可见。它适合作为高保障部署的开关，不适合作为默认姿势。
2. "非 allowed-once 一律失败关闭"这个选择值得在提案里点名。这正是 Windows: dsh plugin add splits paths with spaces, and hook bridges fail open silently #2485 那条缺的东西（那边是裁决拿不到时放行）。同一个仓库里，一个门 fail closed、一个门 fail open，这个对照本身就是推动那边修复的论据。

边界与利益相关

我们不修 DSH 自家组件——sandbox-windows-acl、sandbox-local、tool-pwsh 都在 DSH 里。上面全是意见和串联。我没有 Windows 环境，没有复现过你这三条，也没跑过你的 fork；第二节引的 #3045 同样是别人的报告，我只做了归类。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销，而且是原则性的：我们生态里确实有"第二个模型逐次审批工具调用"的插件，但在安全边界的帖子上推它是错的——理由见第三节。真边界在 ACL、在 interop 开关、在人的批准，那都是 DSH 和操作系统的事。