徐庆伟：龙蜥社区eBPF技术探索SIG组维护者&Linux内核安全研究员。本文是作者在PODS2022大会上对内核安全的思考和体会。本次分享将从监控与可观察性、eBPF安全可观察性分析、内核安全可观察性展望三个方面入手。1.eBPF安全可观测性的前景从下图可以看出，监控只是可观测性的冰山一角，隐藏在水下的深层次问题，绝大部分不能简单地通过监控来解决。监控（Monitoring）vs可观察性（Observability）目前监控也开始可视化，但大多是事先预定义参数，事后查看日志进行分析。监控的缺点包括：1）可扩展性差，需要修改代码和编译；验证周期长；窄数据源等2)可观察性是通过主动自定义测量收集和内核数据聚合，包括以下三种类型：Logging实时或事后特定事件信息分布式服务器集群海量数据溯源图各种异步的离散信息排序信息追踪数据源：提供数据源获取框架：向上连接数据源，收集、分析和发送数据，向下提供用户态接口。前端交互：接入Tracing内核框架，直接与用户交互，负责采集配置和数据分析。指标（metrics）也是可观察性与监视之间的主要区别。统计聚合系统中某类信息，如CPU、内存、网络吞吐量、硬盘I/O、硬盘使用率等，当metric值触发异常阈值时，系统可以发出告警信息或主动处理，如杀死或隔离进程；主要用途：监控（Monitoring）、预警（Alert）。总结一下监控和可观察性的区别：监控：收集和分析系统数据，查看系统当前状态，分析和处理可预见的问题。可观察性：通过观察系统，测量系统内部状态，从其对外输出的数据可以推断出系统此时处于一定的测量水平，尤其是我们关心的场景和事件。2.eBPF安全可观察性分析安全性：是指某些对象或对象属性不受威胁的状态。安全可观察性：通过观察整个系统，从低级内核可见性到跟踪文件访问、网络活动或能力（capability）变化，一直到应用层，覆盖如对易受攻击的共享库的函数调用，跟踪进程执行或解析发出的HTTP请求。所以这里的安全是一个整体的概念。提供各种内核子系统的可观察性，涵盖命名空间逃逸、能力和权限提升、文件系统和数据访问、HTTP、DNS、TLS和TCP等协议的网络活动，以及系统调用层的事件，以审计系统调用和跟踪过程执行。能够从日志、轨迹、度量三个维度查看相关输出，衡量系统内部的安全状态。eBPF的安全可观察性表现在它在内核中的存在很少，但是它的观察能力却极其强大（药效好，副作用小）：程序沙盒：内核的稳定运行由eBPF验证器。低侵入性：无需修改内核代码，无需停止程序运行。透明：透明地从内核收集数据，确保企业最重要的数据资产。可配置：Cilium等自定义甚至自动配置策略，更新灵活度高，过滤条件丰富。快速检测：直接在内核中处理各种事件，无需返回用户态，异常检测方便快捷。其中，eBPF程序的沙箱化更离不开安全模式的eBPFVerifier（其中最重要的是边界检查）：它拥有加载eBPF程序的过程所需的权限，程序可以正常结束没有crash或者其他导致系统崩溃的异常，没有无限循环检查内存越界检查寄存器溢出eBPF的可观察性应用场景主要分为以下三类：1.云原生容器的安全可观察性最热门的云原生场景。Falco、Tracee、Tetragon、Datadog-agent、KubeArmor是现阶段云原生场景下比较流行的一些运行时保护方案。这些解决方案主要是基于eBPF来挂载内核函数和编写过滤策略。当内核层发生异常攻击时，触发预设策略，无需返回用户层直接报警甚至阻断。以预防方式在整个操作系统中实施安全策略，而不是对事件做出异步反应。除了能够为多级访问控制指定允许列表外，它还能够自动检测权限和能力升级或命名空间升级（容器逃逸）并自动终止受影响的进程。可以通过Kubernetes(CRD)、JSONAPI或OpenPolicyAgent(OPA)等系统注入安全策略。2.应用层安全可观察性解决方案这些解决方案是在应用层和系统调用层实现的，可观察性解决方案也各不相同。它们都有一个用户空间代理，该代理依赖于按定义收集的可观察性数据然后对其做出反应，并且无法观察内核级事件。3.内核层安全和可观察性方案这类方案直接运行在内核层，主要是运行时执行，观察能力较弱（甚至没有观察能力）。内置的内核系统提供了很多策略执行选项，但内核在构建时只专注于提供访问控制能力，扩展难度很大。例如，内核无法感知Kubernetes和容器。内核模块虽然解决了可扩展性问题，但由于其产生的安全风险，在很多场景下往往不是明智的选择。像LSM-eBPF这样的年轻内核子系统非常强大和有前途，但只依赖于最新的内核（≥5.7）。3.内核安全可观察性展望下面分别讨论传统内核安全、Android内核安全和KRSI。1、传统的内核安全解决方案：LinusTorvalds曾经说过，大多数安全问题都是由bug引起的，而bug是软件开发过程的一部分，软件中存在bug。至于是安全漏洞还是非安全漏洞bug，内核社区的做法是尽可能多地测试，找出更多潜在的漏洞，类似于黑名单的做法。提交内核代码的过程比较繁琐，而且应用于特定内核版本时，存在周期长和版本适配的问题，所以内核在安全方面的开发速度明显慢于其他内核模块。同时，随着智能化、数字化、云化的快速发展，全球有数百亿台基于Linux的设备，这些设备的安全性主要取决于主线内核的安全性和健壮性。当某个内核LTS版本发布时存在漏洞，那么相关机器将面临被利用的局面，损失不可估量。2、Android内核安全如今，全球越来越多的智能终端，包括手机、电视、SmartBoxes以及物联网、汽车、多媒体设备等都在深度使用Android系统，而Android的底层是Linux内核，这也使得Linux内核的安全性对Android产生了重大影响。由于历史原因，谷歌在Android内核开源方面的理念与Linux内核社区不太吻合。这也导致Android对内核进行了大量有针对性的修改，却无法纳入Upstream。这也导致Android内核在安全方面与Linux内核存在一定的差异，侧重点也不一样。在操作系统层面，Android平台不仅提供了Linux内核的安全特性，还提供了安全的进程间通信（IPC）机制，用于运行在不同进程中的应用程序之间的安全通信。这些操作系统级别的安全功能旨在确保即使是本机代码也受制于应用程序沙箱。该系统可防止违规应用程序损害其他应用程序、Android系统或设备本身，无论代码是本机应用程序行为的结果还是利用应用程序漏洞。Android内核安全特性：HWAddressSanitizerKASANTop-byteIgnoreKCFIShadowCallStack3。内核安全可观察性武器——KRSIKRSI（KernelRuntimeSecurityInstrumentation）原型以LSM（Linuxsecuritymodule）的形式实现，可以将eBPF程序挂载到内核的安全钩子（securityhookPoint）上。内核安全主要包括两个方面：Signals和Mitigations，两者是密不可分的Signals：是指系统有一些异常活动的迹象，eventMitigations：检测到异常行为后采取的告警或阻断措施KRSI是基于LSM实现的，这也使其能够做出访问控制策略决策，但这并不是KRSI的工作重点，主要是对系统行为进行全面监控，以检测攻击（最重要的应用场景，但目前主要只是检测，因为阻断可能会有危险从这个角度来看，KRSI可以说是内核审计机制的扩展，使用eBPF提供比当前内核审计子系统更高级别的可配置性。1)KRSI允许具有适当特权的用户在LSM子系统提供的数百个挂钩中的任何一个挂载BPF程序。2)为了简化这一步，KRSI在/sys/kernel/security/bpf下导出一个新的文件系统层次结构——每个挂钩一个文件。3)BPF程序（新的BPF_PROG_TYPE_LSM类型）可以使用bpf()系统调用挂载到这些钩子上，并且可以有多个程序挂载到任何给定的挂钩上。4)每当安全钩子被触发时，所有挂载的BPF程序都会被顺序调用，只要有任何BPF程序返回错误状态，请求的操作就会被拒绝。5）KRSI可以在函数层面进行阻塞操作，比进程更细粒度，危险程度小很多。4.后续计划内核安全是一个非常复杂的话题，牵一发而动全身。防御机制、强化配置、漏洞利用和其他具有挑战性的技术。在加强防御的过程中，会对性能或系统稳定性产生影响。从eBPF+LSM的角度，可以更直观、数据更丰富地观察内核安全状况，在内核Livepatch、漏洞检测、提权相关防御手段等方面还有进一步发展的空间。内核安全问题牵一发而动全身，尤其是在运行时安全方面。通过上述新的eBPF程序类型，为信号和缓解提供了统一的API策略，优化了内核LSM框架和现有机制容易丢失系统调用的问题。从阻断函数调用的角度来看，可以实现更细粒度和更合理的检测方案，在内核Livepatch、漏洞检测、提权相关攻击防御等方面都有进一步发展的空间。eBPF结合LSM的方案还在不断演进，其功能和性能也在逐步完善。欢迎所有感兴趣的朋友加入龙蜥社区eBPF技术探索SIG（SpecialInterestGroup）（钉钉群号：44866635），共同探讨和分享自己对eBPF技术的看法和解决方案，与社区成员共同开启eBPF的神奇SIG集团的旅程！eBPF技术探索SIG链接地址：https://openanolis.cn/sig/ebp...——END——
