谁来监控监控者eBPF安全工作组成立运维的超级权限有了新规矩《AI视界——从资讯看技术》专栏 · 第十一期eBPF 让运维看到了内核里的一切。但谁来看管这个“超级权限”本身一个新成立的工作组正在回答这个问题。本系列专栏其他文章欢迎访问AI视界——从资讯看技术我的主页AOwhisky这里有更多运维系统性知识整理和其他有趣内容欢迎与我一起探讨学习~一、一个工作组为什么值得关注2026年7月Linux 基金会宣布成立 eBPF 安全工作组。在科技媒体上这条新闻的版面不大。毕竟没有产品发布没有融资消息也没有宕机事故那么抓眼球。但如果你读过本专栏的第八期应该还记得我们聊过 eBPF——它是 Linux 内核里的“安全沙箱”让运维可以在不修改内核、不重启服务的前提下深入到系统调用级别去做观测和控制。当时我把它叫做运维的“超级权限”。而现在Linux 基金会决定给这个超级权限加上一道正式的“规矩”。上一期我们聊了 Cloudflare 宕机事故结尾提了一个问题谁来监控那些监控系统本身这句不是修辞。eBPF 安全工作组要解决的恰好就是这个命题。二、eBPF 的安全悖论先理清一个概念eBPF 本身是“为了安全而生的”但它也带来了新的安全风险。这听起来矛盾但逻辑是通的。eBPF 为了安全做了什么你可以在系统调用级别设置拦截规则阻止恶意程序访问敏感文件。你可以在网络层实时检测异常流量在 DDoS 攻击到达应用之前就拦下来。你可以追踪每个进程的行为发现异常立刻告警。这些能力传统安全工具要么做不到要么需要在内核里装驱动、重启服务器才能实现。eBPF 把它们变成了“随时加载、随时更新”的动态能力。但 eBPF 本身的风险在哪一个能在内核层运行的程序如果本身是恶意的或者被恶意利用后果会非常严重。举几个真实发生过或安全研究者验证过的风险场景内核资源耗尽一个写得不好的 eBPF 程序可能消耗大量内核内存或 CPU导致整台机器性能下降而且排查起来极其困难。数据窃取eBPF 可以 hook 系统调用理论上能截获任何进程的数据——包括密码、密钥、数据库查询结果。绕过审计如果攻击者先加载一个 eBPF 程序来隐藏自己的行为那现有的用户态审计工具可能完全看不到它。这就是 eBPF 的安全悖论它是最强的监控工具也可以是最隐蔽的攻击通道。三、真实案例eBPF 曾被怎么滥用光讲理论不够有说服力。我们来回顾几个已经公开的案例。案例一2024 年容器逃逸漏洞利用某安全团队演示过一种攻击路径攻击者在容器内获得 root 权限后加载一个 eBPF 程序hook 了宿主机内核的关键函数从而实现了容器逃逸。容器本来是无法看到宿主机进程的但 eBPF 程序运行在内核层不受这个限制。这个演示直接推动了 Linux 6.12 中对 eBPF 程序权限的更细粒度控制。案例二隐蔽挖矿攻击2025 年有安全研究者发现一种新型挖矿恶意软件不再通过修改系统文件来隐藏自己而是加载了一个 eBPF 程序来劫持top、ps等系统工具的读操作。当你执行top看进程列表时eBPF 程序自动过滤掉了挖矿进程让你完全看不到它。传统查杀工具在用户态扫描而这个恶意软件躲在内核态。这是典型的“灯下黑”。案例三审计日志篡改eBPF 可以 hookwrite系统调用。这意味着如果攻击者知道你的审计日志写在哪他可以用 eBPF 程序在写入磁盘之前就修改日志内容。这不是修改文件而是修改内核正在写的数据流。篡改发生在审计工具记录之前日志看起来一切正常。这三件事说明了一个道理eBPF 的能力越强管控它的必要性就越大。它没有原罪但它必须被管。四、安全工作组打算做什么Linux 基金会这次成立的安全工作组核心目标就是为 eBPF 建立一套可落地的安全标准。目前披露的几个工作方向方向一eBPF 程序签名机制和容器镜像签名类似未来的 eBPF 程序在加载之前内核可以校验它的数字签名。只有经过可信来源签名的 eBPF 程序才能被加载进内核。这是一个“白名单”思路。方向二eBPF 程序行为限制目前 eBPF 的权限控制比较粗粒度——要么能加载 eBPF 程序要么不能。工作组正在推进更细粒度的能力控制这个 eBPF 程序可以读取网络数据但不能读取文件系统可以 trace 进程但不能修改数据包。把 root 权限拆成多个小权限按需授予。方向三eBPF 审计自身第八期我们提到Linux 6.12 已经支持对 eBPF 操作的审计——谁加载了 eBPF 程序、加载了什么、什么时候卸载的。工作组计划把这个能力标准化让所有支持 eBPF 的系统默认开启 eBPF 操作的审计日志。方向四eBPF 验证器增强eBPF 有一个“验证器”在程序加载之前做安全检查保证它不会让内核崩溃。安全工作组计划进一步增强验证器的能力比如引入形式化验证技术在程序加载之前就证明它不会无限循环、不会越界访问内存。五、实操查一下你的系统里有哪些 eBPF 程序聊了这么多理论我们回到运维最熟悉的场景——查一查自己负责的服务器。# 查看当前加载的所有 BPF 程序bpftool prog list# 查看每个程序的详细信息ID、类型、加载时间bpftool prog show# 查看某个程序的具体内容替换 X 为程序 IDbpftool prog dump xlatedidX如果输出里有你不认识的 eBPF 程序或者有程序是近期加载的而你不知情——这可能是一个需要排查的信号。不是每个未知的 eBPF 程序都是恶意软件但每个恶意 eBPF 程序都是从“你不认识它”开始的。你还可以用bpftool检查哪些进程加载了 eBPF 程序# 查看 eBPF 程序与进程的关联bpftool prog show--bpffs这个命令会告诉你 eBPF 程序的 pin 路径和关联进程。在生产环境里定期做这个检查可以在“监控者”被篡改之前发现异常。六、运维的下一个技能点管理超级权限第十一期了。从第八期聊 eBPF 的能力到这一期聊 eBPF 的安全边界我们完整地走了一个闭环先学会用再学会管。而这恰好是运维这个职业的核心进化路径。普通运维会用工具能执行命令能配 Nginx。高级运维能设计权限体系能评估工具的风险能在“用”和“管”之间找到平衡点。顶级运维在新技术还没出事故之前就已经搭好了管控框架。eBPF 安全工作组的成立是一个信号。它告诉我们超级权限已经来了但管好这个权限的规则才刚刚开始写。而写规则这件事正是运维价值的最高体现。一期一会 · 本期核心笔记eBPF 是最强的监控工具也是最隐蔽的攻击通道。安全悖论决定了它必须被管理。安全工作组推进四件事程序签名、细粒度权限、自审计、验证器增强。运维的下一个技能点不只是会用 eBPF而是能管理这个“超级权限”的安全边界。这一期我们聊了 eBPF 的安全边界聊的是一个具体技术领域的管控规则。如果把视角拉高一点有一个更普遍的数据值得关注Google 最近发布了一份安全报告说云上 85% 的安全漏洞根本原因不是什么高级攻击而是最基础的配置错误。这个数据和我们聊了十一期的那条主线不谋而合。这是《AI视界——从资讯看技术》的第十一期。我们继续。如果这篇文章让你有所思考欢迎在评论区聊聊你用bpftool查过自己服务器上加载的 eBPF 程序吗有没有发现过不认识的东西— Compiled and Authored by Whisky — July 17 th, 2026