06 审批模式与安全控制

学习目标

本章要解决什么问题：Cline 如何在安全和效率之间平衡？命令权限控制器如何防止命令注入？

前置知识

本章涉及安全沙箱的通用原理，建议先阅读：

• 安全沙箱设计

下文假设你已理解多层防御架构和命令策略引擎，直接聚焦 Cline 的具体实现。

---

项目实践

三级自动审批

autoApprove.ts 实现三级自动审批：

Yolo Mode：所有工具自动执行，适合本地开发、信任度高的场景。

Auto-approve All：除浏览器操作和 MCP 工具外的工具自动执行。这两个被排除是因为它们涉及外部系统和第三方服务。

细粒度控制：每个工具可独立配置：

• alwaysAllow：是否自动批准
• 路径限制：是否包括外部路径（如只允许读写项目目录）

CommandPermissionController

对 execute_command 工具的额外验证层：

# 伪代码：验证流程
function validateCommand(cmd: string): Decision {
    // 1. 按 && ; | 分段
    segments = splitByOperators(cmd)

    // 2. 每段独立匹配允许模式
    for seg in segments:
        if !matchesAllowedPattern(seg):
            return Prompt

    // 3. 子 shell 递归验证
    subshell = extractSubshell(cmd)
    if subshell:
        return validateCommand(subshell)

    // 4. 重定向操作符检查
    if hasRedirection(cmd) && targetsProtectedPath(cmd):
        return Forbidden

    return Allow
}

通配符模式匹配：["git", "*"] 允许所有 git 子命令，但 ["rm", "*"] 需要谨慎配置。

子 shell 递归验证：防止 $(rm -rf /) 等注入攻击，递归验证子 shell 内容。

.clineignore 文件访问控制

类似 .gitignore 的机制，限制代理访问：

• 在所有文件列表、搜索、读取操作中自动过滤
• 支持 glob 模式：node_modules/**、*.env、.git/**
• 即使工具被批准执行，也无法访问被屏蔽的文件

任务锁定

TaskLockUtils 使用 SQLite 锁防止同一任务被多个实例同时操作，避免并发执行导致状态不一致。

---

问题与规避

陷阱	场景	对策
Yolo Mode 风险	不受信的代码仓库	仅在本地可信项目中使用
命令注入绕过	复杂命令链绕过模式匹配	分段验证 + 子 shell 递归验证
.clineignore 被绕过	Agent 通过 execute_command 调用 find	需要与 CommandPermissionController 联合使用

---

设计取舍

前置审批 vs 后置审计

方案	优势	代价
前置审批	阻止危险操作执行	增加延迟
后置审计	不阻塞执行	损害已发生

Cline 选择前置审批为主，后置日志为辅：审批在 Coordinator 路由之前完成，同时记录所有工具调用日志供审计。

应用层审批 vs 内核沙箱

方案	优势	代价
应用层审批	灵活、可配置	可被绕过
内核沙箱	强制执行	平台依赖、性能开销

Cline 主要依赖应用层审批，因为作为 VS Code 扩展运行在用户本地环境，不需要跨租户隔离。内核沙箱更适合多租户场景。

---

参考来源

• Cline 源码：apps/vscode/src/core/task/tools/autoApprove.ts
• Cline 源码：apps/vscode/src/core/permissions/CommandPermissionController.ts
• Cline 源码：apps/vscode/src/core/task/tools/utils/taskLockUtils.ts