[Security] WSL2 interop 通道完全穿透 workspace-write 沙箱：bwrap 只读挂载对 Windows 侧进程无效（含 PoC）

[Drazzzor]

[Security] WSL2 interop 通道完全穿透 workspace-write 沙箱：bwrap 只读挂载对 Windows 侧进程无效（含 PoC）

English abstract

On WSL2 (Ubuntu), the DSH workspace-write sandbox is fully bypassable through the WSL interop mechanism. The Linux sandbox uses bwrap (--ro-bind / /) which makes /mnt/c, /mnt/d read-only from the Linux side — but invoking powershell.exe/cmd.exe through WSL interop spawns a native Windows process that does NOT pass through the bwrap mount namespace, and runs with the full privileges of the current Windows user. This lets a sandboxed agent read/write/delete arbitrary files on all Windows drives with zero approval. Verified on 0.1.0-rc.7 (latest): a sandboxed agent deleted 26.8 GB of files on D: via Remove-Item without any approval prompt.

复现环境

• DSH: 0.1.0-rc.7（当前最新版，2026-08-18 实测）
• 宿主: Windows 11 + WSL2 (Ubuntu 26.04)
• 沙箱模式: workspace-write
• 触发面: bash/pwsh 工具 → powershell.exe interop

漏洞描述

DSH 在 Linux 上用 bwrap 实现沙箱（dsh-sandbox-local）：

function bwrapProfileArgs(policy) {
  const args = [
    "--ro-bind", "/", "/",   // 整个根文件系统只读
    "--dev", "/dev",
    "--proc", "/proc",
    "--die-with-parent"
  ];
  if (policy.mode === "workspace-write") {
    args.push("--tmpfs", "/tmp");
    args.push("--bind", policy.workspaceRoot, policy.workspaceRoot); // 仅工作区可写
  }
  return args;
}

问题：WSL2 的 interop 机制（/init 拦截 powershell.exe/cmd.exe/wsl.exe 等 Windows 可执行文件的调用）会启动一个 Windows 原生进程。该进程：

• 不经过 bwrap 的挂载命名空间（bwrap 只能约束 Linux syscall，管不到 Windows 进程）
• 直接以当前 Windows 账户（如 POWER-LR\Drazor）身份运行
• 拥有对 C:/D:/E: 等所有 Windows 盘符的完整读写权限，可执行任意 Windows 命令

bwrap 的 --ro-bind / / 让 Linux 侧看到 /mnt/c、/mnt/d 只读，制造了"沙箱生效"的假象——但 interop 是文档和实现上的盲区，沙箱对这条通道零防护。

PoC（已在 workspace-write 沙箱内实测成功）

# 在 DSH 的 bash 工具中（workspace-write 模式），无需任何审批：
powershell.exe -NoProfile -Command "Set-Content -Path 'D:\pwn.txt' -Value 'pwned'"
# → 成功写入 D 盘，无任何审批弹窗

powershell.exe -NoProfile -Command "Remove-Item 'D:\target' -Recurse -Force"
# → 成功删除任意 Windows 文件/目录（实测删除 26.8GB 无审批）

同样适用于 cmd.exe、wscript.exe、任意 .exe（interop 会把 Windows 可执行文件交给 Windows 侧执行）。

影响

1. workspace-write 的安全承诺在 WSL 下不成立：宣称"只能写工作区"，实际可读写删除 Windows 用户全部文件、改注册表、执行任意程序
2. 与 DSH 自身安全设计矛盾：DSH 拒绝 --host 0.0.0.0（"would expose remote code execution to the network"），却内置了一条不受沙箱约束的 interop RCE 通道
3. 恶意/被 prompt injection 诱导的 agent 可造成不可逆破坏（如本次删除 26.8GB，且 Remove-Item 不走回收站无法恢复）

建议修复方向

1. bwrap 层屏蔽 interop：在沙箱内以只读 bind 覆盖 /usr/lib/wsl/lib（interop 转发依赖）或在 bwrap profile 中 deny 已知 Windows 可执行文件（powershell.exe、cmd.exe、wsl.exe 等），使沙箱内无法启动 Windows 进程
2. 配置检测：检测 /etc/wsl.conf 的 [interop] enabled=false，未禁用时对 interop 调用强制走审批或直接拒绝
3. 审批钩子：对 argv[0] 是 Windows 可执行文件（含 .exe/.bat/.cmd）的调用强制要求审批（类似 Windows ACL runner 的做法）
4. 文档：在 docs/subsystems/sandbox.md 的 Enforcement is a reported fact 段落补充 WSL interop 的 partial-enforcement 说明，明确该场景下 workspace-write 不提供 Windows 侧隔离

参考

• 官方文档承认边界不完整：https://github.com/deepseek-ai/DeepSeek-Harness/blob/master/docs/subsystems/sandbox.md （"the Windows ACL runner's Everyone/hard-link boundaries are current partial cases"）
• 同类沙箱逃逸报告（未覆盖本通道）：
  • [Security] 安全审计报告：沙箱/审批边界绕过与本地 RPC 无认证（PoC 可私下提供） #817
  • 高危问题：vm 沙箱逃逸 ×2 + 本地 /api RPC 无鉴权 #451

备注

