优势比 ptrace 性能好比驱动通用性好无需逐一编译适配缺陷极其容易被 汇编、go、rust、musl 等静态编译方式的直接与内核交互的程序绕过由于是作为被监控者的依赖库被调用线程间、进程间(fd)临界资源问题比较严重印象里好像还与原生的安全机制有冲突例如 seccomp、snap 容器化对于刻意使用 dl 系列函数加载符号的程序难以适用ptraceptrace 就是我们平时使用的 strace、gdb 的底层核心接口。当时我觉得既然 strace 可以追踪系统调用、 gdb 调试过程中又可以阻塞应用那么 ptrace 肯定可以追踪并挂起即将执行的系统调用。事实证明我觉得没错但是优势无法被汇编、静态编译绕过比驱动通用性好无需逐一编译适配缺陷性能太差 ptrace 设计之初就是给调试用的难以并发要获取系统调用参数只能8字节8字节的从寄存器往外取进一步拖慢了性能容易被反侦察当目标被追踪 /proc 目录中目标进程信息会有被调试的标识fanotify这其实是我最后发现的一种监控方式支持简单的文件访问控制。如果不追求极致的安全笔者十分建议采用这种方式。由于笔者没有深入的使用以下仅是个人推断。优势无法被汇编、静态编译绕过可以配合 /proc 目录中的信息扩展访问控制能力比驱动通用性好无需逐一编译适配缺陷若扩展能力则需要频繁的与 /proc/ 目录交互会有些性能损失访问控制能力有限导致提供的安全能力受限内核层eBPF关于eBPF前期调研过程中就被我pass了。优势依托于 CO-RE 机制一次编译到处运行原生支持阻断无需暴力阻断缺点需要高版本内核无法面对信创平台已经铺开的3.x、4.x的内核需求只能支持基于规则的阻断、无法睡眠也无法把数据推往杀毒引擎扫描后再决定放行与否kprobe这如果不在异常/中断上下文就好了。优势任意符号位置基本都可插入hook缺陷非正常的进程上下文禁止睡眠、挂起甚至仅仅是通过copy_from_user取用户层参数触发缺页引发了挂起都不允许需要采集驱动构建套件进行编译适配lsm这也被 pass 掉了原因是收集了一些系统平台去做编译测试部分信创系统唯独缺少关于lsm的编译环境和条件导致编译不通过由于未深度使用以下优缺点仅仅是个人推断。优势由于在更底层不会出现Double Fetch的问题处于进程上下文可以和应用层安全服务阻塞式交互缺陷部分场景可能拿不到业务层需要的全部数据需要配合读取 /proc 目录中的信息进行完善需要采集驱动构建套件进行编译适配FTrace这是个好方法但是唯独架构支持不全。优势处于进程上下文可以和应用层安全服务阻塞式交互缺陷测试了很多 arm64 的信创系统全都不被支持如果 Hook 点太浅容易被Double Fetch需要采集驱动构建套件进行编译适配LivePatch这有点杀鸡用牛刀了。优势可以插在任意位置和地址只要你认为这安全缺陷需要有一定的对应架构的汇编能力毕竟不是内核原生框架需要防御性编程需要采集驱动构建套件进行编译适配tracepoint这个很赞。优势处于进程上下文如果没有防御手段一样会被Double Fetch支持所有架构x64、arm64、mips64el、loongarch64、sw_64缺陷个别系统监控不到事件还没抽出时间调研需要采集驱动构建套件进行编译适配syscall_table差点把它忘了。优势处于进程上下文如果没有防御手段一样会被Double Fetch不需要复杂的寄存器解嵌套、读取操作支持所有架构缺陷在内核引入地址随机化KASLR之后无法再使用需要采集驱动构建套件进行编译适配