Linux Tetragon 的 eBPF 安全观测与进程执行追踪模板

tetragon 默认不抓 shell 子进程，因其仅监听 execve 系统调用且不追踪 fork/clone；内置命令不触发 execve，fork 出的子进程直接“隐身”。

为什么 tetragon 默认不抓到 shell 启动的子进程？

因为 Tetragon 的默认策略只监听 execve 系统调用，而很多 shell（如 bash、zsh）在执行简单命令时会用 fork+execve，但若命令是内置命令（如 cd、echo），根本不会触发 execve；更关键的是，Tetragon 的 eBPF 探针默认不追踪 fork 或 clone，所以父进程一 fork，子进程就“隐身”了。

实操建议：

• 启用 process-exec + process-fork 双探针：在 Tetragon 配置中显式开启 process_fork 事件采集，否则所有 fork 出的子进程（包括 shell 子 shell、后台作业、nohup 进程）都会漏掉
• 注意内核版本兼容性：process_fork 在 linux 5.14+ 才稳定支持，5.10 LTS 内核需打 backport 补丁或升级内核，否则日志里只有 execve，没有 pid/ppid 关系链
• 避免用 shell_exec 类高阶抽象 API——Tetragon 不解析 shell 语法，它只看系统调用，echo $(date) 这种命令只会记录一个 execve("/bin/sh", ...)，不会展开子命令

tetragon-cli getevents 返回空，但 ps 明明看到进程在跑

不是没发生，是事件被过滤掉了。Tetragon 默认只上报匹配当前加载策略（policy）的事件，且默认策略往往只关注高危行为（如写入 /etc、绑定特权端口），普通 ls、cat 不触发任何规则，自然不输出。

实操建议：

• 临时绕过策略，用 tetragon-cli getevents --output-mode=raw 查原始事件流，确认底层是否真有数据（比如能看到 execve 但没匹配 policy）
• 检查策略中 process.exec.file.path 的匹配逻辑：用 "/bin/*" 比 "/bin/bash" 更容易捕获，但注意 glob 不支持正则，"*sh" 是无效的
• 别忽略 Namespace 隔离：容器内进程的 mount_ns 和 pid_ns ID 在 host 视角下不同，策略里若写了 namespace.pid == 42，得先用 tetragon-cli getnamespaces 确认实际值

如何让 Tetragon 输出完整的命令行参数（argv）而不是只显示二进制路径？

Tetragon 默认只记录 process.exec.file.path（即 argv[0]），不自动采集整个 argv 数组——这是性能权衡：完整 argv 需额外内存拷贝和字符串解析，在高频 exec 场景下开销明显。

实操建议：

• 在策略 YAML 中显式声明 process.exec.args: true，否则 tetragon-cli 永远只显示 "/usr/bin/curl"，看不到后面跟的 URL
• 注意长度截断：eBPF 栈空间有限，args 默认最多取前 64 字节（含空格），超长参数会被截断；可通过编译 Tetragon 时调整 BPF_MAX_ARG_STRLEN 宏，但 >128 字节易触发 verifier 拒绝
• 敏感参数风险：开启 args 后，密码、Token、API key 可能随命令行泄露到日志，生产环境务必配合日志脱敏策略（如用 process.exec.args + 正则过滤）

用 libbpf 加载 Tetragon 的 eBPF 程序失败，报 invalid indirect read from stack

这是典型的 eBPF verifier 报错，不是 Tetragon bug，而是你手动修改了 Tetragon 的 BPF 源码（比如加了自定义字段或调试打印），但没遵守 libbpf 的栈访问规则：eBPF 不允许从栈上读取未初始化或越界的内存，尤其在结构体嵌套或数组访问时极易触发。

实操建议：

• 别直接改 process.bpf.c 里的 Struct process_event 大小——verifier 对栈变量大小极其敏感，加一个 char cmdline[256] 就可能超限；优先用 bpf_probe_read_str() 动态读，而非静态分配大数组
• 验证修改前先跑 make -C bpf clean && make -C bpf，确保生成的 .o 能被 bpftool prog load 成功加载，而不是等 Tetragon 启动时报错
• 用 bpftool prog dump xlated 看反汇编，定位哪条指令触发了 invalid indirect read——通常出现在 *(u32*)(r10 - 128) 这类栈偏移计算错误的地方

真正难的不是写策略，是理解 Tetragon 的事件模型和 eBPF verifier 的边界在哪里。很多人卡在“为什么我加了一行代码就不加载了”，其实问题不在那行代码，而在它改变了栈布局或内存访问模式。