第 30 卷

**dsh 的定位**：不是"开箱即用的整车"，是"可编程的乐高底座"。选择 dsh = 选择**自由度 **，代价是**自己要动手拼**。

12.7 官方策略风险

作为选型者，必须考虑的黑天鹅：

• **开源承诺**：MIT 开源目前无杂音，但"官方级插件体系"意味着生态深度绑定官方节奏
• **模型绑定倾向**：官方默认体验倾向 DeepSeek 模型（通过 llm 插件可接任意模型，

但"官方优化"以自家模型为主）

• **商业化转向**：一旦 dsh 用户量上来，官方可能推出托管服务/付费层——开源版能否

保持同等能力未知

• **方向漂移**：rc 期功能增删频繁（TUI/CLI 路线之争即信号），押注错误方向 = 沉没成

本

12.8 白皮书自身的局限

最后，诚实说这本白皮书自己：

• **基于 rc.6 编写**：所有命令、配置、数据在 rc.6 验证，**新版本可能全部失效**
• **benchmark 样本有限**：单机、单模型、有限任务集，不是权威评测
• **中文优先**：英文版是翻译/精简版，可能滞后于中文版内容
• **覆盖不全面**：dsh 官方包 60+，本手册深挖的是核心路径，长尾插件未逐一覆盖

> **使用建议**：把本白皮书当"rc.6 快照 + 方法论"，不要当"永恒圣经"。版本更新时，先跑一遍 [roadmap 学习路径](./roadmap.md) 与 [速查卡](./cheatsheet.md) 的验收标准，再决定要不要

更新你的依赖线。

---

*本章信息截至 2026-08-14（dsh 0.1.0-rc.6）。后续版本如有更新，欢迎提 Issue/PR 修正。

*

第 13 章：安全与沙箱模型

> 本章目标：看懂 dsh 的安全骨架——沙箱管什么、权限怎么分级、审批怎么放行——以及社区审计发现的真实边界。**这是从"能跑"到"敢上生产"的关键一章。**

TL;DR（本章核心，30 秒版）

1. **三层防线**：沙箱（在哪执行）→ 权限预设（能做什么）→ 审批（危险动作要不要

人点头）——默认不是裸执行

1. **沙箱只管文件效果**：`read-only` / `workspace-write` / `danger-full-access` 三

档；网络与进程可见性不在词汇表内（所以 `taskkill` 杀宿主等案例是"词汇表外"，不是沙箱失守）

1. **权限 = 两个旋钮捆成预设**：`sandbox/mode` + `approval/policy`；默认表两张：

`workspace-write`（工作区写 + ask）与 `danger-full-access`（无沙箱 + never）

1. **审批 fail-closed**：只有 `allowed-once` 放行；ask 无应答 = 拒绝

（unavailable），never 一切确定性拒绝——headless 的默认姿态

1. **社区审计找到真实边界**：#159 fs-sandbox 竞态、#584 scrubbedParentEnv 误

伤、#381 iframe 点击劫持、#817 审计报告（vm 逃逸 + 本地 RPC 无认证）

1. **企业基线一句话**：默认 `workspace-write`+ask、loopback 不放行、插件只装信

任源、敏感目录不进 workspace <details><summary>本章导航</summary>

• [13.1 安全设计哲学：沙箱/权限/审批三层](#131-安全设计哲学沙箱权限审批三层)
• [13.2 沙箱机制原理：fs 边界与工具沙箱](#132-沙箱机制原理fs-边界与工具沙箱)
• [13.3 权限模型：工具权限分级表](#133-权限模型工具权限分级表)
• [13.4 审批流：从请求到放行](#134-审批流从请求到放行)
• [13.5 插件安全审计清单](#135-插件安全审计清单)
• [13.6 社区已知安全案例](#136-社区已知安全案例)
• [13.7 企业安全基线](#137-企业安全基线)

</details>

13.1 安全设计哲学：沙箱/权限/审批三层

dsh 的安全骨架是三层各管一件事（依据官方 `docs/subsystems/*` 架构文档，已核验：

`sandbox.md` / `permission-presets.md` / `approval.md`；与第 8 章 8.5 实测交叉印证）：

sandbox/ sandbox-local、

sandbox/ sandbox-policy

权限能做什么interaction/把沙箱 + 审批捆成 permission-命名预设

presets

**最小权限原则**是三层共同的设计取向：默认预设只给"工作区写 + 关键操作询问"；任何提升（切 `danger-full-access`、改审批策略）都显式发生并写入会话日志—

—`permission/preset` 事件是**纯日志的用户意图**，不进模型转录，便于事后回溯"谁在什么时候提了权"。

**威胁模型速记**：三层防线防的是"不可信输入驱动代理越界"——提示词投毒、恶意插件、被诱导的高权限操作（#381 iframe 劫持就是往这条链上打）；它不承诺防"信任代码自

身"（插件就是可执行代码，见 13.5），也不承诺防网络/进程级攻击。

> 核心认知：**dsh 的工具执行默认有隔离与审批层，不是裸执行**；但它不是"安全操作系统"——沙箱不挡网络与进程、审批可以被模型自答（13.6）。

13.2 沙箱机制原理：fs 边界与工具沙箱

官方沙箱文档明确定义：**沙箱只管文件效果（filesystem effects）**，网络与进程可见性不在其词汇表内。

**三档模式**（`SandboxMode`）：

模式允许的文件效果说明

read-only只读 + 必需 sinkWindows ACL 后端无显（POSIX 下如式可写根，报 partial

/dev/null）

走 ctx.sandbox

**执行细节**：

• **策略按调用携带**（per-call）：`SandboxExecutionPolicy`（mode +

workspaceRoot + sessionId）在每次能力调用时解析，不绑死在 provider 上——同一 provider 可同时服务 `read-only` 的 bash 与需要可写状态目录的子代理

• **工作区根规范化**：先按文件系统语义 canonicalize（`symlink/..` 解析到真实目录）

再做词法归一——防符号链接绕边界