【Tetragon / eBPF】对照替代路径：Falco、auditd、Cilium CNP/Hubble 与 seccomp
内容提要
本文对比了Tetragon与Falco、auditd、Cilium CNP/Hubble、seccomp四种安全方案的机制差异，聚焦于过滤位置与能否内联阻断。Falco在用户态解析参数存在TOCTOU竞态风险；auditd仅记录不阻断；CNP处理包路径而非进程；seccomp仅按syscall号过滤。Tetragon在内核hook匹配并支持Override，但仍有竞态窗口。选型需权衡机制与运维成本。
延伸解读
过滤位置决定竞态窗口
Falco 在用户态解析参数存在 TOCTOU 竞态，CVE-2022-26316 是实例；Tetragon 将匹配下沉到内核 hook，缩小了窗口，但官方文档仍警告 TOCTOU。选型时应关注过滤位置与剩余竞态，而非笼统比较 eBPF 使用。
阻断能力差异
seccomp 可内联拒绝 syscall 但仅按编号；auditd 只记录不阻断；CNP 在包路径 drop 但不影响进程 syscall；Tetragon 支持 Override 但需 CONFIG_BPF_KPROBE_OVERRIDE，且 SIGKILL 不保证无副作用。理解各方案阻断语义，避免误用。
选型前提与运维成本
Falco 赢在规则库与生态，auditd 适合合规留存，CNP 适合东西向身份策略，seccomp 适合默认 profile 基线。Tetragon 需运维 BTF 与策略，适合需要对象级上下文和 inline 阻断的场景。权衡机制与运维成本，而非单一性能指标。
Q&A
Falco 和 Tetragon 在事件处理机制上有什么本质区别？
Falco 使用 eBPF 或内核模块作为驱动采集 syscall 事件，然后在用户态通过规则引擎进行解析和匹配，因此存在 TOCTOU 竞态风险。Tetragon 则在内核 hook（如 kprobe、LSM）中直接进行策略匹配，并支持 Override 等内联阻断操作，缩小了竞态窗口。
CVE-2022-26316 是什么？它说明了什么问题？
CVE-2022-26316 是 Falco 低于 0.31.1 版本的一个漏洞，攻击者可以在 syscall 退出时修改用户态缓冲区，导致 Falco 读取到被篡改的参数，从而绕过规则。这验证了系统调用拦截工具中的参数竞态问题（TOCTOU），即监视器读取的用户内存可能不等于内核实际使用的数据。
auditd 和 Tetragon 在功能定位上有何不同？
auditd 是 Linux 内核审计通道，主要用于记录 syscall 和文件访问，生成审计日志以满足合规留存需求，它不能对函数返回值进行 Override 阻断。Tetragon 则是一个运行时安全策略引擎，可以在内核 hook 上根据进程、参数、K8s 标签等执行策略，并支持 Override 或 Signal 进行内联阻断。
Cilium CNP/Hubble 和 Tetragon 分别解决什么问题？
Cilium CNP/Hubble 主要处理网络包路径，基于身份和端口进行 L3/L4（可选 L7）策略，并导出 flow verdict，回答“这条流该不该过”。Tetragon 则关注进程路径，基于 syscall、文件、能力等 hook 参数进行策略判定，回答“这个进程这次操作该不该做完”。
seccomp 和 Tetragon 在过滤机制上有什么不同？
seccomp 在 syscall 入口使用 cBPF 根据 syscall 号和原始参数进行过滤，无法解引用路径字符串，只能按编号白名单拒绝。Tetragon 则可以在内核 hook 上解析路径、套接字等上下文，进行更细粒度的策略匹配，并支持 Override 阻断。
Tetragon 的 Override 功能有什么限制？
Tetragon 的 Override 需要内核配置 CONFIG_BPF_KPROBE_OVERRIDE，并且并非所有 hook 和内核都支持修改返回值。此外，Override 只能让当前函数不执行并返回指定错误，但 SIGKILL 信号不保证当前 syscall 无副作用。
在选择安全方案时，应该考虑哪些因素？
选择安全方案时，需要考虑过滤位置、能否内联阻断、运维成本、规则生态、合规需求等。例如，如果已有 Falco 规则库且检测为主，可继续使用；若需合规留存，auditd 足够；若只需东西向网络策略，CNP/Hubble 即可；若需进程级上下文策略，Tetragon 更合适。
