Agent 执行 Shell 命令：Docker 沙箱真的能防住恶意 rm -rf 吗？

2600_96011506

0人浏览 · 2026-05-13 13:57:22

2600_96011506 · 2026-05-13 13:57:22 发布

从一次生产事故说起

某金融科技团队曾部署过一个自动化日志清理 Agent，该 Agent 被授权通过 Shell 命令管理服务器日志。开发者在测试环境完美运行后，直接将其部署到生产环境。结果某天该 Agent 收到一个精心构造的输入，最终执行了 rm -rf /var/log/* /var/lib/docker/，导致关键日志和容器存储数据被清空，事故恢复耗时 8 小时。

这引出了我们今天要讨论的核心问题：当 Agent 需要执行 Shell 命令时，单纯依赖 Docker 沙箱是否能提供足够的安全保障？

Docker 沙箱的安全边界

1. 默认隔离能力

Docker 通过以下机制提供基础隔离： - 命名空间隔离：PID、网络、挂载点等独立 - Control Groups：资源限制 - 只读文件系统：通过 --read-only 参数实现

但关键限制在于： - 默认允许挂载宿主机目录（-v /host/path:/container/path） - CAP_SYS_ADMIN 等危险权限可能被保留 - 用户命名空间未启用时，容器内 root=宿主机 root

2. 对抗 rm -rf 的具体措施

以下是经过生产验证的防御层次（从外到内）：

第一层：命令过滤

def validate_command(cmd):
    banned = ['rm -rf', 'chmod 777', 'dd if=']
    return not any(b in cmd for b in banned)

缺陷：容易被变异写法绕过（如 rm -rf /var/log/$(echo *)）

第二层：文件系统防护

必须挂载时使用 :ro 只读模式
设置 nosuid,nodev,noexec 挂载选项
对 /bin/rm 等关键命令进行 chattr +i 防修改

第三层：Docker 强化配置

FROM alpine

# 启用用户命名空间映射
RUN echo "dockremap:165536:65536" >> /etc/subuid

# 删除危险 capabilities
RUN setcap -r /bin/*

同时需要在宿主机配置：

# /etc/docker/daemon.json
{
  "userns-remap": "dockremap",
  "default-ulimits": {
    "nofile": 1024
  }
}

超越容器：纵深防御体系

1. 必须实现的审计层

命令全文日志：记录原始输入和实际执行的命令
文件操作审计：通过 inotify 或 auditd 监控关键目录
网络出口控制：防止利用 Shell 反弹连接

2. 执行策略矩阵

风险等级	示例命令	处理方式
高危	rm/mv/dd	人工审批
中危	find/tar	限制参数
低危	ls/stat	直接放行

3. 终极方案：Firecracker 微虚拟机

对于金融级场景，推荐使用基于 Firecracker 的方案： 1. 每个 Shell 会话启动一个独立微VM 2. 内存开销 <5MB，启动时间 <125ms 3. 提供真正的内核级隔离

深度防御实践指南

1. 命名空间隔离强化

在 /etc/containerd/config.toml 中配置：

[plugins."io.containerd.grpc.v1.cri".containerd]
  snapshotter = "overlayfs"
  disable_snapshot_annotations = true
  [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime]
    runtime_type = "io.containerd.runc.v2"
    [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime.options]
      SystemdCgroup = true
      NoNewPrivileges = true

2. 能力(Capabilities)裁剪

推荐的最小能力集：

docker run --cap-drop ALL --cap-add CHOWN --cap-add DAC_OVERRIDE --cap-add FOWNER \
           --cap-add FSETID --cap-add KILL --cap-add NET_BIND_SERVICE \
           --cap-add SETGID --cap-add SETUID --cap-add SETPCAP \
           --cap-add NET_RAW --security-opt no-new-privileges my_image

3. 运行时保护

使用 gVisor 等安全容器运行时：

# 安装 gVisor
curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] https://storage.googleapis.com/gvisor/releases release main" | sudo tee /etc/apt/sources.list.d/gvisor.list > /dev/null
sudo apt update && sudo apt install runsc

# 配置 Docker 使用 runsc
sudo runsc install
sudo systemctl restart docker

实践检查清单

部署前必须验证： 1. [ ] 是否启用了用户命名空间（docker info | grep Userns） 2. [ ] 是否删除了 NET_RAW、SYS_ADMIN 等 capabilities 3. [ ] 是否配置了只读根文件系统 4. [ ] 是否有命令审批工作流对接（如 Slack 审批） 5. [ ] 是否记录了完整的命令审计日志 6. [ ] 是否配置了 seccomp 安全配置文件 7. [ ] 是否禁用了容器特权模式 8. [ ] 是否限制了内存和CPU使用量 9. [ ] 是否配置了容器健康检查 10. [ ] 是否设置了容器自动重启策略