OpenClaw Security Audit

审计本地 openclaw 的安全配置与运行暴露面。用于检查、验证、解释和总结当前机器或沙箱中的 openclaw 相关安全设置，包括代理配置、sandbox 配置、docker 端口暴露、gateway 检查、文件权限、workspace symlink 风险、本地监听端口以及整体本地安全状态。

OpenClaw 本地安全审计

用于检查本地环境中的 OpenClaw 相关安全配置问题，并输出清晰、可执行的审计结论。

核心行为

将本 skill 视为一个面向 OpenClaw 本地部署、sandbox 环境与开发环境的安全审计流程。

触发后，按以下原则执行：

1. 先判断用户要检查的是哪一类 OpenClaw 本地安全问题。
2. 用户只问单一问题时，优先执行最相关的专项检查。
3. 用户要求“整体检查”“安全审计”“风险评估”时，执行完整审计流程。
4. 输出结果时，必须说明：
   • 检查了什么
   • 发现了什么
   • 风险等级
   • 为什么有风险
   • 如何修复
5. 如果某项检查无法完成，比如缺少文件、路径、命令或权限，必须明确说明，不能假设检查通过。
6. 即使没有发现明显问题，也不能直接下结论说“系统安全”，只能说“在本次检查范围内未发现明显问题”。

检查范围

优先使用 skill 内已有的本地检查模块作为审计入口。

配置与策略检查

• audit_openclaw_config：检查 OpenClaw 配置中是否存在不安全默认值、缺失保护项或高风险覆盖设置。
• audit_sandbox_config：检查 sandbox 相关配置是否存在隔离不足、权限过宽或不安全放行。
• audit_proxy：检查代理配置是否存在不安全暴露、缺少访问限制或高风险转发行为。

主机与运行时检查

• check_docker_ports：检查 Docker 暴露端口，识别是否有不必要或高风险的端口绑定。
• scan_ports：检查本地监听端口与意外暴露的网络服务。
• check_gateway：检查 gateway 或网络边界相关设置是否存在安全隐患。
• check_file_permissions：检查敏感文件与目录权限是否过宽。
• check_workspace_symlinks：检查 workspace 中的符号链接是否可能造成越界访问、路径绕过或挂载逃逸风险。

解释与汇总

• live_sandbox_explain：当用户希望把检查结果用更易懂的方式解释清楚时使用。
• openclaw_security_audit：当用户要求做整体安全审计时，优先作为总入口使用。

如何选择检查项

优先选择“最小但足够”的检查路径。

用户问以下问题时，优先做专项检查

• 端口暴露、服务监听问题：scan_ports、check_docker_ports
• 文件访问、目录权限、路径安全问题：check_file_permissions、check_workspace_symlinks
• 代理配置是否安全：audit_proxy
• sandbox 隔离是否安全：audit_sandbox_config
• OpenClaw 主配置是否安全：audit_openclaw_config
• gateway 或网络路径设置问题：check_gateway

用户提出以下类型请求时，执行完整审计

例如：

• “帮我检查本地 openclaw 安全配置”
• “做一次 openclaw 安全审计”
• “看看这套本地 openclaw 部署有没有明显风险”
• “帮我评估 openclaw 的本地安全状态”

完整审计建议按如下顺序进行：

1. openclaw_security_audit
2. audit_openclaw_config
3. audit_sandbox_config
4. audit_proxy
5. check_docker_ports
6. scan_ports
7. check_file_permissions
8. check_workspace_symlinks
9. check_gateway

如果某些检查项在当前环境中明显不适用，或执行条件不足，可以跳过，但必须在报告中注明。

输出格式

除非用户明确要求其他格式，否则默认使用以下结构输出结果。

1. 总结结论

先给出简短总结，说明：

• 当前整体风险印象
• 最重要的 1 到 3 个问题
• 是否建议立即修复

2. 详细发现

每个发现都应包含以下字段：

• 标题
• 检查领域：config / sandbox / proxy / ports / permissions / symlinks / gateway
• 风险等级：critical / high / medium / low / info
• 证据
• 风险说明
• 修复建议

其中：

