第27课：OpenClaw｜安全沙箱与权限深度管理

已注销
36 阅读21分钟

正文.png

很多人都认为OpenClaw安全不安全，取决于它的底层大模型有没有“正确拒绝恶意指令”。但真实答卷截然相反——来自山东大学的安全研究团队用47种攻击场景测试OpenClaw的原生防御能力，平均防御率仅17%，严重依赖后端LLM的安全能力且极易受沙箱逃逸攻击。

这意味着一个事实：不要指望模型替你拦住恶意输入，真正的防线在模型之外。

在过去的26节课中，你已经掌握了OpenClaw从单机部署到高级技能开发的全链路能力。但随着Agent从一个个人工具逐渐演变为企业级服务，安全不再是可以“以后再说”的事情。当ClawHub在一季度爆出1184个恶意Skill，约30万用户受到影响时，“恶意Skill投毒”与“隐蔽的提示词注入”已成为真实发生在你我身边的威胁。

安全从来不是“锦上添花”——它是将Agent推向生产环境的先决条件。本节课将从攻击面分析入手，系统拆解OpenClaw的四重安全防线：沙箱隔离的三种模式、技能执行沙箱容器化方案、工具策略的白名单/黑名单机制与执行审批、文件系统访问的路径白名单与安全加固，以及网络访问控制与外部策略限制。然后以高危漏洞CVE-2026-25253的真实复现剖析攻击链路，最后落脚到一份可立即执行的配置基线检查清单，将本节课所有安全知识点贯通为一个企业级的Agent安全准入方案。

27.1 三层沙箱安全机制详解

一句话概括：OpenClaw不是默认安全的。它的安全底座由沙箱隔离、工具策略和提升执行三个独立维度组成——沙箱决定“在哪里跑”，工具策略决定“能跑什么”，提升执行决定“什么能逃出沙箱”，三者联动才能筑起真正可控的防线，缺一不可。

理解OpenClaw的安全设计，首先要回答一个根本性问题：当有人说“OpenClaw不安全”时，他指的是什么？

答案可以从Snyk Labs的安全研究报告的表述中找到：OpenClaw的攻击面非常广，从Gateway控制面板到各类指令的入口都会成为提示词注入的潜在突破口。原因在于OpenClaw作为一个运行在本地、能调用系统工具、能读写文件、能驱动外部服务的AI框架，其具备的操作权限本身就是一把双刃剑。安全分析人士对此毫不讳言：“从安全角度看，这种架构本质上类似于命令与控制（C2）系统。”一个能运行命令、读写文件和调用网络工具的Agent，任何微小的控制流程缺陷都可能演变为严重的安全漏洞。

OpenClaw官方文档对这一风险有准确的表述：“应将其视为带有持久化凭证的不可信代码执行。”安装一个ClawHub技能，本质上就是在你的主机上运行第三方代码。这一设计哲学决定了安全不能再是“事后思考”，而必须在部署之初就作为基础设施的一部分被纳入考量。

三重控制：沙箱、工具策略与提升执行

OpenClaw的安全体系由三个独立但强关联的控制维度构成：

维度配置入口核心作用关键限制
沙箱隔离agents.defaults.sandbox决定工具“在哪里运行”：宿主机或Docker容器无法独立决定工具能否调用，仅改变执行位置
工具策略tools.allow/deny决定工具“是否能被调用”，是硬性拦截开关deny永远优先；allow非空时其余工具默认禁用
提升执行tools.elevated仅针对exec工具的沙箱逃生通道不绕过工具策略——若deny包含exec，提升执行同样无效

理解这三层的职责边界及其依赖关系，是安全配置不踩坑的前提。沙箱隔离改变的是工具运行的网络和文件系统命名空间，并未阻止任何工具被调用；工具策略提供的是决定性拦截——无论模型输出了什么指令，工具策略会先审查“这个工具是否可被调用”；提升执行仅限于exec工具，是沙箱内部需要突破到宿主机运行的受控逃生通道。

沙箱三种模式详解

模式含义适用场景风险
"off"所有工具直接在宿主机上运行仅限开发测试，绝对不能用于生产极高
"non-main"非主会话（群聊、渠道接入）进入沙箱默认可兼顾体验与安全较低
"all"所有会话都在沙箱中运行多用户生产环境，最安全部署复杂

当mode为"off"时，Agent运行在直接继承你的主机用户权限的状态下。一个诱导提示词注入就能让Agent读取~/.ssh/id_rsa并外发数据。

