OpenClaw 安全的发展方向

# OpenClaw 安全的发展方向 — OpenClaw 博客 来源: https://openclaw.ai/blog/where-openclaw-security-is-heading 我们的目标是让 OpenClaw 成为运行强大 AI 个人助手的可信方式。 OpenClaw 可以读取文件、运行命令、安装插件、与网络通信，并在真实机器上为真实用户执行操作。这样的能力很容易被描述为危险。这种担忧是合理的。强大并不意味着盲目、无界或无法审计。 其中一部分已经落地。一部分正在推出。一部分还在开发中。一部分是研究。我想明确区分它们，因为那些模糊界限的文章会误导读者。 ## 文件系统边界与 fs-safe OpenClaw 运行在你的机器上。这意味着它可以访问你的文档、代码库和照片。 人们通常最先想到的文件系统风险是路径遍历。这种风险确实存在，但它也只是更大一类 bug 的一个症状：边界不清。代码以为它在某个根目录内写入，但一个符号链接、绝对路径、解压归档或草率的拼接让它越界了。 `fs-safe` (https://fs-safe.io/) 是其中一种应对方案。它是 OpenClaw 已经积累的 安全文件系统模式集合 (https://docs.openclaw.ai/gateway/security/secure-file-operations)，被打包成一个共享库，以便核心代码、插件和相邻服务可以使用相同的根限制原语。 它不是沙箱。一个被允许运行任意 shell 命令的插件仍然可以做 shell 命令能做的所有事情。`fs-safe` 防范的是文件系统代码中的边界穿越 bug。 在插件工作区内写入应该成功。穿越和绝对路径写入到工作区外应该失败。插件作者不应该需要重新实现这些检查。 终端输出显示 fs-safe 允许工作区内写入，并阻止穿越和绝对路径写入为“工作区外”。在工作区内写入成功。穿越和绝对路径写入被拒绝并标记为“工作区外”。下一步是让这些原语成为 ClawHub 上插件的预期模式。绕过它们并不自动意味着恶意，但它是安全性相关的。随着时间的推移，这种选择应该会对插件的信任状态产生负面影响。 最安全的文件系统调用仍然是我们根本不做的那种。这是正在进行的 SQLite 运行时状态重构背后的安全动机。会话、转录、调度器状态和插件状态应该属于一个带有清晰所有权和事务的类型化数据库，而不是松散的零散文件。将运行时状态移入 SQLite 从运行时路径中移除了整类文件系统访问。 ## 网络出口与 Proxyline 智能体系统使得 SSRF 比在普通 web 服务中更难处理。在普通服务中，用户控制的 URL 往往是例外。在智能体运行时中，用户控制或模型影响的 URL 是正常的产品行为。“获取这个 URL，因为某人或某物要求了它”是正常的工作。 我们从最明显的方法开始：在获取 URL 之前验证它。但这还不够。验证会解析 DNS，而获取时又会解析一次 DNS，结果可能在两次之间发生变化。在验证时指向一个公网 IP 的主机，到请求发出时可能指向一个元数据端点。 修复必须更靠近出口。 Proxyline (https://proxyline.dev/) 是我们为此提供的 Node 进程路由层。它为 Node 网络接口安装进程级路由，并将流量发送到你所配置的代理 (https://docs.openclaw.ai/security/network-proxy)。配置的代理应该是连接时策略所在之处：阻止元数据地址、私有范围、环回探测地址以及你的环境需要阻止的任何其他内容。 Proxyline 负责路由。代理负责执行。 它还让运维人员拥有可观测性。如果你已经在运行一个托管代理，你可以将 OpenClaw 流量路由通过它，并从你已经信任的基础设施上监控目标、速率和被阻止的尝试。 Proxyline 并不是一个针对所有可能字节的完美牢笼。原始套接字、原生模块、非标准传输、早期捕获的代理以及非 OpenClaw 子进程仍然可以绕过 Node 级别的护栏。但对于普通的 OpenClaw 网络路径，将控制点从“某个包装器记得验证这个 URL”转变为“出口流量通过代理策略”是一个好得多的形态。 验证路径很简单：`example.com` 应该通过，环回探测地址应该失败，并且 `openclaw proxy validate` (https://docs.openclaw.ai/cli/proxy) 应该证明配置的路由行为符合预期。 终端输出显示 openclaw proxy validate 允许 example.com，拒绝环回探测地址，并通过验证。本地过滤代理允许 `example.com`，阻止环回探测地址，并且 `openclaw proxy validate` 通过了。 ## ClawHub 上的插件信任 当插件来自 ClawHub 时，ClawHub 必须是插件信任和来源的权威。OpenClaw 应该在安装和更新时消费这些信号，而不是事后仅依赖本地检查。 ClawHub 管道是一个信号混合体：ClawScan、VirusTotal、静态分析、元数据检查、来源验证以及人工审核。这些都不是魔法。扫描器在不同方面都有噪声，一个对什么都大喊大叫的管道会教会用户忽略它。 这正是 ClawHub (https://docs.openclaw.ai/clawhub) 可以做到本地安装流程做不到的事情的地方。它可以将信任证据 (https://docs.openclaw.ai/clawhub/security-audits) 附加到特定包版本。它可以说明这个版本是干净的、可疑的、搁置的、隔离的、撤销的或恶意的。它可以阻止下载恶意或隔离的版本 (https://docs.openclaw.ai/clawhub/moderation)。它可以向用户展示发生了什么变化以及原因。 插件可以来自 GitHub (https://docs.openclaw.ai/cli/plugins)、私有仓库或别人发给你的文件。这不会改变，OpenClaw 不应该假装用户不拥有自己的机器。 我们能做的是让安全路径更好。在 ClawHub 上发布。接受扫描。附加证据。让用户在安装前评估证据。 我们也在探索基线之上的更高信任层级：官方包、可信发布者以及接受更严格审核标准的包。对于 ClawHub 之外的插件，我们也希望扫描能覆盖到它们，但具体的产品形态仍需努力。 如果 ClawHub 将一个版本标记为恶意并隔离，那么 ClawHub 的安装路径应该拒绝它。这是标准。 终端输出显示 OpenClaw 拒绝安装一个被 ClawHub 标记为恶意和隔离的版本。ClawHub 将一个版本标记为恶意并隔离；OpenClaw 拒绝安装。 ## 命令审批与提示疲劳 提示的出现速度比任何人阅读它们都快。几分钟后，用户就会开启 YOLO 模式以便工作继续。这时，提示会训练用户不再阅读。 解决这个问题意味着更少的提示以及更好的提示。 准确性部分从解析开始。字符串匹配是不够的。如果允许列表或阻止列表只看到外部命令，那么包装器就成了绕过手段。一个知道 `rm` 但看不到 `bash -c "rm -rf ~/something"` 内部内容的策略，不是用户应该信任的策略。 Shell 审批路径 (https://docs.openclaw.ai/tools/exec-approvals) 现在会评估常见 shell `-c` 包装器内部的命令链。如果内部链包含不被允许的可执行文件，那么包装器不应该让它变得安全。命令高亮器也使用 Tree-sitter 来展示 OpenClaw 在包装器内部发现了什么。 OpenClaw 执行审批对话框，高亮显示嵌套的 bash 和 Python 命令中的可执行文件，包括 rm。命令高亮器识别包装器载荷内部的可执行文件，包括内部的破坏性命令。PowerShell 有其自身的陷阱；对于不理解的形式，我们默认拒绝，更广泛的支持已在路线图中。 解析是较容易的一半。较难的一半是决定何时询问。 一个静态审批策略要么对可能有风险的一切进行提示，要么依赖于一个固定的允许/拒绝列表，无法判断命令是否适合当前任务。 用户真正关心的问题：我想让这个发生吗？ 这就是为什么我们正在实验上下文审批。目标不是“永不提示”。目标是提示意味着某些东西——当它们出现时，用户应该停下来阅读。 对于 OpenAI 用户，我们公开了 Auto Review (https://developers.openai.com/codex/concepts/sandboxing/auto-review)，这是一个 codex 特定的功能，它在沙箱边界用独立的审查代理替代了手动审批。 ## 静态分析 OpenClaw 曾有很多 GitHub 安全公告。第一项工作是堵住漏洞。下一项工作是确保同类 bug 不再重现。 补丁一个公告后，很容易认为工作完成了。一个 GHSA 是关于一类 bug 的证据，而不仅仅是一个 bug。分类后的问题是：我们能找到所有看起来像这样的代码吗？ 为此，我们使用带有精确规则包的 OpenGrep。每条规则都与一个公告、报告或审查发现相关联。基线目标是回归检测：如果同样的易受攻击形态再次出现，CI 会在审查之前捕获它。更好的目标是变体检测：捕获同一错误的近似版本。 精确性至关重要。一条嘈杂的规则比没有规则更糟，因为它会让团队忽略这个渠道。 目前，检入的精确 OpenGrep 规则包有 148 条规则。它在 PR diff 上运行，完整扫描可以手动执行。新修补的公告成为新规则的候选。 终端输出显示一条 OpenGrep 规则在本地捕获到一个来源于 GHSA 的不安全 safe-bin 配置文件回退模式。一条 OpenGrep 规则在本地捕获了之前由 GHSA 揭示的 bug 形态。CodeQL 与其并行运行，以获得更深层次的语义覆盖。它更慢且维护起来噪声更大；我们两者都用。 ## 这对 OpenClaw 用户意味着什么 OpenClaw 并没有变得更弱。我们正在让边界更容易看清和捍卫。 我们不会承诺零风险的智能体。任何这样承诺的人要么是在推销东西，要么是还没有发布足够多的产品。 我们能承诺的是方向。OpenClaw 可以在保持强大的同时变得更容易防御。这就是我们正在构建的东西。