雖然經常更新內核版本通常被認為是一種安全最佳實踐，但由于各種原因，尤其是生產環境中的服務器無法這樣操作。這就意味著在機器運行時，會存在利用已知的漏洞(當然，還會有一些未知的漏洞)來進行攻擊的情況，所以需要某種方法來檢測和阻止對這些漏洞的利用，這正是Linux Kernel Runtime Guard(Linux內核運行時保護LKRG)誕生目的所在。

LKRG出自Openwall項目，該項目因其安全性增強的Linux發行版而聞名。Openwall的創始人亞歷山大·佩斯利亞克(Alexander Peslyak)，在安全領域也很極為出名。他在當年1月底宣布LKRG是“我們有史以來最具爭議的項目”。發布的0.0版本“相當草率”，Peslyak在LKRG 0.1發布公告中說;首席開發者Adam“pi3”Zabrocki根據10天的反饋整理內容并添加了一些新功能。

LKRG在Linux內核運行時對完整性進行檢查，并檢測內核的安全漏洞。LKRG是一個內核模塊(不是內核補丁)，所以它可以針對各種主線和發行版內核進行構建和加載，而不需要打補丁。目前支持的內核版本已更新至5.19，并支持x86-64、32位x86、AArch64 (ARM64)和32位ARM這幾類的CPU架構。

LKRG對正在運行的Linux內核進行檢測，并希望能夠及時響應對正在運行的進程用戶id等憑證未經授權的修改(完整性檢查)。對于進程憑據，LKRG嘗試檢測漏洞，并在內核根據未經授權的憑據授予訪問權限(例如打開文件)之前采取行動。Juho Junnila的論文題為“Linux Rootkit檢測工具的有效性”，顯示了LKRG可以作為有效的內核Rootkit檢測器。LKRG挫敗了許多預先存在的Linux內核漏洞的利用，并且很可能會檢測并防御許多未來沒有特意試圖繞過LKRG的利用(包括未知的漏洞)。雖然LKRG在設計上是可以繞過的，但這種繞過需要更復雜和/或更不可靠的漏洞。

為了跟蹤正在運行的內核，LKRG創建了一個數據庫，其中包含關于系統及其上運行的內核的各種類型信息的散列。它跟蹤系統中可用的和活動的cpu，以及它們的中斷描述符表(idt)和特定于模型的寄存器(MSRs)的位置和內容。由于插入(或從系統中拔出)的cpu數量的變化，內核可能會修改自己，所以LKRG必須準備好根據這些事件重新計算一些哈希值。

LKRG除了跟蹤內核.text、.rodata和異常向量表之外，也會跟蹤每個加載的內核模塊，包括它的struct模塊指針、名稱、.text的大小和哈希值等信息，以及模塊特定的信息。為了檢測修改，需要定期驗證存儲的值。這是通過許多機制實現的：

1. 首先是定時檢查計時器，檢測周期可以通過sysctl接口設置；

2. 當檢測到模塊加載或cpu熱插拔活動，并且可以通過另一個sysctl手動觸發時，它也會運行該檢查；

3. 系統中的其他事件(例如CPU空閑、網絡活動、USB更改等)將觸發驗證，盡管只有一定百分比的時間來降低性能影響。例如，CPU空閑將觸發0.005%的時間驗證，而USB更改將觸發50%的時間驗證；

所有這些都是為了保護運行時內核本身的完整性，但漏洞利用通常會針對系統上運行的進程，以提高特權等，這些信息保存在內核的內存中。因此LKRG還會跟蹤每個進程的一系列不同屬性，并維護自己的任務列表，用于驗證內核的列表。如果兩個進程發生分歧，則終止受影響的進程，目的是在被漏洞利用差異之前進行防御。