强烈建议生产环境使用"all"模式。如果仍有顾虑，宁可采用"non-main"并搭配严格的工具白名单，而不是关闭沙箱。

Bind Mount审计（bind mounts security check）：容易被忽视的安全缺口

挂载目录到沙箱容器时，默认模式是读写（rw）——这意味着沙箱内的Agent可能会意外修改甚至删除你主机的关键目录。两条黄金法则：

  • 只读挂载优先：对于配置文件和密钥目录，务必使用:ro标记。挂载/etc完全没必要
  • 禁止挂载Docker Socket：/var/run/docker.sock。这无异于把控制宿主机容器的钥匙直接交给Agent，是已经被攻击者成功利用的真正高危配置

27.2 技能执行沙箱的容器化隔离

一句话概括：沙箱不是单一产品，而是从简易Tool Policy到Docker隔离，再到NemoClaw OpenShell企业级容器的递进式生态。能力越强、隔离越彻底，部署复杂度也相应递增，按需而不是盲目升级才是选型的核心。

2026年安全认知的一个重要跃迁是理解了“沙箱是一个谱系”。从个人用户到大型企业，不同安全要求落在不同的隔离层级上。

第一级：工具策略隔离（零成本，最大价值）

最低门槛的“隔离”甚至不涉及容器，仅通过工具策略限制Agent能调用的工具范围。你可以完全禁止exec工具，让Agent除了无法执行系统命令、无法启动浏览器自动化外，其他能力正常运转。这个级别的隔离成本为零，但已经能堵住大部分高危攻击面。

第二级：Docker沙箱（生产标配）

Docker沙箱是目前最通用的生产级隔离方案。OpenClaw官方通过agents.defaults.sandbox.backend: "docker"启用。沙箱中所有工具执行（exec、read、write、edit、apply_patch）都被限制在容器内部。配置示例：agents.defaults.sandbox.mode: "all"，配合workspaceAccess: "ro"实现只读挂载。对大规模部署，每个会话独立容器（scope: "session"）可达到完全的租户隔离。

⚠️ [安全红线]：Docker沙箱存在CVE-2026-27002配置注入漏洞。2026年2月披露，配置不当的Docker选项可能允许容器逃逸或主机数据访问。OpenClaw已在v2026.2.15后阻断危险配置，包括network=host、seccompProfile=unconfined和apparmorProfile=unconfined。

第三级：NemoClaw OpenShell（企业级沙盒）

Nvidia推出的NemoClaw是OpenClaw生态中最引人注目的企业级安全沙盒解决方案。黄仁勋在演讲中将OpenClaw形容为“AI代理的操作系统”，但直接运行OpenClaw意味着主体结构可以发出任意网络请求、存取主机文件系统，并调用任何推理端点。如果没有防护措施，一旦Agent无人监测的运行，安全、成本和合规性风险将不断膨胀。NemoClaw围绕OpenClaw的CLI设计了一个完整的沙盒基础架构。执行NemoClaw时，它会建立OpenShell沙盒环境，并在隔离容器中执行OpenClaw。OpenShell整合了基于策略的隐私和安全防护措施，让用户能够控制OpenClaw的行为和数据处理。

NemoClaw由两个核心组件构成：TypeScript插件和Python蓝图。TypeScript插件解析和验证YAML蓝图并作为子进程运行；生成的沙箱内，来自Agent的推理请求永远不会直接离开沙箱——OpenShell拦截这些请求并将其路由到已配置的推理提供方。

这一设计填补了OpenClaw底层原先欠缺的基础架构层，使其能兼顾高效运作所需的访问权限与企业级的安全合规。

27.3 Tool Policy：Agent工具的硬性防御机制

一句话概括：Agent工具白名单/黑名单由两张网构成——工具配置文件预定义可调用范围，allow/deny在任何自动或手动执行路径之前进行第一道裁决，必须在openclaw.json中显式设置，因为CLI无法配置数组字段。

工具策略“硬阻”模型

工具策略（Tool Policy）是OpenClaw安全框架中最容易被忽视、却最有价值的防线。其设计核心是“硬性阻断优于软性引导”——不依赖大模型的道德判断，在Gateway层就给高危工具关上大门。

一个最容易操作的验证方法是：在生产配置中将高危工具全部加入tools.deny，然后尝试在会话中输入“帮我执行ls -la”——Agent无法调用exec工具，攻击链路在此被彻底切断。

配置层级与合并策略

OpenClaw的工具策略是一个多层级叠加体系。如果开启沙箱，还会额外叠加sandbox.tools.allow/deny。最终生效策略是各层合并的结果。

