看板卡片级 Agent 的 OS 层沙箱机制：cgroup、seccomp 与命名空间隔离的工程实现

KanBots 将看板卡片与 AI Agent 绑定，每张卡片对应一个独立的 Git Worktree，Agent 在各自的代码空间内并行执行开发任务。这种架构下，每个 Agent 都是一个潜在的代码执行环境，可能编译运行不受信任的代码、访问网络资源或生成子进程。因此，OS 层沙箱不再是可选的安全增强，而是支撑多租户并行执行的基础设施。

沙箱设计目标与威胁模型

卡片级 Agent 的沙箱需要解决三类风险：资源耗尽（某个 Agent 占用全部 CPU 或内存导致系统级联故障）、权限逃逸（Agent 通过系统调用获取宿主机 root 权限）、以及数据泄露（Agent 访问其他卡片的工作目录或敏感文件）。针对这些风险，沙箱设计遵循 "最小权限原则" 与 "纵深防御" 理念，通过多层机制叠加形成有效隔离。

第一层：cgroup v2 资源配额

cgroup v2 是 Linux 内核提供的资源控制机制，可为每个 Agent 进程组设置硬性上限。对于 KanBots 场景，建议为每张卡片创建独立的 cgroup 层级：

/sys/fs/cgroup/kanbots/card-123/
├── cpu.max: "50000 100000"    # 50% CPU 时间片
├── memory.max: 1G              # 内存硬上限
├── pids.max: 32                # 进程数限制
└── io.max: "259:0 rbps=104857600"  # 磁盘 I/O 限速 100MB/s

关键参数配置建议：CPU 使用 cpu.max 而非 cpu.weight，避免权重竞争导致的资源饥饿；内存设置 memory.high 作为软限制提前触发回收，配合 memory.max 硬上限防止 OOM 波及宿主机；进程数限制应包含 Agent 本身及其可能生成的编译器、测试进程。当 Agent 触及资源上限时，cgroup 直接返回 ENOMEM 或冻结进程，无需外部监控介入。

第二层：seccomp 系统调用过滤

seccomp 通过 BPF 程序在系统调用入口点进行过滤，可阻断危险操作。Docker 默认 seccomp 配置已屏蔽 44 个高危系统调用，但 Agent 场景需要更严格的定制策略。

建议阻断的系统调用类别包括：

• 特权提升类：ptrace、keyctl、perf_event_open
• 命名空间逃逸类：mount、unshare、setns、pivot_root
• 内核操作类：kexec_load、bpf、open_by_handle_at

对于需要编译代码的 Agent，需放行 execve、fork、clone，但应通过参数过滤阻断带有 CLONE_NEWUSER 或 CLONE_NEWNET 标志的调用。seccomp 策略应以 JSON 配置文件形式管理，通过 seccomp_export_bpf 生成 BPF 字节码后加载。需要注意的是，seccomp 是防御纵深的一部分，不能作为唯一安全边界。

第三层：命名空间与文件系统隔离

KanBots 已为每张卡片提供独立的 Git Worktree，但 OS 层仍需额外的隔离加固。

PID 命名空间：Agent 运行在新的 PID namespace 中，使其无法看到宿主机进程树，也无法向外部进程发送信号。这对于防止 Agent 误杀或恶意终止其他卡片进程至关重要。

网络命名空间：根据任务类型配置网络隔离级别。纯代码生成任务可使用 --network none 完全断网；需要访问 API 的任务可配置为仅允许出站 HTTPS，通过 iptables 或 nftables 在 namespace 出口处过滤。

文件系统挂载：采用只读挂载策略，将系统目录（/usr、/lib）以 ro 模式绑定，仅开放 /tmp 和卡片工作目录为可写。对于需要临时编译的场景，可使用 tmpfs 挂载隔离的构建目录，任务结束后自动清理。

第四层：Linux Capabilities 降权

容器默认启用的 14 项 capabilities 对 Agent 而言大多冗余。建议采用 "全弃用 + 白名单" 策略：

docker run --cap-drop ALL \
  --cap-add CHOWN \
  --cap-add SETGID \
  --cap-add SETUID \
  --cap-add KILL \
  kanbots-agent

特别注意避免授予 SYS_ADMIN、SYS_PTRACE、SYS_MODULE 等高权限 capability。SYS_ADMIN 单独即可执行 mount、swapon 等敏感操作，是容器逃逸的高危入口。

进程级沙箱替代方案

对于不想引入容器运行时开销的场景，可参考 Sandlock 的纯进程级沙箱方案。该方案结合 Landlock（文件系统访问控制）、seccomp-bpf（系统调用过滤）和 seccomp user notification（动态策略执行），无需创建容器即可实现等效隔离。

进程级沙箱的优势在于 Copy-on-Write 内存共享：Agent 父进程加载的模型权重和依赖库可通过 fork() 共享给子进程，避免每个沙箱独立加载造成的内存膨胀。实测显示，加载 2GB 模型的场景下，10000 个进程级沙箱的总内存占用仍为 2GB，而容器方案需要 20TB。

监控与告警配置

沙箱的有效性依赖持续监控。建议配置以下指标：

• 资源使用率：每张卡片的 CPU、内存、磁盘 I/O 实时用量，触及 80% 阈值时预警
• 系统调用审计：通过 auditd 或 sysdig 记录被 seccomp 拦截的调用，识别潜在攻击模式
• 逃逸检测：监控宿主机上是否出现来自 Agent namespace 的异常进程或网络连接

告警阈值应保守设置，宁可误报也不漏报。对于触及资源上限的 Agent，自动触发优雅终止并归档日志，避免影响同主机的其他卡片。

总结

KanBots 卡片级 Agent 的 OS 层沙箱是一个多层叠加的工程问题。cgroup 提供资源硬边界，seccomp 缩减内核攻击面，命名空间实现进程与网络隔离，capabilities 降权消除特权滥用路径。四层机制相互配合，形成纵深防御体系。对于追求极致性能的场景，进程级沙箱（Landlock + seccomp）可作为容器方案的轻量替代，在保持隔离强度的同时降低资源开销。

资料来源

• KanBots 官方文档与架构说明
• Sandlock 项目技术博客："Processes Are All You Need for AI Sandboxing"
• Red Hat Enterprise Linux Container Security Guide: Linux Capabilities and Seccomp

systems