ants-openclaw-security-audit

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