【Falco】对照替代路径：Tetragon、auditd 与 seccomp
内容提要
本文对比Falco、Tetragon、auditd与seccomp四种安全工具，聚焦过滤位置与能否内联阻断。Falco在用户态规则引擎检测，适合告警；Tetragon内核选择器支持Override，可阻断操作；auditd提供合规审计账本；seccomp按syscall编号白名单拒绝。CVE-2022-26316揭示用户态读取参数存在TOCTOU竞态，但0.44.1已修复。选型取决于威胁模型与证明义务，非品牌偏好。
延伸解读
机制差异决定选型，而非品牌偏好
文章强调，Falco、Tetragon、auditd 和 seccomp 的差异在于过滤位置和能否内联阻断，而非品牌。Falco 在用户态规则引擎检测，适合告警；Tetragon 内核选择器支持 Override，可阻断操作；auditd 提供合规审计账本；seccomp 按 syscall 编号白名单拒绝。选型应基于威胁模型和证明义务，例如需要 inline 阻断时选择 Tetragon，需要合规账本时选择 auditd。
CVE-2022-26316 的启示：检查窗口与 TOCTOU
CVE-2022-26316 展示了用户态读取参数存在 TOCTOU 竞态，Falco 低于 0.31.1 受影响，但 0.44.1 已修复。文章提醒，任何仍在用户态解析参数的路径都需重新评估“检查与使用是否同一副本”。该 CVE 应作为威胁模型和争论的证据，而非弃用 Falco 的理由。
seccomp 与 Falco 并非互斥
seccomp 在 syscall 入口按编号白名单拒绝，无法解引用路径；Falco 在用户态按富化字段检测。两者分工明确：seccomp 收窄允许的 syscall 集合，Falco 检测白名单内的可疑行为。文章指出，不跑 Falco 不等于关闭 seccomp，容器基线仍应保留运行时 profile，二者不是互斥套餐。
Q&A
Falco、Tetragon、auditd 和 seccomp 在过滤位置和阻断能力上有什么本质区别？
Falco 在用户态规则引擎检测，主要告警；Tetragon 在内核 BPF 选择器匹配，支持 Override 阻断；auditd 在内核审计通道记录，不阻断；seccomp 在 syscall 入口按编号白名单拒绝。
Tetragon 的 Override 和 Falco 的告警在语义上有什么不同？
Tetragon 的 Override 证明在具备 error injection 的 hook 上，这次函数调用可以不执行；Falco 规则命中只证明用户态引擎在已富化字段上认为条件为真，不能证明调用未发生。
auditd 和 Falco 在合规审计场景下如何选择？
需要不可抵赖的主机 syscall 账本时选 auditd；需要按规则语言表达可疑行为并接入响应流程时选 Falco。两者字段、时间戳、丢记录模式不同，不能混用。
seccomp 和 Falco 在容器安全中如何配合使用？
seccomp 先按 syscall 编号白名单收窄允许的调用集合，Falco 再在允许的调用上按路径、套接字等富化字段做规则检测。两者不互斥，容器基线应保留 seccomp profile。
CVE-2022-26316 是什么？它是否意味着必须弃用 Falco？
CVE-2022-26316 是 Falco 低于 0.31.1 版本在 syscall 退出时从用户态缓冲区读取参数导致的 TOCTOU 竞态，可被绕过。0.31.1 已修复，0.44.1 远在修复线之上，不应作为弃用 Falco 的理由。
在什么情况下应该选择 Tetragon 而不是 Falco？
当威胁模型要求与 Kubernetes CRD 同一控制面做上下文策略，并且需要在内核能力允许时做 inline Override 阻断操作时，应选择 Tetragon。
Falco 0.44.1 的检测机制是怎样的？
Falco 0.44.1 使用 modern_ebpf 或 kmod 作为驱动采集 syscall 上下文，libscap 采集，libsinsp 富化，规则引擎在用户态求值，主路径是告警而非阻断。
