【Falco】对照替代路径：Tetragon、auditd 与 seccomp

前 13 篇把一次检测事件从双引擎驱动讲到五轴排障。接下来的问题不是「Falco 功能全不全」，而是：什么时候用户态规则路径的税不值得付——需要内核选择器与 Override、合规目标就是主机 audit 账本、或 seccomp 白名单已经卡住 syscall 编号。

本文不做 CPU 或内存排行榜。跨方案开销比较需要固定内核、规则规模、是否开强制执行、导出是否全量；单个百分比是口径欺骗。站内 linux/ebpf-security 对照表里的资源占用数字本系列不引用。这里只钉机制分歧：过滤在哪发生，阻断能不能跟这次内核操作同一条路径。Tetragon TracingPolicy / Override 不重写——机制结论外链 Tetragon 第 10 篇 与 第 14 篇。

本篇在系列中的位置

篇目	核心内容
第 13 篇 · 排障坐标系	按五轴归因
第 14 篇 · 对照替代路径	Tetragon / auditd / seccomp
第 15 篇 · 响应与生态边界	告警下游接到哪
系列目录	全部篇目

版本锚定：Falco 0.44.1（源码 tag 0.44.1）。对照结论是机制判断。Tetragon 站内钉 v1.7.0；auditd / seccomp 随发行说明。CVE-2022-26316 钉的是 Falco 低于 0.31.1 的检查窗口，不是「今日 0.44.1 仍未修」，也不是「必须弃用 Falco」。

一、对照 Tetragon：内核选择器与 Override / Signal

Tetragon 的 TracingPolicy 选择器默认在 BPF 程序内匹配；匹配后可以 Post、Override 或 Signal（强制执行）。Falco 官方把内核事件源称为 driver（0.44.1 仅 modern_ebpf ∥ kmod）：libscap 采集，libsinsp 富化，规则引擎在用户态求值（Kernel Events / Kernel Events Architecture）。

这不是「谁也用了 eBPF」的同义词。eBPF 在 Falco 里首先是把 syscall 上下文送出内核的驱动；在 Tetragon 里首先是策略判定与可选强制执行的挂载点。Falco 赢在的前提：规则库、插件源、告警下游响应流程已存在，且威胁模型不要求「这一次」内核操作不执行。Tetragon 赢在的前提：要与 Kubernetes CRD 同一控制面做上下文策略，并在内核能力允许时做 inline Override——并接受五轴运维税（Tetragon 选型）。

对照时还要分清观测完备性与强制执行语义。Falco 规则命中证明的是「用户态引擎在已富化字段上认为条件为真」；Tetragon Override 证明的是「在具备 error injection 的 hook 上，这次函数调用可以不执行」。把前者写成后者，会在事故复盘里假装「调用没发生」。反过来，把 Tetragon 仅观测模式当成「已经比 Falco 多一层强制执行」，同样是口号替换机制。

同一节点上两者可以并存，版本正交（本系列钉 Falco 0.44.1，Tetragon 系列钉 v1.7.0）。并存时排障必须先点名轴：无 Falco 告警先走本系列五轴；无 process_exec 或 Override 未生效走 Tetragon 五轴。联合 runbook 仍开放（第 16 篇），本文不编造「告警与 exec_id 已自动 join」。

机制差表与「过滤位置 × 能否 inline」见第五节；Override / Signal 保证边界以 Tetragon 第 10、13 篇为准，本篇不复述 error injection 与 SIGKILL 副作用。Tetragon 侧更完整的 Falco 对照段见其第 14 篇——两边口径应对齐，不互相改写对方版本钉。

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

Linux Audit（auditd(8)、audit.rules(7)、内核 CONFIG_AUDIT / CONFIG_AUDITSYSCALL）把选定 syscall 与文件监视编成记录，经 netlink 送给用户态 auditd。它解决的是可审计留存与合规证明，不是 Falco 规则命中后的响应编排，也不是 Tetragon 式 Override。

auditd 赢在的前提：合规要的是主机 syscall 账本，编制已有 audit 规则与 SIEM 解析器。Falco 赢在的前提：要按规则语言表达「可疑行为」并接到响应流程，而不是证明「某条 audit 记录已落盘」。不要把 audit 的「exit 记录」读成「调用被拒绝」。

