许庆伟：龙蜥社区eBPF技术探索SIG组 Maintainer & Linux Kernel Security Researcher。
本文是作者在 PODS 2022 大会上关于内核安全方面的一些思考和心得，本次分享将从监控和可观测性、eBPF 安全可观测性分析、内核安全可观测性展望三个方面展开。
一、eBPF 安全可观测性的前景展望
从下图可以看到，监控只是可观测性的冰山一角，而大部分都隐藏在水面之下的深层次问题无法简单通过监控解决。
监控(Monitoring) vs 可观测性(Observability)
目前监控也开始可视化，但绝大部分都是事先预定义参数，然后事后查看日志，进行分析。监控的缺点包括：
1）可扩展性差，需要修改代码和编译；验证周期长；数据来源窄等问题。
2）可观测性是通过主动定制度量的搜集和内核数据聚合，包括以下三种：
Logging
- 实时或者事后特定事件信息
- 分布式服务器集群的海量数据溯源图
- 离散信息整理各种异步信息
Tracing
- 数据源：提供数据来源
- 采集框架：往上对接数据源，采集解析发送数据，往下对用户态提供接口
- 前端交互：对接 Tracing 内核框架，直接与用户交互，负责采集配置和数据分析
Metrics（度量）
这也是可观测性与监控最主要的区别。系统中某一类信息的统计聚合，比如 CPU、内存、网络吞吐、硬盘 I/O、硬盘使用等情况。当度量值触发异常阈值时，系统可以发出告警信息或主动处理，比如杀死或隔离进程；
主要目的：监控（Monitoring）、预警（Alert）。
总结一下监控和可观测性的区别：
监控：收集和分析系统数据，查看系统当前的状态，对可预见的问题进行分析处理。
可观测性：通过观察系统并衡量系统的内部状态，从其外部输出的数据推断出来系统此时处于某种程度的度量，特别是我们所关心的场景和事件。
二、eBPF 安全可观测性分析
安全：指的是某种对象或者对象属性不受威胁的状态。
安全可观测性：
- 通过观测整个系统，从低级别的内核可见性到跟踪文件访问、网络活动或能力（capability）变化，一直到应用层，涵盖了诸如对易受攻击的共享库的函数调用、跟踪进程执行或解析发出的 HTTP 请求。因此这里的安全是整体的概念。
- 提供对各种内核子系统的可观测性，涵盖了命名空间逃逸、Capabilities 和特权升级、文件系统和数据访问、HTTP、DNS、TLS 和 TCP 等协议的网络活动，以及系统调用层的事件，以审计系统调用和跟踪进程执行。
- 从日志、跟踪及度量三个维度检查相关输出，进而来衡量系统内部安全状态的能⼒。
eBPF 的安全可观测性表现为对内核来说其存在感极低但观测能力却异常强大（药效好，副作用小）：
- 程序沙箱化：通过 eBPF 验证器保护内核稳定运行。
- 侵入性低：无须修改内核代码，且无须停止程序运行。
- 透明化：从内核中透明搜集数据，保证企业最重要的数据资产。
- 可配置：Cilium 等自定义乃至自动化配置策略，更新灵活性高，过滤条件丰富。
- 快速检测：在内核中直接处理各种事件，不需要回传用户态，使得异常检测方便和快速。
其中 eBPF 程序沙箱化，更加离不开安全模式的 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）。
三、内核安全可观测性展望
下面从传统内核安全、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 能够从函数级别做阻断操作，相比进程具有更细粒度，危险程度也会小得多。
4.后续计划
- 内核安全问题是个非常复杂的话题，牵一发而动全身，防御机制、加固配置、漏洞利用等等挑战性的技术。在进行加固防御的过程中，又会产生性能或者系统稳定性相关的影响。
- 从 eBPF + LSM 的角度可以更加可视化、数据丰富的观测内核安全情况，进而在内核 Livepatch、漏洞检测以及防御提权相关攻击手段上，有着进一步的发展空间。
内核安全问题，牵一发而动全身，尤其是在运行时安全方面。通过上述 eBPF 新型 program 类型，为 signals 和 mitigation 提供统一 API 的策略，并优化内核 LSM 框架和现有机制容易丢失系统调用的问题，从阻断一个函数调用运行的角度，来实现更细粒度，也更合理的检测方案，同时在内核 Livepatch、漏洞检测以及防御提权相关攻击手段上，有着进一步的发展空间。eBPF 结合 LSM 的方案还在持续演进，功能和性能逐渐完善。
欢迎各位感兴趣的朋友加入龙蜥社区 eBPF 技术探索 SIG（Special Interest Group）（扫描下方二维码或搜索钉钉群号：44866635） ，一起讨论分享自己对eBPF 技术的看法和解决方案，和 SIG 组成员一起开启 eBPF 的神奇之旅！
eBPF 技术探索 SIG 链接地址：
—— 完 ——
加入龙蜥社群
加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】与你同在；加入钉钉群：扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥社区（OpenAnolis）交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！
关于龙蜥社区
龙蜥社区（OpenAnolis）是由企业单位、事业单位、社会团体、个人等在共建、共治、共享的基础上组成的非营利性开源社区。龙蜥社区成立于 2020 年 9 月，旨在构建一个开放、平等、协作、创新的 Linux 上游发行版社区及创新平台。
龙蜥社区成立的短期目标是开发龙蜥操作系统(Anolis OS)作为 CentOS 停服后的应对方案，构建一个兼容国际 Linux 主流厂商的社区发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。
目前，Anolis OS 8.6已发布，更多龙蜥自研特性，支持 X86_64 、RISC-V、Arm64、LoongArch 架构，完善适配 Intel、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密和机密计算支持。
欢迎下载：https://openanolis.cn/download
加入我们，一起打造面向未来的开源操作系统！https://openanolis.cn
