DSH read-only 沙箱被绕开，通过 ssh 对远程主机进行写操作

[SuperPaiGu]

问题

这是 read-only 沙箱的BUG吗？

环境

• DSH 版本：<v0.2.1-rc.2>
• 使用模型/Agent：<Deepseek-V4.1-Flash-1017>
• 2026.10.20
• 场景：read-only 沙箱模式

背景

我是从完全权限切换到只读模式下使用的，但切换后我没有明确指明其只能进行只读操作。我希望让 AI 指导我把项目部署到服务器。结果 AI 没有只给部署步骤，而是在只读模式下直接通过 ssh 连进远程服务器执行操作。命令格式为 ssh ip "mv ..." 。我询问他为什么没有拦截，他给出的理由是：DSH 的 read-only 沙箱管的是本机文件工具（write/edit、本机删除改写等），ssh ip "mv ..."这条命令在本机看来只是“启动一个出站进程”，真正被改的是服务器上的磁盘，不经过本机沙箱裁决，所以它没被拦

[timerring]

这可能不是 bug 😂，可以看 沙箱文档 和 代码实现，目前的 read-only 限制的是执行主机上的文件写入，文档也明确说了网络访问不在这个策略范围内。

这个限制由代码和操作系统执行。例如 macOS 的规则是默认允许操作，再禁止文件写入；Linux 的实现则通过只读挂载或文件访问规则限制写入。这些规则都没有禁止联网。

所以 ssh ip "mv ..." 的过程是模型选择执行这条命令，本机的 SSH 客户端连接服务器，服务器再以登录账号的权限执行 mv。修改的是服务器上的文件，本机沙箱约束不到远端进程。所以只要认证成功、远端账号有权限，就可能执行成功。本机 shell 命令及其子进程对本机文件的写入，也受到沙箱限制。 远端可能没有限制。

[VitorRodi]

The existing explanation correctly identifies the boundary: a filesystem sandbox on the local host does not automatically restrict operations executed on a remote SSH server.

I think the main improvement here would be to make the read-only guarantee explicit and enforce it at the tool and authorization layers, rather than relying exclusively on filesystem permissions.

There are three separate controls worth considering:

1. Local filesystem restrictions: prevent modifications to protected paths on the host.
2. Process and network restrictions: control which external programs and network destinations the agent can access.
3. Remote authorization: ensure credentials available to the agent cannot perform unauthorized changes on other machines.

For environments where read-only must include remote infrastructure, I would recommend using SSH credentials associated with a restricted account that cannot modify production resources.

An additional defense would be a command-execution approval policy that requires explicit user confirmation before invoking SSH or other remote execution tools, even if the local sandbox allows the process to start.

This is more reliable than attempting to classify individual shell commands as safe. For example, a command that appears to only retrieve information locally may invoke a script or remote endpoint that produces side effects.

A useful regression test would be to configure read-only mode with remote execution approval enabled and verify that:

• Local read operations continue working.
• Remote read commands require approval according to policy.
• Remote write commands cannot execute without explicit authorization.
• Declining approval prevents the SSH process from starting.
• The same policy applies when remote execution is hidden inside scripts or wrapper commands.

I would also suggest documenting two distinct concepts:

• Local filesystem read-only mode.
• End-to-end read-only operation, including external systems.

Without that distinction, users may reasonably assume the sandbox protects infrastructure outside the host, even though the enforcement mechanism cannot provide that guarantee.

This seems particularly important for AI-assisted deployment workflows, where access to valid SSH credentials can turn an otherwise limited session into a privileged remote operation.

[SteelUnion]

这条我看得挺感兴趣，因为我那东西正好也不管这个。

我数的是持久化操作的次数。ssh ip "mv ..." 在本机看是一次调用，算一次，什么都不拦。所以靠计数也解决不了。

想问一个。你希望 read-only 的承诺覆盖到远端效果吗。

如果要覆盖，那就不是文件系统沙箱能做的事了，得看命令语义，比如出站 ssh 加带写操作的子命令。这是另一套东西。

如果你只是想让它先说一句「这一步会改服务器上的文件」，那大概是提示层，不是沙箱。

我倾向后一种更现实，但我不确定你要的是哪个。