工程上常见的混用失败是：合规审计员要的是不可抵赖的主机账本格式，安全运营却只把 Falco 告警截图贴进报告。两者字段集合、时间戳语义、丢记录模式都不同——audit backlog 满与 Falco drop 指标不是同一证据包。需要账本时走 auditd；需要行为规则与响应编排时走 Falco；需要 inline 阻断时走 Tetragon。三选一不是品牌偏好，是证明义务不同。

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

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

与 Falco 的分工是：seccomp 先收窄「允许发出哪些 syscall」；Falco 再在仍被允许的调用上按路径、套接字、进程树等富化字段做规则检测。 更深的 cBPF vs eBPF VM 差异见 ebpf/。seccomp 赢在的前提：发行版/运行时默认 profile 已够，威胁模型是「多余 syscall 不要存在」。Falco 赢在的前提：攻击者已经在白名单 syscall 里做文章，需要对象级上下文告警。

排除树上「不跑 Falco」不等于关掉 seccomp。容器基线仍应保留运行时 profile；Falco 叶判负只说明「用户态规则检测税当前不值得付」，不说明「syscall 面可以任意放大」。把 seccomp 与 Falco 写成互斥套餐，是采购话术，不是机制。

四、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 级工业反例，验证的是 Garfinkel（NDSS 2003）指出的 argument race：监视器读到的用户内存，不必等于内核稍后真正使用的那一份。0.31.1 之后修补了公告里那类「退出时再读用户缓冲」窗口；本系列钉的 0.44.1 远在修复线之上。 机制问题并没有从操作系统里消失——任何仍在用户态解析 argv/sockaddr 的路径，都要重新回答「检查与使用是否同一副本」。

正确用法：把 CVE 写进威胁模型与「用户态规则 vs 内核 selector」争论的证据栏。错误用法：把它写成「必须弃用 Falco、全体换内核策略机」的充分条件，或暗示 0.44.1 仍暴露同一未修窗口。Tetragon 第 14、16 篇对同一 CVE 的口径与本篇一致。

对仍停留在远低于 0.31.1 的集群，正确动作是升级到已修复线并核驱动成对，而不是把历史 advisory 当成永远有效的弃用判决。对本系列读者：若威胁模型要求「检查与内核使用同一参数副本，且必要时让调用不执行」，排除树应在「需要 Override」叶离开 Falco，而不是在规则 YAML 里叠加更多异常来假装窗口消失。

五、机制差：过滤位置 × 能否 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"]
  tet --> ov["Override or Signal"]
  fal --> alert["Alert after enrich"]
  aud --> log["audit record"]
  sec --> ret["ERRNO or KILL"]

表后必须说清假设。Falco 在 0.31.1 之后修了公告里那类窗口，不等于变成了内核 inline 策略机。Tetragon 有 Override，不等于所有 hook、所有内核都能改返回值。seccomp 拒绝编号，不等于看见了 /etc/shadow 路径字符串。

谱系收成一句：Garfinkel 2003 把系统调用拦截的陷阱写成通用结构 → CVE-2022-26316 是用户态再读缓冲的工业实例 → Falco 0.44.1 仍是「驱动采集 + 用户态规则」；需要 inline 阻断时排除树应指向 Tetragon，而不是在 Falco 规则 YAML 里假装 Override。选型树见第 16 篇。

不做的事：不引用未标定的 CPU% 排行；不重写 TracingPolicy；不把本篇写成 SIEM 接入菜谱（留给第 15 篇边界表）。

参考资料

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

• Falco 0.44.1：Kernel Events、Kernel Events Architecture；falcosecurity/libs（libscap / libsinsp / driver）
• Tetragon v1.7.0：强制执行、对照替代路径
• Linux：auditd(8)、audit.rules(7)；seccomp(2)、struct seccomp_data

论文 / 谱系

• Garfinkel, T. (2003). Traps and Pitfalls. NDSS 2003（尤其 argument races）
• McCanne, S. & Jacobson, V. (1993). The BSD Packet Filter. USENIX Winter ’93

工业反例（B）

• GitHub Advisory GHSA-6v9j-2vm2-ghf7 / CVE-2022-26316（Falco < 0.31.1）

站内对照

• 系列目录
• 第 1 篇 · 全景
• 第 13 篇 · 排障
• 第 16 篇 · 选型收束
• Tetragon 16

上一篇：排障坐标系

下一篇：响应与生态边界