有一条不可违反的原则在官方文档中反复强调：deny永远优先。这是防疏漏的最后一道硬性屏障。同时，如果allow非空，未明确允许的工具都会被默认禁用。

企业安全视角的配置基线

{
  "tools": {
    "deny": ["exec", "bash", "apply_patch", "WebFetch"],
    "allow": ["read", "write", "edit", "filesystem"],
    "profile": "messaging"
  }
}

如果工具策略配置正确，即使Agent遭遇复杂的间接提示词注入攻击，也无法调用高危命令和网络外连通道。

tools.profile: "messaging"会自动将Agent限制在与通信相关的工具范围内，运行时工具（如shell执行、进程管理）和工作区外的文件系统工具都将被禁止。

⚠️ [安全红线]：如果仅依赖AGENTS.md中的安全红线，而不通过tools.deny硬性禁用高危工具，面对精心构造的提示词注入攻击时几乎毫无防御力。防御不能靠“商量”，必须靠配置。

执行审批（Approval）流程

当Agent需要执行高风险操作时，OpenClaw触发用户确认（Approval）流程。只有策略+允许列表+用户审批三者协同批准，命令才会被允许执行。

# 针对单次审批设置
openclaw approval request "执行数据库迁移" --timeout 60

为了防止授权链路过度暴露，命令应限定执行窗口，超时未决策则拒绝执行。企业环境还可以将Approval与内部工单系统对接，供安全审计链路核查。

27.4 文件系统的访问路径限制

一句话概括：文件隔离措施三连环——工作区隔离限定访问范围，路径白名单指定仅可读写的安全临界区，禁止读取配置文件与密钥文件，最小化权限原则贯穿始终。

工信部国家互联网应急中心联合中国网络空间安全协会发布的《OpenClaw安全使用实践指南》强调了本节的每一个原则。

工作区隔离：从“能读任何文件”到“只能读工作区”

OpenClaw默认的workspaceOnly = false时，Agent可以读取你机器上的任何文件。一个恶意构造的提示词注入可以让Agent读取~/.ssh/id_rsa并外传，攻击链路畅通无阻。

启用的命令是openclaw config set tools.fs.workspaceOnly true。这会彻底将Agent的操作限制在~/.openclaw/workspace/及授权路径内，其他位置完全不可见，是防御凭证窃取最有效的一招。

路径白名单：明确允许访问的目录

CNCERT指南明确建议：仅开放专用工作目录，禁止访问桌面、文档、下载、密码管理器目录。配置方式为在openclaw.json的tools.file.allowedPaths中声明允许访问的路径。

{
  "tools": {
    "file": {
      "allowedPaths": [
        "/home/username/openclaw-workspace",
        "/home/username/Downloads/incoming"
      ],
      "workspaceOnly": true
    }
  }
}

同时必须添加BLOCKED_PATHS禁止读取系统配置与密钥文件，包括~/.openclaw/openclaw.json自身。

禁止以高权限运行

CNCERT指南明确要求：禁止以管理员或超级用户权限运行OpenClaw，创建专用低权限账户，仅授予最小必要目录的读写权限。配置后通过openclaw security audit验证账户权限和路径白名单配置效应。

27.5 网络访问控制与外部请求策略

一句话概括：OpenClaw默认监听127.0.0.1且不暴露端口，这是第一道天然防线——但如果你把它绑定到公网，就必须补上防火墙规则、IP白名单、TLS加密三道关卡，严格执行CNCERT安全指南的基线要求。

默认端口暴露与CNCERT三阶加固

CNCERT指南明确指出OpenClaw默认端口为18789，严禁暴露至公网。

生产环境部署必须完成以下操作：gateway.bind: "127.0.0.1"；禁用Tailscale、WireGuard等隧道的外映射；远程必须通过VPN+验证码的多因子访问；gateway.controlUi.allowInsecureAuth设为false；对接即时通讯软件，仅允许授权人员使用。

对于高安全场景，还可以配合Envoy Proxy构建网络边界，将OpenClaw的Gateway与外部不可信网络隔离，真正的纵深防御做法。

技能的网络访问管控

CNCERT指南建议限制网络访问，仅允许连接到必要的AI服务与API。高危行为包括技能通过curl、wget等网络命令向外发送窃取数据。通过工具策略禁用WebFetch和Bash中的curl/wget命令，可以弥补Agent网络策略的短板。

CNCERT指南中的企业部分还针对云服务商提出额外要求：默认不暴露Gateway至公网、在用户独立VPC内部署、对镜像及控制面实施常态安全扫描。