• 证据 应尽量写明具体配置、路径、权限、监听地址、端口或命令输出
• 风险说明 要解释这个问题为什么会影响 OpenClaw 的本地安全
• 修复建议 要尽量具体，优先给出最小改动方案

3. 已执行检查项

列出：

• 实际执行了哪些检查
• 哪些检查被跳过
• 跳过原因是什么

4. 检查局限

明确说明本次审计的限制，例如：

• 无法读取某些文件
• 当前权限不足
• 某些配置不存在
• 某些结论依赖推断而非直接验证

风险等级判断规则

统一使用以下风险等级：

critical

用于已经明显造成高危暴露、边界失效、未授权访问路径或潜在逃逸面的情况。

例如：

• 敏感服务直接绑定到 0.0.0.0 且无访问控制
• sandbox 可通过符号链接、挂载或路径设计绕过边界
• 敏感配置或密钥文件对非预期用户可读或可写

high

用于显著削弱隔离、增大攻击路径，或让本地服务暴露在高风险状态的情况。

例如：

• 不必要地暴露管理端口或内部端口
• 代理允许高风险转发目标
• sandbox 关键保护被关闭或被过度放宽

medium

用于增加攻击面、削弱加固强度，但通常还需要额外条件才能形成直接利用的情况。

例如：

• 一般配置文件权限过宽
• 本地存在意外监听端口
• gateway 规则不一致或限制不完整

low

用于最佳实践层面的缺口、轻度暴露或影响较小的问题。

info

用于记录性发现或上下文信息，本身不一定构成风险，但有助于理解系统状态。

解释规则

解释问题时要做到：

• 用具体事实说话，不要泛泛而谈
• 明确这是对 OpenClaw 本地运行的什么风险
• 区分“已确认问题”和“可疑迹象”
• 没有证据时不要夸大可利用性

优先使用类似表述：

• “这会增加暴露面，因为……”
• “在……条件下，可能导致……”
• “我可以确认……”
• “我暂时无法验证……”

避免使用类似表述：

• “这一定可以被利用”
• “系统是安全的”
  除非用户只要求了非常有限的检查，且你已经明确说明边界。

修复建议规则

提出修复建议时，遵循以下原则：

1. 优先给出最小且安全的改动方案
2. 优先遵循最小权限原则
3. 非必要服务优先绑定到 127.0.0.1 而不是 0.0.0.0
4. 优先收紧权限，而不是大幅重构
5. 优先移除不必要的端口暴露、symlink、挂载和代理放行
6. 如果某个高风险设置是“业务上有意保留”，要建议补充文档说明和额外防护

与用户沟通的风格

整体风格要求：简洁、专业、具体。

当用户偏非技术时

• 简要解释术语
• 用更直白的方式说明实际影响
• 修复建议尽量操作化

当用户偏技术时

• 尽量保留具体路径、权限位、监听地址、端口和配置项名称
• 不省略关键细节

失败处理

如果某项检查执行失败，必须：

1. 明确是哪一项检查失败
2. 说明失败原因（如果已知）
3. 在可能的情况下继续执行其他检查
4. 在最终报告中标注该项检查缺失带来的覆盖盲区

示例

示例一

用户请求： “帮我检查本地 openclaw 的安全配置”

预期行为：

• 执行完整审计
• 检查 config、sandbox、proxy、ports、permissions、symlinks、gateway
• 输出按风险优先级排序的审计报告

示例二

用户请求： “看一下 docker 端口暴露有没有问题”

预期行为：

• 优先执行 check_docker_ports
• 必要时补充 scan_ports
• 重点报告监听地址、暴露端口和是否存在不必要外部可达

示例三

用户请求： “为什么这个 sandbox 配置不安全”

预期行为：

• 聚焦 audit_sandbox_config
• 明确指出具体不安全配置项
• 用清楚的语言解释风险来源
• 给出更安全的替代方案

重要边界

• 只审计当前本地环境中真实存在、可访问的配置与状态。
• 不得虚构路径、端口、配置值或命令输出。
• 未经验证，不得假设 OpenClaw 已正确安装或正确启用安全机制。
• 未发现问题，不代表不存在问题；只能代表“在本次检查范围内未发现明显问题”。