【Tetragon / eBPF】对照替代路径：Falco、auditd、Cilium CNP/Hubble 与 seccomp

前 13 篇把一次运行时安全事件从 exec_id 与 hook 讲到选择器、强制执行与五轴排障。接下来的问题不是「Tetragon 功能全不全」，而是：什么时候内核态 TracingPolicy 的税不值得付——Falco 规则库已经覆盖检测、主机 auditd 已满足合规留存、东西向只需 Cilium NetworkPolicy 与 Hubble、或 seccomp 白名单已经卡住 syscall 编号。

本文不做 CPU 或内存排行榜。跨方案开销比较需要固定内核、规则规模、是否开强制执行、导出是否全量；单个百分比是口径欺骗。站内 linux/ebpf-security 对照表里的 CPU% 与「约 200MB / 150MB」本系列不引用。产品勾选级对照见 observability/15，本篇不重写那一节。这里只钉机制分歧：过滤在哪发生，阻断能不能跟这次内核操作同一条路径。

本篇在系列中的位置

篇目	核心内容
第 13 篇 · 排障坐标系	按五轴归因
第 14 篇 · 对照替代路径	Falco / auditd / CNP·Hubble / seccomp
第 15 篇 · Runtime Hooks	OCI hook 与容器边界
系列目录	全部篇目

版本锚定：Tetragon v1.7.0。对照结论是机制判断。Falco / auditd / seccomp 版本随各自发行说明；CVE-2022-26316 钉的是 Falco 低于 0.31.1 的检查窗口，不是「今日 Falco 仍未修」。

一、对照 Falco：驱动采集，规则在用户态

Falco 官方把内核事件源称为 driver：现代 eBPF probe（文档中的默认路径之一）或内核模块。libscap 从 driver 取 syscall 事件，libsinsp 做状态富化，规则引擎在用户态求值（见 Falco Kernel Events / Kernel Events Architecture 与 falcosecurity/libs 对 libscap/libsinsp 的分工）。Tetragon 的 TracingPolicy 选择器默认在 BPF 程序内匹配，匹配后可以 Post、Override 或 Signal（第 7 篇、第 10 篇）。

这不是「谁也用了 eBPF」的同义词。eBPF 在 Falco 里首先是把 syscall 上下文送出内核的驱动；在 Tetragon 里首先是策略判定与可选强制执行的挂载点。Falco 的规则库、插件源、生态响应流程是它赢的前提；Tetragon 赢在与 Kubernetes CRD 同一控制面、以及（在内核能力允许时）inline Override。

工业反例：GHSA-6v9j-2vm2-ghf7 / CVE-2022-26316

GitHub Advisory GHSA-6v9j-2vm2-ghf7（CVE-2022-26316，2022-03-11，影响 Falco 低于 0.31.1，修复 0.31.1）写明：处理 connect、open、openat、creat 时，Falco 在 syscall 退出时从用户态缓冲区再读部分参数。恶意程序可以拉长这次 syscall，并在调用发出之后、执行完成之前改掉自己地址空间里的缓冲区。Falco 随后把改过的数据当成「这次调用的输入」，规则可能被绕过。公告给出两类具体窗口：慢 TCP 握手的 C2 connect()，以及经 FUSE/SSHFS 等引入额外 IO 延迟的文件名隐藏。内核模块、eBPF probe、用户态 instrumentation 均受影响。

这是 B 级工业反例，不是 Falco 百科，也不是「Falco 不可用」的判决。它验证的是 Garfinkel NDSS 2003 §4.3.3 的 argument race：监视器读到的用户内存，不必等于内核稍后真正使用的那一份。修复版本改变了采集窗口；机制问题并没有从操作系统里消失。任何仍在用户态解析 argv/sockaddr 的工具，都要重新回答「检查与使用是否同一副本」。

Tetragon 把匹配下沉到 kprobe/LSM 等 hook，读的是进入该 hook 时的参数视图，并可用 Override 让函数不执行。这缩小的是「用户态规则引擎 vs 内核已完成的 syscall」这一段，不是 Bishop & Dilger 意义上的全部 TOCTTOU（路径在 check 与 use 之间仍可被并发改写）。官方 TracingPolicy 文档自己警告低层配置会引入 TOCTOU。对照应写成：过滤位置不同，剩余竞态不同，而不是「Tetragon 消灭了竞态」。

二、对照 auditd：内核审计通道，不是 inline 策略机

Linux Audit（auditd(8)、audit.rules(7)、内核 CONFIG_AUDIT / CONFIG_AUDITSYSCALL）把选定 syscall 与文件监视编成记录，经 netlink 送给用户态 auditd。规则可以在内核侧按列表类型（user / exit / exclude 等）过滤，也可以在用户态再筛。它解决的是可审计留存与合规证明，不是 TracingPolicy 那种「匹配则改返回值」。

auditd 赢在的前提：合规要的是主机 syscall 账本，编制已有 audit 规则与 SIEM 解析器，不需要按 Pod 标签 inline 阻断。Tetragon 赢在的前提：要在 hook 上按二进制/参数/K8s 选择器做同一套观测与强制执行，并接受 BTF 与策略运维税。

不要把 audit 的「exit 记录」读成「调用被拒绝」。记录出现只证明审计钩子认为这次调用发生过。

三、对照 Cilium CNP / Hubble：包路径身份，不是进程路径

Cilium NetworkPolicy / CiliumNetworkPolicy 把 selector 蒸馏成 numeric identity，在东西向 eBPF 数据面做 L3/L4（可选 L7）判定；Hubble 导出的是 flow verdict，不是 process_exec。策略编译 钉 NP/CNP → policy map；Hubble 信号 钉 flow 与 metrics 口径；Cilium 选型终章 把 Tetragon 标成运行时安全续作，而不是把 CNP 写成 syscall 强制执行。

