关于eBPF安全可观测，我想和你聊聊----PODS 2022大会上的主题分享

和大家分享下8月16号晚，我在PODS 2022大会上关于内核安全方面的一些思考和心得，直播没讲到的内容摘自我博客的其他文章，有些在公众号文章里也有。本次分享将从监控和可观测性、eBPF安全可观测性分析、内核安全可观测性展望三个方面展开。​更多内核安全、eBPF分析和实践文章，请关注博客和公众号:

CSDN博客：内核功守道
公众号： 内核功守道

一、eBPF安全可观测性的前景展望

从下图可以看到，监控只是可观测性的冰山一角，而大部分都隐藏在水面之下的深层次问题无法简单通过监控解决。

监控(Monitoring)vs可观测性(Observability)

目前监控也开始可视化，但绝大部分都是事先预定义参数，然后事后查看日志，进行分析。监控的缺点包括：

• 可扩展性差，需要修改代码和编译；验证周期长；数据来源窄等问题。
• 可观测性是通过主动定制度量的搜集和内核数据聚合，包括以下三种：

Logging

• 实时或者事后特定事件信息
• 分布式服务器集群的海量数据溯源图
• 离散信息整理各种异步信息

Tracing

• 数据源：提供数据来源
• 采集框架：往上对接数据源，采集解析发送数据，往下对用户态提供接口
• 前端交互：对接Tracing内核框架，直接与用户交互，负责采集配置和数据分析

Metrics（度量）

这也是可观测性与监控最主要的区别

系统中某一类信息的统计聚合，比如CPU、内存、网络吞吐、硬盘 I/O、硬盘使用等情况。当度量值触发异常阈值时，系统可以发出告警信息或主动处理，比如杀死或隔离进程；

主要目的：

• 监控（Monitoring）
• 预警（Alert）

总结一下监控和观测的区别：

监控：收集和分析系统数据，查看系统当前的状态，对可预见的问题进行分析处理；

可观测性：通过观察系统并衡量系统的内部状态，从其外部输出的数据推断出来系统此时处于某种程度的度量，特别是我们所关心的场景和事件；

二.eBPF安全可观测性分析

安全：安全指的是某种对象或者对象属性不受威胁的状态。

安全可观测性：

• 通过观测整个系统，从低级别的内核可见性到跟踪文件访问、网络活动或能力（capability）变化，一直到应用层，涵盖了诸如对易受攻击的共享库的函数调用、跟踪进程执行或解析发出的 HTTP 请求。因此这里的安全是整体的概念。
• 提供对各种内核子系统的可观测性，涵盖了命名空间逃逸、Capabilities 和特权升级、文件系统和数据访问、HTTP、DNS、TLS 和 TCP 等协议的网络活动，以及系统调用层的事件，以审计系统调用和跟踪进程执行。
• 从日志、跟踪及度量三个维度检查相关输出，进而来衡量系统内部安全状态的能⼒。

eBPF的安全可观测性表现为对内核来说其存在感极低但观测能力却异常强大（药效好，副作用小）：

• 程序沙箱化：通过eBPF验证器保护内核稳定运行。
• 侵入性低：无须修改内核代码，且无须停止程序运行。
• 透明化：从内核中透明搜集数据，保证企业最重要的数据资产。
• 可配置：Cilium等自定义乃至自动化配置策略，更新灵活性高，过滤条件丰富。
• 快速检测：在内核中直接处理各种事件，不需要回传用户态，使得异常检测方便和快速。

其中的程序沙箱话离不开更安全的eBPF Verifier（其中最重要的是边界检查）：

• 拥有加载eBPF程序的流程所需的特权
• 无crash或其他异常导致系统崩溃的情况
• 程序可以正常结束，无死循环
• 检查内存越界
• 检查寄存器溢出

eBPF的可观测性应用场景主要有以下三类：

1.云原生容器的安全可观测性

随着云网边端的急速发展，人们的目光越发的聚焦在目前最火热的云原生场景上。Falco、Tracee、Tetragon、Datadog-agent、KubeArmor是现阶段云原生场景下比较流行的几款运行时防护方案。

这些方案主要是基于eBPF挂载内核函数并编写过滤策略，在内核层出现异常攻击时触发预置的策略，无需再返回用户层而直接发出告警甚至阻断。

以预防的方式在整个操作系统中执行安全策略，而不是对事件异步地做出反应。除了能够为多个层级的访问控制指定允许列表外，还能够自动检测特权和 Capabilities 升级或命名空间提权（容器逃逸），并自动终止受影响的进程。

安全策略可以通过 Kubernetes（CRD）、JSON API 或 Open Policy Agent（OPA）等系统注入。

2.应用层安全可观测方案

此类解决方案是在应用程序和系统调用层面上执行，并且可观测性方案也各不相同。它们都有一个用户空间代理，这个代理依赖于按定义收集的可观测性数据，然后对其作出反应，且无法对内核级别的事件进行观测。


3.内核层安全可观测方案

此类解决方案是直接在内核层面操作，主要针对运行时增强（runtime enforcement），观测能力较弱（甚至没有观测能力）。内置的内核系统提供了非常多的策略执行选项，但内核在构建时却只重点提供访问控制的能力，而且非常难以扩展，例如内核是无法感知到 Kubernetes 和容器的。虽然内核模块解决了可扩展性问题，但由于其产生的安全风险，在很多场景下往往不是一种明智的选择。

像 LSM-eBPF 这样年轻的内核子系统功能非常强大，也非常有前景，只是需要依赖最新的内核（≥5.7）。