LKRG跟蹤的目標包括task屬性，如task_struct的地址、進程名稱和ID、cred和real_cred憑據結構的地址、與之關聯的各種用戶和組ID、SELinux設置以及seccomp配置。所有這些信息在每次系統調用(例如setuid()， execve())或系統中發生其他事件(例如，在打開文件之前檢查權限)時被驗證。此外，每次運行內核驗證時都要執行進程列表驗證。每次都要驗證所有進程，而不僅僅是進行系統調用的進程，任何差異都會導致終止有差異的進程。

LKRG測試了一些已知內核漏洞 (如CVE-2014-9322, CVE-2017-6074)，性能的影響約為6.5%。

非法提權（Illegal Elevation of Privileges）

1. Token / pointer swapping

2. 非法調用comit_creds()

3. 覆寫cred/read_cred結構體

沙箱逃逸

1. Namespace逃逸

2. 容器逃逸

為了說明LKRG的漏洞檢測能力，在對發行版內核的測試中，LKRG成功檢測到CVE-2014-9322 (badret)、CVE-2017-5123 (waitid(2) missing access_ok)、CVE-2017-6074(在DCCP協議中使用后free)的某些預先存在的漏洞。

但是，它無法檢測到CVE-2016-5195 (Dirty COW)的漏洞，因為這些漏洞直接針對用戶空間，即使是通過內核來進行操作。在Dirty COW中，LKRG的“繞過”是由于漏洞的性質和利用它的方式，這也是未來利用類似的直接針對用戶空間繞過LKRG的一種方式。

從檢測端避開LKRG:

1. 覆蓋LKRG不保護的關鍵元數據

2. 將攻擊移動到用戶空間

3. 贏得競態

從正面攻擊LKRG角度：

1. 攻擊LKRG內部的同步機制和鎖機制

2. 找到LKRG所有的上下文并禁用它們

3. 通過內核直接攻擊用戶空間(如DirtyCOW)

計算關鍵metadata的哈希值
保護范圍：

1. 發送到所有CPU中的核心數據IPI (Inter-Processor-Interrupt)，并獨占地運行LKRG的保護功能(IDT/MSR/CRx/等)

2. Linux內核.text部分

3. Linux內核.rodata部分

4. Linux內核的異常向量表

5. 關鍵的系統全局變量，如SMEP和SMAP

6. 所有動態加載的模塊及其在內部結構中的順序；

7. 如有IOMMU，也可對其防護

pCFI機制

1. 檢測ROP

2. 檢測棧遷移

3. 非.text數據的利用

4. 動態生成可執行page的利用

通過sysctl動態配置LKRG

root@ubuntu:~/lkrg# sysctl -a|grep lkrglkrg.block_modules = 0lkrg.heartbeat = 0lkrg.hide = 0lkrg.interval = 15lkrg.kint_enforce = 2lkrg.kint_validate = 3lkrg.log_level = 3lkrg.msr_validate = 1lkrg.pcfi_enforce = 1lkrg.pcfi_validate= 2lkrg.pint_enforce = 1lkrg.pint_validate= 3lkrg.profile_enforce = 2lkrg.profile_validate = 9lkrg.smap_enforce = 2lkrg.smap_validate= 1lkrg.smep_enforce = 2lkrg.smep_validate = 1lkrg.trigger = 0lkrg.umh_enforce = 1lkrg.umh_validate=1

從以上LKRG原理的角度來分析，對于需要仔細考慮內核的威脅模型以及具體需求的個人或公司來說，LKRG的功能是有價值的。所以可以作為系統級別縱深防御策略中的另一道防線，而不是“一招勝天”的靈丹妙藥。我們知道，內核中充滿了各種類型的自修改代碼，從跟蹤點和其他調試特性到各種優化，因此保護運行時的內核完整性并不是一項簡單的任務。本文分析了LKRG的原理與優劣勢解析，下篇將從實際案例和代碼的角度來分析，為什么會選擇LKRG做運行時安全檢測，敬請期待。

審核編輯 ：李倩