第 17 章 · 安全边界与隔离

本篇目标：正确理解「沙箱不是安全边界」这句话，并据此做架构决策。 这一章的结论可能不讨喜：DSH 目前不能作为生产安全基座。

17.1 官方声明的准确含义

官方 SAFETY.md 逐条拆开：

原文 作者补的一句与官方完全一致：「动态插件虽然运行在沙箱环境里，但沙箱不是安全边界。」

判据 21：凡是需要「保证」的隔离，必须由 Harness 之外的边界提供——一次性 VM / 容器 / 独立主机 / 网络策略 / 专用账号。Harness 内部的沙箱只是降低概率的一层，不是保证。

17.2 纵深防御：权限与沙箱是两层，不是一层

官方 Claude Code 文档给出目前最清晰的表述：

关键结论：两者结合才是纵深防御。Deny 规则阻止尝试，沙箱阻止 Bash 越界；PreToolUse hook 返回 allow 不会绕过 Deny 规则（Deny 仍会被评估）。

官方 常用配置键：

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "allowWrite": ["/tmp/session"],
      "denyWrite": ["~/.ssh", "~/.aws", ".env"],
      "denyRead":  ["~/.ssh", "secrets/"]
    },
    "network": { "allowedDomains": ["api.example.com"] },
    "credentials": {
      "files": ["~/.ssh", "~/.aws"],
      "envVars": { "API_TOKEN": { "mode": "mask" } }
    }
  }
}

envVars 的 mask 模式值得单独说：真实 token 在命令里被替换成哨兵值，只对允许的主机注入真值。这样即便模型把命令打印进日志，凭据也不会泄漏。

--dangerously-skip-permissions 在官方文档里被标注为仅容器场景适用，不推荐用于 CI；更安全的模式是 sandbox + auto-allow。

17.3 威胁模型（逐条给对策）

第 6 条最容易被忽略：ctx.effect() 能撤销注册，撤不回一条已经 push 的 commit（第 11 章）。唯一解法是在动作发生前拦住。

17.4 在 DSH 上的最小安全配置

官方 subsystems/approval / permission-presets / sandbox 三个子系统页是入口。落地动作：

⚠️ 本教程不提供「一键公网暴露 DSH」或「关闭审批以提速」的配置。这两件事在官方安全声明下都属于不负责任的建议。

17.5 事故响应

出事时按固定顺序，别先去查模型：

① 隔离：停宿主 / 断网 / 撤销 API key
② 保全：复制 append-only 事件日志与 audit log（别重启覆盖）
③ 重建：从 Trajectory 按来源还原「模型当时看到了什么」
④ 定责：外部注入？插件？配置？还是模型输出？（第 06 章二分法）
⑤ 固化：新增一条规则 + 一个 hook / deny 规则 + 一个 coverage test（第 07 章）
⑥ 验证：用事故输入做一条 eval 用例，进 suite，永不移除

第 ⑥ 步是 ratchet 在安全场景的形态：每一次事故都必须变成一条永久回归用例。

17.6 本章产出与验收

核心产出：一份本项目威胁模型表（10 类逐条对策）+ 最小权限配置 + 一次「注入攻击被拦下」的验证记录。

验收点：

• 能逐字说清 SAFETY.md 对「生产就绪」的结论
• 能解释权限与沙箱为何互补、各自覆盖不到什么
• 能说出 ctx.effect() 撤不回什么，以及唯一解法
• 能列出至少 3 条必须放在 Harness 之外的安全控制
• 能把一次事故转成一条永久 eval 用例

延伸阅读