三.内核安全可观测性展望

随着几何倍数增长的智能设备以及高频次的使用，各种的黑客攻击以及数据泄露事情频繁发生，这也让设备安全和信息安全成了绝大多数公司最为关注和人力财力投入的领域。

安全的基座在芯片，芯片的基座在操作系统，操作系统的核心是内核。安全不是单一维度，多层级构建防御矩阵，以及多个角度来解析安全问题，会达到更好的效果。

比如一个简单的内存泄漏问题，前期可能会因为内核泄漏，剩余内存不足导致系统卡顿，此时工程师查找的是Performance性能问题，接下来当系统不能及时回收内存，或者阈值设置不合理，一些进程会被Kill掉，甚至极端情况下，系统会oops或者panic，此时系统展现出来的是Stability稳定性问题。然后如果这个问题触发点很隐蔽，程序发布之前都没有触发而被发现，那后续被黑客利用起来做进一步攻击行为，造成安全漏洞和经济损失，这就是最严重的Security安全问题。

下面从传统内核安全、Android内核安全、KRSI等几个方面展开讨论。

1.传统内核安全方案：

正如Linus Torvalds曾经说过的，大多数安全问题都是bug造成的，而bug又是软件开发过程的一部分，是软件就有bug。

至于是安全还是非安全漏洞bug，内核社区的做法就是尽可能多的测试，找出更多潜在漏洞这样近似于黑名单的做法。

内核代码提交走的流程比较繁琐，应用到具体内核版本上，又存在周期长以及版本适配的问题，所以导致内核在安全方面发展的速度明显慢于其他模块。同时，随着智能化、数字化、云化的飞速发展，全球基于Linux系统的设备数以百亿计，而这些设备的安全保障主要取决于主线内核的安全性和健壮性，当某一内核LTS版本被发有漏洞，这样相关的机器都会面临被攻破利用的局面，损失难以估量。

2.Android内核安全

现如今，世界上越来越多的智能终端包括手机、TV、SmartBox和IoT、汽车、多媒体设备等等，均深度使用Android系统，而Android的底层正是Linux内核，这也让Linux内核的安全性对Android产生重大影响。

由于历史原因，Google在Android内核开源的问题上，理念和Linux内核社区不是十分的匹配，这也导致了Android对内核做了大量的针对性修改，但是无法合入到Upstream上。这也导致了Android内核在安全侧有部分不同于Linux内核，侧重点也存在不同。

在操作系统级别，Android平台不仅提供Linux内核的安全功能，而且还提供安全的进程间通信 (IPC)机制，以便在不同进程中运行的应用之间安全通信。操作系统级别的这些安全功能旨在确保即使是原生代码也要受应用沙盒的限制。无论相应代码是自带应用行为导致的结果，还是利用应用漏洞导致的结果，系统都能防止违规应用危害其他应用、Android 系统或设备本身。

Android内核安全特性：

• HWAddressSanitizer
• KASAN
• Top-byte Ignore
• KCFI
• ShadowCallStack

3.内核安全可观测性利器-KRSI

KRSI (Kernel Runtime Security Instrumentation)的原型通过LSM (Linux security module)形式实现，可以将eBPF program挂载到kernel的security hook（安全挂钩点）上。内核的安全性主要包括两个方面：Signals和Mitigations，这两者密不可分。

• Signals：意味着系统有一些异常活动的迹象、事件
• Mitigations：在检测到异常行为之后所采取的告警或阻断措施

KRSI基于LSM来实现，这也就使其能够进行访问控制策略的决策，但这不是KRSI的工作重心，主要是为了全面监视系统行为，以便检测攻击（最重要的应用场景，但目前主要还是只做检测居多，因为贸然做阻断处理可能会比较危险）。从这种角度来看，KRSI可以说是内核审计机制的扩展，使用eBPF来提供比目前内核审计子系统更高级别的可配置性。

1.KRSI允许适当的特权用户将BPF程序挂载到LSM子系统提供的数百个钩子中的任何一个上面。

2.为了简化这个步骤，KRSI在/sys/kernel/security/bpf下面导出了一个新的文件系统层次结构——每个钩子对应一个文件。

3.可以使用bpf()系统调用将BPF程序(新的BPF_PROG_TYPE_LSM 类型)挂载到这些钩子上，并且可以有多个程序挂载到任何给定的钩子。

4.每当触发一个安全钩子时，将依次调用所有挂载的BPF程序，只要任一BPF程序返回错误状态，那么请求的操作将被拒绝。

5.KRSI能够从函数级别做阻断操作，相比进程具有更细粒度，危险程度也会小得多。

后续计划

• 内核安全问题是个非常复杂的话题，牵一发而动全身，防御机制、加固配置、漏洞利用等等挑战性的技术。在进行加固防御的过程中，又会产生性能或者系统稳定性相关的影响。
• 从eBPF + LSM的角度可以更加可视化、数据丰富的观测内核安全情况，进而在内核Livepatch、漏洞检测以及防御提权相关攻击手段上，有着进一步的发展空间。

内核安全问题，牵一发而动全身，尤其是在运行时安全方面。通过上述eBPF新型program类型，为signals和mitigation提供统一API的策略，并优化内核LSM框架和现有机制容易丢失系统调用的问题，从阻断一个函数调用运行的角度，来实现更细粒度，也更合理的检测方案，同时在内核Livepatch、漏洞检测以及防御提权相关攻击手段上，有着进一步的发展空间。eBPF结合LSM的方案还在持续演进，功能和性能逐渐完善。