只需要「哪些身份可以访问哪些端口」，排除树停在 Cilium 数据面，不必为运行时安全再付 TracingPolicy 税。已经用 Hubble 看清 Policy denied，却拿 Tetragon 去「再确认一次连接」，是把轴用错：包路径的 deny 不会自动长出 exec_id。

两者可以同集群部署，版本正交（本系列钉 Tetragon v1.7.0，Cilium 系列钉 v1.20.0）。联合归因的 runbook 仍是开放问题（第 16 篇），本文不编造「identity 与 exec_id 已自动 join」。

四、对照 seccomp：syscall 编号白名单，不解引用路径

Seccomp-BPF 的输入是 struct seccomp_data：syscall 号、arch、指令指针、原始寄存器参数。经典 BPF 不能把用户态路径指针解引用成字符串。容器运行时在启动时装上 profile 之后，进程能做的调用集合被卡住；SECCOMP_RET_ERRNO / KILL 发生在 syscall 入口，属于 inline 拒绝，但拒绝的依据几乎只有编号与整数参数。

这与 Tetragon 的分工是：seccomp 先收窄「允许发出哪些 syscall」；Tetragon 再在仍被允许的调用上按路径、套接字、能力、血缘做上下文策略。 站内 ebpf-security 用过「Seccomp 看不到 /etc/shadow 路径」这一结构；本篇只保留机制句，不沿用该文未核实的开销表。更深的 cBPF vs eBPF VM 差异见 eBPF 系列。

seccomp 赢在的前提：发行版/运行时默认 profile 已够，威胁模型是「多余 syscall 不要存在」，编制不想维护 TracingPolicy。Tetragon 赢在的前提：攻击者已经在白名单 syscall 里做文章（openat 指向宿主机文件、connect 指向 C2），需要对象级上下文。LSM 谱系（Wright, Cowan, Smalley, Morris, Kroah-Hartman, Linux Security Modules, USENIX Security 2002）把「参数已解析后的对象」定为 hook 点；Tetragon 的 LSM sensor 吃的是这条学术前身，不是「实现了 LSM 框架」。

五、机制差：过滤位置与能否 inline 阻断

flowchart LR
  sc["Syscall or hook"]
  sc --> sec["seccomp cBPF\nnumber and raw args"]
  sc --> aud["audit rules\nrecord path"]
  sc --> fal["Falco driver\nthen userspace rules"]
  sc --> tet["Tetragon in-kernel\nselector"]
  sc --> cnp["Cilium identity\npacket path"]
  tet --> ov["Override or Signal"]
  fal --> alert["Alert after copy"]
  aud --> log["audit record"]
  sec --> ret["ERRNO or KILL"]
  cnp --> drop["Policy drop"]

表后必须说清假设。Falco 在 0.31.1 之后修补了公告里那类「退出时再读用户缓冲」窗口，不等于变成了内核 inline 策略机。Tetragon 有 Override，不等于所有 hook、所有内核都能改返回值。CNP drop 不等于容器内 write() 没做完。

谱系可以收成一句：Bishop & Dilger 1996 定义文件绑定上的 TOCTTOU → Garfinkel 2003 把它写成系统调用拦截工具的通用陷阱（含参数竞态）→ CVE-2022-26316 是用户态再读缓冲的工业实例 → Tetragon 用 in-kernel 匹配与 Override 换一段窗口，仍把 TOCTOU 留在 TracingPolicy 警告里。选型若离开这些名字，讨论退回安装量与品牌口号。

不做的事：不引用未标定的「Tetragon 比 Falco 少百分之几 CPU」；不把 Falco 规则生态写成缺陷；不承诺本站另开 Falco 全书。

参考资料

规范 / 官方文档 / 源码（A）

• Tetragon v1.7.0：docs/content/en/docs/concepts/enforcement/_index.md；tracing-policy/selectors.md（Override 与 CONFIG_BPF_KPROBE_OVERRIDE）；tracing-policy/_index.md（TOCTOU 警告）
• Falco：Kernel Events、Kernel Events Architecture；falcosecurity/libs（libscap / libsinsp / driver 分工）
• Linux：auditd(8)、audit.rules(7)；seccomp(2)、struct seccomp_data
• Cilium 系列：第 7 篇 策略编译、第 8 篇 Hubble、第 16 篇 选型

论文 / 谱系

• Garfinkel, T. (2003). Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools. NDSS 2003. 尤其 §4.3 竞态与 §4.3.3 argument races
• Bishop, M. & Dilger, M. (1996). Checking for Race Conditions in File Accesses. Computing Systems 9(2):131–152
• Wright, C., Cowan, C., Smalley, S., Morris, J. & Kroah-Hartman, G. (2002). Linux Security Modules: General Security Support for the Linux Kernel. USENIX Security 2002
• McCanne, S. & Jacobson, V. (1993). The BSD Packet Filter. USENIX Winter ’93（内核过滤 VM 谱系；实现见 ebpf/，本篇不重写）

工业反例（B）

• GitHub Advisory GHSA-6v9j-2vm2-ghf7 / CVE-2022-26316（Falco 低于 0.31.1；syscall 退出时读用户态缓冲的 TOCTOU 窗口）

站内对照

• 系列目录
• 第 10 篇 · 强制执行
• 第 13 篇 · 排障
• 第 16 篇 · 选型收束
• 网络可观测性 · Hubble / Tetragon 产品对照
• eBPF 安全文（机制可对照；不采用其未核实 CPU/内存数字与「零缺口」表述）

实验台账

• 本篇无跨方案 benchmark；选型依据为过滤位置与阻断语义。

→ 上一篇：排障坐标系 · 下一篇：Runtime Hooks 与容器边界 · 系列目录