Linux 内核 seccomp BPF 系统调用过滤器的深度工程实战：从 cBPF 到 eBPF 的系统调用沙箱生产部署策略

一、架构动机：为什么需要 syscall 沙箱

在生产环境中，一个进程能调用的系统调用数量远多于它实际需要的。一个 Web 服务进程理论上需要 read、write、mmap 等十几个 syscall，但如果它意外调用了 execve、ptrace、mount，就意味着一个远程代码执行漏洞可能直接升级为容器逃逸或主机接管。

seccomp（Secure Computing mode）是 Linux 内核提供的一种安全机制，它通过 BPF（Berkeley Packet Filter）虚拟机来过滤进程可以执行的系统调用。不同于 capabilities 的粗粒度控制，seccomp BPF 可以在 syscall 粒度上进行精确拦截，甚至根据参数值做条件判断。

现代容器生态中，seccomp 是纵深防御的关键一环：Docker 默认的 seccomp profile 禁用约 44 个危险 syscall，containerd 使用类似策略，Kubernetes 从 1.22 开始默认启用 RuntimeDefault seccomp profile。但很多团队对 seccomp 的理解停留在"删减 syscall 列表"的层面，对 BPF 程序的编写与优化缺乏系统认知。

二、seccomp 两层模型：mode 1 vs mode 2

seccomp 经历了两次重大演进：

seccomp-BPF 本质上是在 syscall 入口处嵌入一个 cBPF（classic BPF）程序。当进程发起 syscall 时，内核在执行实际 syscall 之前，先运行 seccomp BPF 程序对 syscall 编号和参数进行检查。

关键数据结构是 struct seccomp_data：

struct seccomp_data {
    int nr;                     /* 系统调用号 */
    __u32 arch;                  /* 架构标识 (AUDIT_ARCH_X86_64 等) */
    __u64 instruction_pointer;   /* 调用时 RIP */
    __u64 args[6];               /* syscall 的 6 个参数 */
};

每个 BPF 指令操作一个 32 位字，通过 BPF_LD | BPF_W | BPF_ABS 从 seccomp_data 的偏移量加载数据。这比 socket filter 的 payload 访问更直接——seccomp 的数据结构是固定布局的。

三、BPF 程序编写：从不允许到精细控制

3.1 最小可工作的 seccomp filter

以下是一个最简单的 seccomp 过滤器，只允许 read、write、exit、exit_group、sigreturn，其余全部返回 SECCOMP_RET_ERRNO | EACCES：

#include <linux/seccomp.h>
#include <linux/filter.h>
#include <linux/audit.h>
#include <sys/prctl.h>
#include <unistd.h>
#include <stddef.h>
#include <stdio.h>
#include <errno.h>

#define ALLOW_SYSCALL(name) \
    BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_##name, 0, 1), \
    BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW)

static void install_seccomp_filter(void) {
    struct sock_filter filter[] = {
        /* 1. 校验架构 — 防止跨架构攻击 */
        BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
                 offsetof(struct seccomp_data, arch)),
        BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, AUDIT_ARCH_X86_64, 1, 0),
        BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL_PROCESS),

        /* 2. 加载 syscall 编号 */
        BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
                 offsetof(struct seccomp_data, nr)),

        /* 3. 白名单 */
        ALLOW_SYSCALL(read),
        ALLOW_SYSCALL(write),
        ALLOW_SYSCALL(close),
        ALLOW_SYSCALL(brk),
        ALLOW_SYSCALL(mmap),
        ALLOW_SYSCALL(munmap),
        ALLOW_SYSCALL(futex),
        ALLOW_SYSCALL(rt_sigreturn),
        ALLOW_SYSCALL(exit_group),
        ALLOW_SYSCALL(exit),
        ALLOW_SYSCALL(rt_sigaction),
        ALLOW_SYSCALL(sigaltstack),
        ALLOW_SYSCALL(arch_prctl),

        /* 4. 默认拒绝 */
        BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | (EACCES & 0xffff)),
    };

    struct sock_fprog bpf = {
        .len = sizeof(filter) / sizeof(filter[0]),
        .filter = filter,
    };

    /* 设置 no_new_privs — 否则非 root 用户无法设置 seccomp */
    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) < 0) {
        perror("prctl(PR_SET_NO_NEW_PRIVS)");
        _exit(1);
    }

    if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &bpf) < 0) {
        perror("prctl(PR_SET_SECCOMP)");
        _exit(1);
    }
}

这段代码中有一个极其重要但容易被忽略的细节：必须先调用 arch 校验。在 x86_64 系统上，32 位进程可以通过 int 0x80 或 sysenter 发起 syscall，使用不同的 syscall 编号体系。攻击者可以通过切换到 32 位模式来绕过针对 x86_64 syscall 编号编写的过滤器。

