Agent 沙箱逃逸面排查：从 WorkBuddy 身份混淆到容器隔离失效

2600_96011524

0人浏览 · 2026-05-14 19:09:18

2600_96011524 · 2026-05-14 19:09:18 发布

当你的自动化 Agent 在容器内运行时，是否真的如你所想那样安全？近期处理的一起 WorkBuddy 身份混淆事件暴露了沙箱边界的关键漏洞——本文将拆解容器逃逸的常见攻击面，并提供可落地的加固清单。

身份混淆引发的沙箱失效

在调试某企业部署的 WorkBuddy 自动化流程时，我们发现当两个同名员工（分属不同部门）触发相同流程时，Agent 会将操作记录错误归因。根本原因在于容器内运行时未能正确继承宿主机层的用户命名空间隔离，导致：

身份主键冲突：容器内进程看到的 UID 与宿主机实际用户脱钩
审计断层：操作日志中的 whoami 返回容器默认用户而非真实调用者
横向移动风险：通过挂载的 Docker socket 获取宿主机权限

容器沙箱逃逸四大攻击面实测

1. 用户命名空间未隔离

通过 docker run --userns=host 或未配置 /etc/subuid 时，容器内 root 可直接映射到宿主机 root。检测命令：

docker run --rm alpine cat /proc/self/uid_map
# 高危输出示例：0 0 4294967295

加固方案： - 强制启用用户命名空间重映射 - 在 Kubernetes 中设置 runAsNonRoot: true - 使用 PodSecurityPolicy 限制特权容器（K8s 1.25+ 需通过替代方案实现）

2. 敏感挂载点未过滤

常见错误配置包括： - /var/run/docker.sock 挂载（直接获取宿主机 Docker 控制权） - /proc 挂载（利用内核漏洞提权） - 宿主 SSH 密钥目录挂载 - /dev 设备文件未过滤（可能访问物理设备）

动态检测脚本增强版：

import os
from pathlib import Path

DANGEROUS_MOUNTS = [
    '/var/run/docker.sock',
    '/root/.ssh',
    '/proc/sys/kernel/core_pattern',
    '/dev/mem',
    '/dev/kmem'
]

def check_mounts():
    with open('/proc/self/mountinfo') as f:
        for line in f:
            for path in DANGEROUS_MOUNTS:
                if path in line:
                    print(f'[CRITICAL] Dangerous mount detected: {path}')
                    # 新增风险等级评估
                    if 'docker.sock' in path:
                        print('  → 直接导致宿主机权限失控')

3. 镜像供应链污染

通过分析 ClawHub 的依赖解析顺序，发现当同时存在以下情况时可能加载恶意工具： 1. 私有 registry 中存在与公共仓库同名的工具镜像 2. 未明确指定镜像仓库地址 3. 未校验镜像签名 4. 使用 latest 标签而非固定哈希值

增强校验步骤： 1. 使用 cosign verify 验证镜像签名 2. 在 OpenClaw 网关配置强制镜像来源策略 3. 部署 Notary v2 或 Sigstore 进行供应链证明 4. 在 CI/CD 流水线添加 SBOM（软件物料清单）扫描

4. 内核漏洞未修补

即使配置完善的容器也可能因内核漏洞（如 CVE-今年-0492）逃逸。关键检查项： - 宿主机内核版本是否在受影响范围 - unprivileged_userns_clone 是否被错误启用 - seccomp 过滤器是否拦截高危 syscall（如 keyctl） - AppArmor/SELinux 配置文件是否限制容器能力

加固检查清单（按优先级排序）

[ ] 启用用户命名空间隔离并验证 UID 映射
[ ] 审计所有容器挂载点，移除敏感目录
[ ] 部署镜像签名校验与来源白名单
[ ] 更新宿主机内核并配置针对性 seccomp 规则
[ ] 在 OpenClaw 网关层添加操作审计日志（需包含真实用户身份）
[ ] 定期执行容器逃逸渗透测试（推荐使用 CDK 工具包）
[ ] 限制容器网络权限（禁用 CAP_NET_RAW）

从 WorkBuddy 事件看身份传播链

最终我们通过以下改造解决身份混淆问题： - 在容器 init 阶段注入真实的 LDAP 用户信息 - 通过独立的 Unix socket 传递身份令牌（而非依赖环境变量） - 在 ClawBridge 消息总线层添加 X-Real-User 标头校验 - 实现基于 SPIFFE 的工作负载身份认证

这种方案相比传统的容器内用户映射，更能适应企业复杂的组织架构变更。当员工部门调整时，只需更新中央身份库即可自动同步到所有 Agent 运行时环境。