27.6 CVE-2026-25253漏洞回顾与防御启示

一句话概括：一个CVSS 8.8的远程代码执行漏洞，攻击者仅靠一个恶意链接就能完全接管你的Agent——CVE-2026-25253的深层根源是对URL参数的过度信任，它提醒我们：控制平面的配置入口本身就是高价值的攻击面，必须在网关层强制实施多重认证。

在了解层层防御后，还需要理解为什么即便配置了沙箱、工具策略、路径白名单，攻击者仍然可能绕过所有防线。CVE-2026-25253给出了最直观的答案——攻击者的目标不是绕过工具策略，而是直接攻陷你的控制平面。

漏洞全貌：一键点击即被完全接管

该漏洞CVSS评分8.8（高危），属于典型的“跨域资源传输不当”（CWE-669）。由于系统过度信任URL参数中的网关地址，攻击者可诱导受害者点击恶意链接，实现WebSocket连接劫持并静默窃取高权限身份令牌，进而在受害者机器上执行任意系统命令。

攻击者无须任何点击，只需诱导用户访问一个恶意网页，即可通过WebSocket网关静默窃取认证令牌，完成对本地Agent的完全接管。

受影响版本：2026.1.29以前的所有OpenClaw版本。

深层诱因：便利性以牺牲授权为代价

攻击根源在于URL参数动态覆盖机制。OpenClaw设计允许在URL的查询参数中传递网关地址，支持用户在不同网关间切换。攻击者通过在恶意链接中构造特定的WebSocket地址参数，将Control UI的连接目标指向自己控制的恶意服务器，从而截取所有通信，包括认证令牌的自动交换。

被截取的高权限令牌让攻击者有能力绕过执行侧所有防线，直接向受害者网关发送任意系统命令。

防御措施

CNCERT指南的强制要求包括：禁止将默认端口（18789/19890）暴露到公网；gateway.controlUi.allowInsecureAuth设为false；启用验证码等强认证措施；警惕非官方来源的控制UI访问入口，防止中间人攻击。

加固原则是无论沙箱多么坚固，都要假设控制平面是薄弱环节，在网关层面强制要求所有敏感操作二次认证，建立双重防线。

27.7 安全配置基线检查清单

以下是本课全部实践的汇总，也是你部署OpenClaw进入生产环境之前必须完成的自检表。

一、环境隔离

  • □ 是否在物理隔离的独立环境中部署，不接入校园网/企业核心网
  • □ 是否使用Docker沙箱、虚拟机、容器等隔离技术运行

二、网络边界

  • □ 是否已将默认端口18789/19890绑定至127.0.0.1，未暴露至公网
  • □ 是否已启用防火墙规则，仅开放必要端口
  • □ 是否已配置IP白名单限制可连接IP范围
  • □ 远程访问是否通过VPN并启用验证码等多因子强认证

三、账户与权限

  • □ 是否已创建专用低权限账户（非root/管理员）运行OpenClaw
  • □ 是否已关闭无障碍、屏幕录制等高危权限
  • □ 是否已限定仅开放专用工作目录，禁止访问桌面、文档、下载、密码管理器目录

四、工具与沙箱

  • □ 沙箱模式是否已设置为all或non-main（严禁off）
  • □ workspaceAccess是否已设置为"ro"只读挂载
  • □ 是否已通过tools.deny硬性禁用高危工具（exec、bash、apply_patch）
  • □ 是否已配置tools.file.workspaceOnly: true限制文件访问范围
  • □ 是否已通过tools.deny禁用网络外联工具（curl、wget、WebFetch）

五、控制面安全

  • □ gateway.controlUi.allowInsecureAuth是否已设为false
  • □ DM配对策略是否已设为pairing（验证码）或allowlist（白名单）
  • □ 是否已为网关服务生成唯一高强度的令牌或密码
  • □ 是否已配置gateway.auth.mode: "token"并设置强密码

六、密钥与数据

  • □ 是否已拒绝存储或处理银行卡号、密码、身份证号、密钥等隐私数据
  • □ 敏感凭据是否通过凭证管理系统按需注入，而非明文写入代码或配置文件
  • □ 是否已配置定期轮换关键凭据

七、技能与插件

  • □ 是否仅从可信渠道安装经过签名验证的扩展程序
  • □ 是否已拒绝来源不明、含“自动赚钱”“破解”等黑灰产类技能
  • □ 安装Skill前是否已进行代码审查，尤其检查含npm install、pip等包管理器的技能

