eBPF 威胁模型
内置的 eBPF 控制
- 使用 eBPF 校验器
- 根据 eBPF 的使用场景，或许可以不用 root 权限
- 如果一个 eBPF 程序尝试写入到任意进程的内存需要在内核中打印 log
推荐设计
- 最小权限原则
- 职责分离原则
- 执行 软件服务链 最佳实践
基于 eBPF 绕过系统调用
系统调用会有额外的开销，但可以基于 eBPF 绕过系统调用
可以看到真正的系统调用只有 3 ns，其他都是系统调用切换的开销
vDSO 提供了一种工具来尽可能的减少系统调用
vDSO（Virtual Dynamic Shared Object）是一种轻量级的共享库机制，主要用于在 Linux 系统上优化系统调用的性能。它允许用户空间的应用程序直接获取某些系统调用的功能，而无需进入内核模式，从而减少了上下文切换的开销。
原理
vDSO 基于以下原理：
- 内存映射：在程序加载时，vDSO 被映射到应用程序的地址空间中。这是一个由内核预先定义的共享对象，包含一些常用的系统调用函数的实现。
- 用户空间执行：通过这种方式，某些系统调用（如获取时间等）可以在用户空间中直接执行，而不需要进入内核模式。例如，获取当前时间的系统调用可以通过 vDSO 中的函数来实现，这样只需访问用户空间的内存而不必切换到内核。
- 动态链接：vDSO 是动态加载的，程序在运行时可以直接链接到该共享对象中的功能，提高了效率。
功能
vDSO 的主要功能包括：
- 提高性能：通过减少上下文切换的次数，vDSO 提高了系统调用的性能，尤其是在频繁需要系统调用的场景下（如高频率需获取时间的应用程序）。
- 提供信息：vDSO 可以提供一些系统信息（如当前时间、时钟速度等），使得应用程序可以更高效地获取这些信息。
- 系统统一性：vDSO 为多个应用程序提供一致的接口，简化了系统调用的实现。
vDSO 的存在大大提高了许多 Linux 应用程序的性能，特别是在高负载或实时性要求较高的场景下。如果你想了解更多关于 vDSO 的具体实现或使用案例，随时告诉我！
如下这些函数都已经经过了 POC 验证
eBPF MAP 批处理 多个操作
什么是 eBPF maps
cilium 如何 操作 hash map
eBPF 校验器的安全评估
-
eBPF 很伟大，是因为这样做比加载一个自定义模块更安全。使用一个 eBPF bug 程序攻击摧毁一个系统是很困难的。
-
而且几乎和原生代码一样快。
-
eBPF 在容器中使用也要同样安全
eBPF 校验器
-
当加载 eBPF 程序时会做静态检查： 比如查看程序的所有分支 确保所有分支都是安全的（包括所有的可能输入），如果发现任何一个分支是被证明是不安全的，拒绝该程序。
-
校验器本身已经算是复杂了，超过2万行
-
校验器bug会导致严重的安全性威胁：比如容器逃逸，LPE等
Container escape（容器逃逸） 是一种安全漏洞，允许攻击者从容器环境中突破限制，获得对宿主机（主机操作系统）的控制权。简单来说，容器逃逸意味着攻击者能够在容器内执行代码，从而获取到宿主机的文件系统、网络设置、进程列表甚至是系统权限。
容器逃逸的原理
容器化技术（如 Docker、Kubernetes）通常使用操作系统内核的隔离特性来限制进程的权限和访问范围。这包括：
- 命名空间（Namespaces） ：隔离进程、网络、用户、文件系统等。
- 控制组（cgroups） ：限制进程使用的资源（如 CPU、内存等）。
- 能力（Capabilities） ：限制进程的特权功能。
但是，当这些特性不当配置或者存在漏洞时，攻击者有可能利用它们进行容器逃逸。
容器逃逸的示例
- 内核漏洞：利用内核中的安全漏洞（例如，CVE漏洞）可以使攻击者获取到内核特权，从而逃逸到宿主机。
- 配置错误：容器的配置如果不当，例如使用了
privileged模式，允许容器获得宿主机的所有权限，这会显著增加容器逃逸的风险。 - 过度信任容器：如果容器中的应用程序运行在过于广泛的权限下（如 root 用户），攻击者可能会利用这些权限来越权操作。
防范容器逃逸的方法
- 最小权限原则：容器应以最低的权限运行，避免使用 root 用户。
- 限制使用特权模式：避免使用
--privileged标志运行容器。 - 使用安全框架：例如 SELinux、AppArmor、Seccomp 等，提供额外的安全隔离。
- 定期更新和打补丁：确保容器和宿主机的操作系统保持最新，以修补已知的安全漏洞。
- 监控和审计：使用监控工具检测异常活动，提高安全检测能力。
安全具体指什么？
之前的工作：
- 安全调查：verifier.c 出现过超过 40 个 CVE
- 只是孤立的部分的校验
- 动态测试以及模糊测试
现有方法： 基于手册的源代码 review
- 应用我们在漏洞开发以及脆弱性调研的经验
- 学术研究的经验
- 之前的校验器 bug 分析
- 鉴别并且文本化：校验器必须证明的不变量
面向安全的内核扩展能力
eBPF 缺少运行时 内存安全
eBPF 校验器不稳定： 单独静态分析不能保证运行时安全
safe bpf 是一个 eBPF 程序的动态沙箱： 包括错误隔离，硬件辅助内存标记，进而强化运行时空间内存安全。
所有内存访问总是能落到 eBPF 沙箱内
基于 ARM MTE 进行 内存标记
安全沙箱的效果：
- 阻止了 7 次 高严重性威胁
- 在 webserver macrobenchmarks 导致 0-4% 的额外开销
该项目将提供于：
从 buzz 中得到的教训
该项目的作用是为了找到 ebpf 的 校验器的 逻辑上的脆弱性，该项目不面向：找到内存相关 bug
提供了一个工具便于在 eBPF 字节码级别写代码
为什么有这样一个项目？
校验器比较复杂，超过 2 万代码
校验器的目的有复杂性：
- 跟踪 bfp 程序每一个可能分支的状态
- 跟踪 helper 方法， kfuncs 等
- 证明程序是安全的 这本身就是很难的
提供另外一种方式以便和 eBPF 在 bytecode 层次进行交互
为什么选择这个这项目？
校验器存在一个 bug 表示 在内核中存在一个潜在的分支可以用于代码执行
已经学到的教训
未来的研究方向：
