HDUO Lab

深入 Seccomp 白名单陷阱排查：glibc 升级引发的 clone3 拦截与容器无限 CrashLoop 实战

作者：

ningniu

在

某次核心业务重构，开发团队将基础镜像从 CentOS 7 迁移至 Debian 11 后，发布到生产环境的全量 Pod 瞬间陷入 CrashLoopBackOff。业务端一口咬定是 K8S 底层挂载卷权限配置错误，因为 Java 应用日志仅留下一句干瘪的 java.io.IOException: Cannot run program: error=1, Operation not permitted，随后进程崩溃。

最终结论直接抛出：这是一起典型的容器运行时安全策略（Seccomp）误杀事件。新版镜像内置的 glibc >= 2.34 默认启用了 clone3 系统调用，而集群默认下发的自定义 Seccomp 白名单（Profile）严重老化，未包含此 Syscall。内核按照策略配置返回 EPERM（Operation not permitted），导致进程创建直接被拒。

解决方案：在 Seccomp Profile 中补齐 clone3（435）及 faccessat2（439），或在预发环境先将 defaultAction 降级为 SCMP_ACT_LOG 进行系统调用采样。

案发现场：被误导的权限报错

排查过程中，开发拿着 Operation not permitted 的日志找过来，要求运维检查容器的 runAsUser 和 Volume 的 fsGroup。

这是一个非常经典的排查误区。在 Linux 系统中，EPERM 错误码（Error Number 1）不仅代表文件系统权限不足，当进程触发了被内核拦截的动作（如被 Seccomp、AppArmor 或 SELinux 阻断）时，同样会抛出这个错误。

盲目去排查文件系统权限纯粹是浪费时间。容器起不来，且报底层权限错误，直接下钻到 Node 节点看内核审计日志。

执行以下命令：

# 在 Pod 所在宿主机上直接抓取 Seccomp 审计日志
ausearch -m SECCOMP --just-one
# 如果没有 auditd，直接看内核环形缓冲区
dmesg -T | grep -i seccomp

立刻拿到实锤证据：

audit: type=1326 audit(1690000000.123:4567): auid=4294967295 uid=1000 gid=1000 ses=4294967295 subj=unconfined pid=123456 comm="java" exe="/opt/java/bin/java" sig=0 arch=c000003e syscall=435 compat=0 ip=0x7f8a9b123456 code=0x50000

拨云见日：Syscall 435 的身世

看懂上面这行内核日志，是搞容器安全的基操。 核心关注三个字段：

  1. type=1326：标准的安全计算模式（Seccomp）拦截事件。

  2. arch=c000003e：表示当前架构是 x86_64（AUDIT_ARCH_X86_64）。

  3. syscall=435：被拦截的具体系统调用号。

不知道 435 是什么？用 ausyscall 查一下：

$ ausyscall x86_64 435
clone3

为什么仅仅升级了基础镜像，就会突然触发 clone3 拦截？

底层原理在于：在 Linux 5.3 内核中，引入了更具扩展性的 clone3 系统调用来替代传统的 clone/fork/vfork。而从 glibc 2.34 开始，标准库的进程创建封装函数（如 posix_spawn）默认优先尝试调用 clone3。如果在容器内执行了类似 Runtime.getRuntime().exec() 的代码，底层就会触发该系统调用。

当时集群下发的 Seccomp Profile 还是两年前从某个 GitHub 仓库 Copy 下来的“业界最佳实践”。这个陈旧的白名单里只有 clone，压根没有 clone3。

当未在白名单中的 Syscall 被触发时，由于策略的默认行为被设置为 SCMP_ACT_ERRNO：

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": [
    "SCMP_ARCH_X86_64"
  ],
  "syscalls": [ ... ]
}

内核不会杀掉进程（如果是 SCMP_ACT_KILL，应用会直接收到 SIGSYS 信号并 Dump Core，反而好查），而是向调用方返回一个 errno，默认就是 EPERM。这就是业务层看到 Operation not permitted 的直接原因。

治本之策：防御性安全与可观测性

安全加固决不能以牺牲可用性为代价。直接在生产环境强推严苛的 Seccomp 白名单，无异于在高速公路上埋地雷。

正确的修复与落地路径：

  1. 更新 Seccomp 规则：在 syscalls 列表中补齐现代 glibc 常用的系统调用。除了 clone3，通常还需要加上 faccessat2（439）和 statx（332），这几个是基础镜像升级引发血案的常客。
{
  "names": [
    "clone3",
    "faccessat2",
    "statx"
  ],
  "action": "SCMP_ACT_ALLOW"
}

  1. 灰度与审计模式（Audit Mode）： 任何新的 Seccomp 规则上线前，必须先将 defaultAction 设置为 SCMP_ACT_LOG。这样内核只会记录审计日志，而不会真正阻断请求，跑一周后回收日志，确认无误再切回 SCMP_ACT_ERRNO。

  2. 引入 Falco 规则引擎监控： 靠人工看 dmesg 是低效的。应当利用 Falco 这类基于 eBPF 的运行时安全工具，将 Seccomp 和内核事件提取为结构化告警。 编写一段简单的 Falco 规则，专门捕捉异常进程创建：

- rule: Unexpected Syscall Attempt (Seccomp missing)
  desc: Detect processes trying to use modern syscalls blocked by legacy seccomp profiles
  condition: >
    evt.type=syscall and evt.dir=< and evt.rawres=-1 
    and (evt.arg.error=EPERM or evt.arg.error=ENOSYS)
  output: >
    Syscall blocked (user=%user.name pod=%k8s.pod.name container=%container.name syscall=%evt.type)
  priority: WARNING

一旦有被拦截的系统调用，SRE 团队能第一时间收到告警，而不是等业务反馈“我的 Pod 起不来了，存储坏了”。

同类问题速查排查清单

  1. 确认安全组件拦截层级：看到 EPERM / Operation not permitted，首查 dmesg/audit。确认是 Seccomp (Syscall 阻断) 还是 AppArmor/SELinux (MAC 文件/能力阻断)。

  2. 翻译 Syscall 号：拿到 syscall=XXX 后，必须结合 arch 使用 ausyscall 进行转译。不同架构下同一个编号代表的系统调用完全不同。

  3. 查验 glibc/内核版本匹配度：应用基础镜像升级跨度较大时（如 Alpine 3.12 -> 3.16，或 Debian 10 -> 12），大概率会引入新的系统调用封装，需提前审核 Seccomp 白名单。

  4. 抓取 Core Dump 判断：若应用直接闪退且退出码为 159，通常是被触发了 SIGSYS (Bad system call)。这说明 Seccomp 配置成了 SCMP_ACT_KILL，检查 dmesg 即可破案。

更多文章