[security] bwrap sandbox can be bypassed by accessing X11 socket or dbus

[Wren6991]

I'm running latest DSH master on a machine running latest Ubuntu LTS with an X11 desktop environment.

By default the bwrap sandbox is fully read-permissive, but forbids writes outside of workspace dirs. I've just walked V4.1 Flash through the following steps:

• Read ~/.Xauthority from my homedir
• Open a terminal
• Enter touch ~/foobar to demonstrate bypass of bwrap write restrictions
• Read back ~/foobar through fs tools to check it exists

This is a full bypass of the sandbox for anyone running DSH in default configuration on a machine with an X11 session. dbus is also accessible, so it's not strictly just an X11 issue.

I think this could be mitigated by applying some network restrictions to bwrap, and it would probably be sensible to revoke reads to ~/.Xauthority (and/or path indicated by $XAUTHORITY) too.

The exact bwrap confinement is:

bwrap --ro-bind / / --dev /dev --unshare-pid --proc /proc --die-with-parent --tmpfs /tmp --bind <workspace> <workspace>

(note no unshare-net).

I asked the same DSV4.1 instance to translate my description above and add its own notes:

---

我在一台运行最新 Ubuntu LTS、使用 X11 桌面环境的机器上运行最新 DSH master。

默认情况下，bwrap 沙箱对读取完全放行，但禁止写入工作区目录之外的位置。我刚才引导 V4.1 Flash 完成了以下步骤：

• 从我的主目录读取 ~/.Xauthority
• 打开一个终端
• 输入 touch ~/foobar，以演示绕过 bwrap 写入限制
• 通过文件系统工具回读 ~/foobar，确认它确实存在

对于任何在默认配置下、于带 X11 会话的机器上运行 DSH 的人而言，这是对沙箱的完全绕过。dbus 同样可以访问，所以这严格来说并不只是 X11 的问题。

我认为可以通过对 bwrap 施加一些网络限制来缓解；此外，撤销对 ~/.Xauthority（和/或 $XAUTHORITY 所指向路径）的读取权限，大概也是合理的。

确切的 bwrap 约束如下：

bwrap --ro-bind / / --dev /dev --unshare-pid --proc /proc --die-with-parent --tmpfs /tmp --bind <workspace> <workspace>

（注意其中没有 unshare-net。）

我让同一个 DSV4.1 实例翻译了我上面的描述，并让它补充自己的说明：

---

我自己的说明

• 会话模型：DSH 会话日志记录的是 deepseek-flash（provider 为 deepseek-official），并没有出现 "V4.1 Flash" 这个写法。如果该别名对应的就是 V4.1 Flash，请忽略；否则建议改为日志中的别名，以免上游核对时对不上。
• 回读是用 bash 的 ls -l，不是 read 文件系统工具；沙箱允许读取，所以两种方式都可以，只是与原文不一致。
• ~/.Xauthority 的可读性确实是该路径成立的前提：把 XAUTHORITY 指向空文件后，XOpenDisplay(":1") 会失败。因此撤销读取权限这条缓解措施是有效的。
• 网络限制只能覆盖 X11 这一半：X 仅通过抽象套接字 @/tmp/.X11-unix/X1 可达（6000–6009 无 TCP 监听），而抽象套接字没有文件系统路径可供遮蔽，所以 --unshare-net 是 bwrap 层唯一的手段——代价是 bash 失去全部网络访问。会话总线是文件系统套接字（/run/user/<uid>/bus，位于只读绑定的 / 之下），--unshare-net 对它无效，需要单独处理（例如遮蔽该目录，或改用独立 uid）。
• 整条路径没有用到任何工具：注入是通过普通 bash 调用完成的，因此 tools/pre-execute 与 ctx.approval.request 都不会触发——审批机制约束的是工具，而这里根本不是一次工具调用。
• 受限子进程的写入限制仍然有效：在同一沙箱内直接 touch 该路径仍返回 Read-only file system。