• 发现时间: 2026-08-18
• 环境: DSH 0.1.0-rc.7 / WSL2 Ubuntu 26.04 / Windows 11
• 已实测的破坏案例: 沙箱内 agent 通过 interop 永久删除 D 盘 26.8GB 文件（Remove-Item -Recurse -Force），无审批
• 完整 PoC 与破坏性复现脚本可私下提供（涉及在真实文件系统上执行删除，不适合公开全文；可联系作者获取，或按本文 PoC 自行验证）

[weijiafu14]

这份报告的定位是对的，而且我想指出一件可能比 WSL 本身更重要的事：这不是一个 WSL 特有的洞，它是一整类洞在 WSL 上的实例，而同一类的另一个实例上周已经在这个社区被独立报出来过了。

一、先给读到这帖的人一条现在就能做的

你把 /etc/wsl.conf 的 [interop] enabled=false 列成了"DSH 应该检测的配置"。对今天的用户来说，它其实是当下唯一在正确层次上的缓解：

# /etc/wsl.conf
[interop]
enabled=false
appendWindowsPath=false

然后 wsl --shutdown 重启该发行版。

之所以说"正确层次"：interop 是 WSL 自己的 binfmt 转发机制，关掉它的开关在 WSL 手里，不在 DSH 手里。DSH 侧的任何缓解都是在猜黑名单——你自己在建议 1 里也点到了这个问题（"deny 已知 Windows 可执行文件"），而 .exe 的名字是无穷的，wscript.exe 你已经举了一个，还会有下一个。关掉转发本身，比枚举可执行文件名强一个数量级。

代价要说清：关掉之后你在这个发行版里就调不了 Windows 程序了。对专门跑 agent 的 WSL 实例这通常无所谓；对日常开发的主力发行版会很难受。所以更实际的做法是给 agent 单开一个发行版（wsl --import 一个干净的），在那个里面关掉 interop——顺带还把 Windows 侧的可达文件范围也一起收窄了。

二、这一类的名字：沙箱管的是系统调用，管不了"委托给一个不在沙箱里的执行者"

你写了一句很准的话：

bwrap 只能约束 Linux syscall，管不到 Windows 进程

把它一般化就是：bwrap / Seatbelt 这类沙箱约束的是"这个进程自己能做什么"。当进程把工作委托给一个沙箱外的执行者时，它自己一个越权系统调用都没发出——所以沙箱没有任何理由报警。

而这不是 WSL 独有的。同一个社区里有另一份独立的报告，形状一模一样，只是换了操作系统：

• #4503（macOS）：Seatbelt profile 里只有 deny file-write*，unix socket 的 connect(2) 不受约束——于是沙箱内的进程可以连上 Docker daemon 和 ssh-agent。连 daemon 不是写文件，但 daemon 会替你写；用 ssh-agent 签名不是读私钥，但签名的效果一样。

两份报告并排看，共同点非常清楚：

	你这份（WSL2）	#4503（macOS）
沙箱机制	bwrap mount namespace	Seatbelt deny file-write*
沙箱内的动作	执行 powershell.exe	connect(2) 一个 unix socket
这个动作违规了吗	没有	没有
谁替它干了活	Windows 侧原生进程	Docker daemon / ssh-agent
结果	删掉 D 盘 26.8GB	容器逃逸 / 用私钥签名

所以修法也是同一个形状：沙箱策略必须显式处理"通往沙箱外执行者的通道"，而不只是文件和路径。你建议的第 1 条（屏蔽 interop 转发）和 #4503 需要的（限制 socket 连接）是同一条原则的两个实例。

我建议你把这个交叉引用加进原帖——两个平台上各有一份独立复现的报告，比任何单份都更能说明"沙箱模型漏了一整个维度"，而不是"WSL 有个 bug"。你已经引了 #817 和 #451，#4503 值得加上，因为它是唯一一份不同操作系统、同一类原理的。

三、关于你的建议 3，我有保留意见

对 argv[0] 是 Windows 可执行文件（含 .exe/.bat/.cmd）的调用强制要求审批

这条在用户审批的意义上是合理的（人来看一眼）。但如果实现成"让模型判断这次调用安不安全"，那就是错的层次——在这个威胁模型里，被 prompt injection 诱导的正是模型本身，让它审批自己是没有边界可言的。你原文里"恶意/被 prompt injection 诱导的 agent"这句已经说明你清楚这一点，我写在这里是怕后面的讨论跑偏。

另外 argv[0] 匹配本身也容易被绕（/init 转发、wsl.exe -e、软链、cmd.exe /c 套一层），所以它适合当审计信号，不适合当安全边界。真边界还是在第 1 条和第 2 条——把转发通道本身关掉。

边界与利益相关

我们不修 DSH 自家组件——dsh-sandbox-local、bwrap profile、审批链路全在 DSH 里。上面全部是缓解建议和跨报告的归类，不是我能替你落地的东西。我没有在 WSL 上复现过你这个 PoC（我在 macOS 上），上面关于 interop 机制的部分是按 WSL 的公开行为写的，实测以你的为准。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销，而且是原则性的：我们生态里有"让第二个模型逐次审批工具调用"的插件，在这类帖子上推它是根本性的错误建议——攻击者就是模型，再加一个模型不构成边界。这条口径我在 #250 / #4503 / #4384 都写过，这里第四次。

（另：你把 PoC 里真正破坏性的那部分留作私下提供、公开版只留可自证的最小写入，这个处理方式很得体。）