【雲攻防系列】玩轉eBPF---關於核心執行時安全的那些事兒

知識背景

當我們談及執行時防護產品或方案時，人們的目光主要集中在主機、終端和目前最火熱的雲原生場景上。Falco、Tracee、Tetragon、Datadog-agent、KubeArmor 是現階段雲原生場景下比較流行的幾款執行時防護方案。這些方案主要是基於 eBPF 掛載核心函式並編寫過濾策略，在核心層出現異常攻擊時觸發預置的策略，無需再返回使用者層而直接發出告警甚至阻斷。

這樣的方案優點是可以自定義乃至自動化配置策略，修改檢測、阻斷規則檔案更快速，更新靈活性高、過濾條件豐富（程式、網路、檔案等），更加重要的在核心直接處理各種事件，節省了資料傳輸和上下文切換帶來的效能損耗，對於網路或者 Tracing 等短時間大量資料處理的場景，效能方面提升更高。劣勢也很明顯，也就是隻能管控到程式這個粒度。如果發生誤報的時候，殺死程式對系統穩定性和效能有很大的影響，也會涉及到正常業務的流轉。

我們都知道核心社群的傳統就是相對安全性更側重於效能和功能（這也是各大廠商最關注的部分），在需要犧牲效能來改善核心安全性時並不願意折衷處理。其實從另一個角度來看，也不是核心社群不想合入有用的安全 Patch，從 LKML 裡面關於 LSM 或者其他 Security 相關的訂閱人數、世界上獨立的核心安全公司數量來看，除了一些核心安全機制有相應大公司或大社群維護（SELinux (NSA)、AppArmor (OpenSuSE/Ubuntu)、PaX / grsecurity (Spender)），以及 PaX / grsecurity 和核心社群的歷史淵源，所以在全球範圍內，真實有效的核心安全開發者是少之又少。

Linux核心社群堅持"Security through obscurity"哲學，這意味著核心社群從來不主動申請CVE漏洞編號，即使如此，2021年1月到8月，有CVE編號的核心漏洞超過110個。再加上核心程式碼提交走的流程比較繁瑣，應用到具體核心版本上，又存在週期長以及版本適配的問題，所以導致核心在安全方面發展的速度明顯慢於其他模組。

KRSI優勢和流程

基於以上歷史原因，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);

1. KRSI 允許適當的特權使用者將 BPF 程式掛載到 LSM 子系統提供的數百個鉤子中的任何一個上面；

2. 為了簡化這個步驟，KRSI 在 /sys/kernel/security/bpf 下面匯出了一個新的檔案系統層次結構——每個鉤子對應一個檔案；

3. 可以使用 bpf() 系統呼叫將 BPF 程式(新的BPF_PROG_TYPE_LSM 型別)掛載到這些鉤子上，並且可以有多個程式掛載到任何給定的鉤子。

4. 每當觸發一個安全鉤子時，將依次呼叫所有掛載的 BPF程式，只要任一 BPF 程式返回錯誤狀態，那麼請求的操作將被拒絕。

結論

核心安全問題，牽一髮而動全身，尤其是在執行時安全方面。透過上述 eBPF 新型 program 型別，為 signals 和 mitigation 提供統一 API 的策略，並最佳化核心 LSM 框架和現有機制容易丟失系統呼叫的問題，從阻斷一個函式呼叫執行的角度，來實現更細粒度，也更合理的檢測方案，同時在核心Livepatch、漏洞檢測以及防禦提權相關攻擊手段上，有著進一步的發展空間。eBPF 結合 LSM 的方案還在持續演進，功能和效能逐漸完善，詳細請看核心社群 LSM 郵件列表或https://lore.kernel.org/all/?q=eBPF+LSM。創新研究院雲安全團隊將會持續關注相關內容和技術的演進。