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 已正确安装或正确启用安全机制。
• 未发现问题，不代表不存在问题；只能代表“在本次检查范围内未发现明显问题”。