3.2 基于参数的精细化控制

单纯按 syscall 编号过滤在很多场景下不够安全。例如，openat 几乎不可避免，但我们可能希望阻止它打开某些敏感路径。虽然 seccomp BPF 只能看到参数值（路径的指针），不能直接解引用字符串，但可以对整数参数做条件判断：

/* 限制 clone 只能创建线程，不能创建进程 */
BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
         offsetof(struct seccomp_data, nr)),
BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_clone, 0, 5),

/* 加载 clone 的第一个参数 (flags) */
BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
         offsetof(struct seccomp_data, args[0])),

/* 如果 CLONE_NEWUSER 被设置 → 拒绝 (容器逃逸的风险点) */
BPF_JUMP(BPF_JMP | BPF_JSET | BPF_K, CLONE_NEWUSER, 0, 1),
BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | (EPERM & 0xffff)),

/* 否则允许 */
BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),

对于需要字符串参数检查的场景，seccomp 单独无法完成。工程上通常配合 Landlock LSM（用户态自主沙箱）或 bpf syscall + trace point（SECCOMP_RET_TRACE + ptrace tracer）来实现。容器运行时 containerd 就是使用 SECCOMP_RET_TRACE 将字符串参数解析交给用户态的 OCI hook 处理。

四、seccomp 返回值的工程语义

seccomp BPF 程序通过 SECCOMP_RET_* 动作决定如何处理当前 syscall：

工程选择策略：

• 高安全等级（如密码服务、密钥代理）：用 KILL_PROCESS，宁可误杀不可放过。
• 标准 Web 服务：用 ERRNO | ENOSYS，让应用收到 "function not implemented" 错误并优雅降级。容器化部署中这比直接杀进程更适合健康检查。
• 开发/灰度阶段：先用 LOG 记录哪些 syscall 会被拦截，运行一段时间收集 baseline，确认无遗漏后再切换到 ERRNO。这叫 seccomp audit mode，是生产部署前的必要步骤。

五、高性能 BPF 编译器：从手写指令到 libseccomp

手写 cBPF 指令容易出错且难以维护。业界成熟的方案是使用 libseccomp（来自 SUSE/resindertools 团队），它提供高层语义到 BPF 的编译。

#include <seccomp.h>

static int build_advanced_filter(void) {
    scmp_filter_ctx ctx;

    /* 默认动作: 允许一切 */
    ctx = seccomp_init(SCMP_ACT_ALLOW);
    if (!ctx) return -1;

    /* 明确禁止危险调用 */
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_execve), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_execveat), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_ptrace), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_mount), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_umount2), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_kexec_load), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_kexec_file_load), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_init_module), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_finit_module), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_delete_module), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_swapon), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_swapoff), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_reboot), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_setns), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_unshare), 0);

    /* clone: 禁止 CLONE_NEWUSER | CLONE_NEWNET 等 namespace 创建 */
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP(sys_clone), 1,
        SCMP_A0(SCMP_CMP_MASKED_EQ, CLONE_NEWUSER, CLONE_NEWUSER));

    /* socket: 仅允许 AF_INET / AF_INET6 */
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_socket), 1,
        SCMP_A0(SCMP_CMP_NE, AF_INET));
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_socket), 1,
        SCMP_A0(SCMP_CMP_NE, AF_INET6));
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EACCES), SCMP(sys_socket), 1,
        SCMP_A0(SCMP_CMP_NE, AF_UNIX));

    /* BPF(x) -> 保留给 seccomp 自身的 syscall */
    /* 不加载 BPF 程序可以阻止攻击者修改 seccomp filter */

    seccomp_load(ctx);
    seccomp_release(ctx);
    return 0;
}

libseccomp 内部会自动优化 BPF 程序，比如将多个相同动作的 rule 合并到同一个 jump table 中。对于 N 个 rule，朴素实现是 O(N) 线性扫描，而 libseccomp 使用树状分支将平均复杂度降至 O(log N)。

性能测试数据（x86_64, 48 rule filter, 1000万 syscall）：

使用 seccomp_attr_set(ctx, SCMP_FLTATR_CTL_OPTIMIZE, 2) 开启 BPF 编译器优化（树化 + 公共子表达式消除），可以获得 30%+ 的性能提升。

六、安全建模：seccomp 在纵深防御中的定位

seccomp 不是零信任架构的替代品，而是内核态的最后一道防线。在现代容器栈中的防御层次：

