【云攻防系列】玩转eBPF-关于内核运行时安全的那些事儿

基于以上历史原因，eBPF 和基于函数的更细粒度管控方案重磅出炉，名字就叫内核运行时检测 KRSI（Kernel Runtime Security Instrumentation）。

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

• Signals 就是指一些可能意味着（并不是 100% 确定）系统有一些异常活动的迹象、事件；

• Mitigation 则是指在检测到异常行为之后所采取的补救措施；

KRSI 基于 LSM 来实现，这也就使其能够进行访问控制策略的决策，但这不是 KRSI 的工作重心，主要是为了全面监视系统行为，以便检测攻击。从这种角度来看，KRSI 可以说是内核审计机制的扩展，使用eBPF 来提供比目前内核审计子系统更高级别的可配置性。

struct krsi_hook {

const char *name

enum krsi_hook_type h_type;

struct dentry *h_dentry;

struct mutex mutex;

struct bpf_prog_array __rcu *progs;

};

在 KRSI 中，三个参数将直接传递给任何挂载的 BPF程序。这些程序可以通过 vma 指针来了解所有受影响的内存区域。它们还可以根据 vma->vm_mm 来获得调用进程的顶层内存管理数据(mm_struct 结构体)。简而言之，这些程序可以获取大量信息。

int security_file_mprotect(struct vm_area_struct *vma,

unsigned long reqprot,unsigned long prot);

内核安全问题，牵一发而动全身，尤其是在运行时安全方面。通过上述 eBPF 新型 program 类型，为 signals 和 mitigation 提供统一 API 的策略，并优化内核 LSM 框架和现有机制容易丢失系统调用的问题，从阻断一个函数调用运行的角度，来实现更细粒度，也更合理的检测方案，同时在内核Livepatch、漏洞检测以及防御提权相关攻击手段上，有着进一步的发展空间。eBPF 结合 LSM 的方案还在持续演进，功能和性能逐渐完善，详细请看内核社区 LSM 邮件列表或https://lore.kernel.org/all/?q=eBPF+LSM。创新研究院云安全团队将会持续关注相关内容和技术的演进。