八、持续监控

  • □ 是否已定期运行安全审计工具进行常规检查，--deep执行实时网关探测，--fix实施自动加固
  • □ 是否已将持续监控纳入运维流程，包括行为日志、决策输出、资源使用及异常事件记录
  • □ 关键操作日志是否已防篡改保存，并接入SIEM工具集中分析
  • □ 是否已对高危操作设置人工二次确认或多签流程

九、漏洞管理

  • □ 是否已将OpenClaw更新至最新版本，并安装官方安全补丁
  • □ 是否已确认不受CVE-2026-25253、CVE-2026-27002等已知高危漏洞影响
  • □ 是否已持续关注官方安全公告与漏洞通报

27.8 本节小结

本节课将OpenClaw的安全体系拆解为一个从基础设施到应用配置的纵深防守模型：

  • 三层安全防线：沙箱决定执行位置（mode），工具策略决定工具可用性（allow/deny），提升执行决定受限逃生通道（elevated），三者独立且缺一不可——工具策略是硬性阻断的核心，所有高危工具必须列入deny
  • 沙箱谱系：从工具策略到Docker隔离，再到NemoClaw OpenShell企业沙盒，逐级增强——个人开发者用工具策略+Docker已足够，大型企业可参考NemoClaw架构
  • 文件访问：workspaceOnly+路径白名单限定边界，配合最小权限账户，禁止访问关键配置目录
  • 网络隔离：来自CNCERT的三阶加固——防火墙规则+IP白名单+TLS加密，默认端口不暴露公网
  • 安全审计：定期运行openclaw security audit --fix --deep自动加固
  • 系统化风险管理：配套持续监控、审计追踪和漏洞管理流程

安全从来不是一个可选的额外步骤，而是将Agent部署到生产环境时，在配置文件中必须一以贯之的刚性要求。本节课的检查清单可以成为你的OpenClaw上线前的最后一关——严格执行它，你就已经站在了绝大多数部署实例的前列。

下一节课将聚焦敏感信息管理与API密钥保护，把安全防线继续延伸至Webhook的加密签名验证和云密钥托管的最优实践，补全Agent安全建设的最后一块拼图。

27.9 课后习题

1. 配置演练：从零配置安全沙箱

在你的测试环境中创建一个全新的OpenClaw实例，从零开始配置三层安全防线——设置沙箱模式为"non-main"，通过tools.deny禁用高危工具，配置tools.file.workspaceOnly: true。编写一段~/.openclaw/openclaw.json中的安全配置节。用命令openclaw security audit验证配置是否通过基线检查。

2. CVE-2026-25253防御复现

确认当前OpenClaw版本（openclaw --version）。如果版本低于2026.1.29，升级到最新版本。在openclaw.json中配置强令牌认证（gateway.auth.mode: "token"），设置gateway.bind: "127.0.0.1"。验证网关不再信任URL参数中的网关地址覆盖。思考：如果同时开放了18789端口到公网，上述配置还能完全防御该攻击吗？

3. 工具策略测试

将tools.deny配置为包含["exec", "bash"]，重启Gateway后发送指令“请帮我执行ls -la”。观察Agent的响应。然后临时移除exec从deny列表，再次测试同一指令。解释为什么仅靠AGENTS.md中的安全红线无法防御这种恶意指令。

4. 沙箱逃逸案例分析

阅读CVE-2026-27002漏洞详情。在你的环境中检查是否有类似的危险配置（如network=host、seccompProfile=unconfined）。运行openclaw sandbox explain --json命令，分析输出字段中的docker配置参数，自行判断是否存在容器逃逸风险。

5. 安全基线定制

根据你的部署环境和组织安全策略，选择27.7节检查清单中的至少8项进行落地配置。记录配置过程中遇到的常见问题（如路径白名单遗漏导致技能无法读取文件），并调整清单顺序以先验证基础路径再推进高级权限。做配置变更前创建配置备份，并在隔离环境充分测试。

🔗《30节课精通 OpenClaw》系列课程导航

去订阅

第一部分（第1-5课） ：基础认知与入门部署——解决“这是什么、怎么搭建”的问题；

第二部分（第6-10课）：核心原理深度剖析——解决“底层怎么工作”的问题；

第三部分（第11-15课） ：应用场景与平台集成——解决“能用来做什么”的问题；

第四部分（第16-21课） ：技能开发与定制扩展——解决“如何自己扩能力”的问题；

第五部分（第22-26课）：高级特性与性能优化——解决“怎么用得更好”的问题；

第六部分（第27-30课） ：安全、运维与生态进阶——解决“如何安全可靠地规模化”的问题；

avatar
文章
阅读
粉丝