┌─────────────────────────────────────────┐
│  Layer 7: 应用层 (输入验证、WAF)         │
├─────────────────────────────────────────┤
│  Layer 6: 用户态沙箱 (WASM/Landlock)     │
├─────────────────────────────────────────┤
│  Layer 5: LSM (AppArmor/SELinux)         │
├─────────────────────────────────────────┤
│  Layer 4: 容器隔离 (namespace/cgroup)    │
├─────────────────────────────────────────┤
│  Layer 3: 系统调用沙箱 (seccomp BPF)     │
├─────────────────────────────────────────┤
│  Layer 2: Capabilities (细粒度特权分割)   │
├─────────────────────────────────────────┤
│  Layer 1: 硬件隔离 (VM/TEE/CGA)          │
└─────────────────────────────────────────┘

seccomp 的不可替代性在于：它是唯一能在系统调用入口处做决策的机制。即使攻击者拥有所有 capabilities（包括 CAP_SYS_ADMIN），如果 seccomp 过滤了 mount()，调用依然会被拒绝。这是 capabilities 体系本身无法保证的。

6.1 Known Limit & 绕过面

工程部署中需要清醒认识 seccomp 的盲区：

1. 参数指针解引用：seccomp BPF 不能直接读取用户态字符串指针。需要配合 SECCOMP_RET_TRACE + ptrace 由用户态读取后再注入。

2. 攻击面内 syscall 被滥用：如果允许 process_vm_readv + process_vm_writev，攻击者可以向宿主进程中注入 payload。标准的 Docker profile 已禁用了这两个 syscall。

3. TOCTOU 竞态：seccomp 只检查 syscall 入口时的参数值。如果攻击者使用 syscall（如 write）向 fd 写入文件，随后该文件被替换（symlink swap），seccomp 无法感知。需要配合 Landlock 做 inode 级别的路径锁定。

4. 多线程竞态：Linux 5.10 之前，seccomp filter 安装后无法动态修改家族线程。Linux 6.9+ 引入了 seccomp_unotify 的改进，但仍然存在窗口期。建议 fork 之后再安装 filter。

七、生产级部署检查清单

将 seccomp profile 部署到生产前，按以下步骤验证：

# Step 1: 使用 strace 收集 syscall baseline
strace -f -c -p $(pgrep your_service) 2>&1 | head -50
# 运行至少一个完整业务周期（高峰+低谷）后 Ctrl+C 查看统计

# Step 2: 使用 LLVM-bpftrace 动态追踪未预期 syscall
bpftrace -e 'tracepoint:syscalls:sys_enter_* /pid == $1/ { 
    printf("%s %s\n", comm, probefunc); 
}' $(pgrep your_service)

# Step 3: 使用 SECCOMP_RET_LOG 观察模式部署（不拦截）
# 查看 auditd 日志: ausearch -m seccomp -ts today

# Step 4: 灰度切换为 ERRNO 模式
# 监控应用错误日志中是否有大量 ENOSYS/EACCES

# Step 5: 全量 rollout，设置 KPI 监控
# 关键指标: syscall 被拒次数 (应趋近于 0)

此外推荐使用 oci-seccomp-bpf-hook（Open Container Initiative 的 seccomp hook），它可以将 OCI 规范的 seccomp profile JSON 编译为 BPF 二进制后由 containerd/CRI-O 注入。Kubernetes Pod 的 securityContext.seccompProfile.type: RuntimeDefault 即调用此路径。

八、工程决策框架

何时该使用 seccomp BPF

• 服务代码复杂度高（依赖链广，担心第三方库引入 surprise syscall）
• 容器化部署且使用 rootless mode（namespace 逃逸面需要额外限制）
• 面向不可信输入的服务（Web 网关、文件解析器、反序列化服务）
• 需要满足合规要求（PCI-DSS、HIPAA 中的沙箱化要求）

何时不该使用 seccomp BPF

• 服务需要动态加载插件（无法预知所有 syscall）—— 改用能力降维 + Landlock
• 纯 worker 无外部输入且已用 namespace 隔离 — 过度设计
• 强依赖 seccomp 自身 syscall 的 BPF 监控工具（自引用悖论）

九、总结

seccomp BPF 是 Linux 内核提供的最精进粒度的 syscall 安全控制机制。它用仅约 4KB 的 BPF 程序，在 syscall 入口处完成纳秒级的安全决策。工程实践中，"先 LOG 白名单 + 后 ERRNO 阻断"的渐进式部署策略，比"一次性严格禁用"更安全、更不容易引发生产事故。

与其他安全层（capabilities、LSM、Landlock、namespace）组合使用时，seccomp 是纵深防御中不可或缺的底座。对容器运行时而言，它不是可选项，而是默认启用的安全契约。理解其原理和边界，是每个系统工程师和容器平台维护者的必备技能。