Linux 2.6內核下LKM安全性研究

徐 敏 ，熊盛武

（武漢理工大學 湖北 武漢 430070）

可加載內核模塊[1]（Loadable Kernle Module（LKM））作為對Linux宏內核結構的一種改進，它可以在不需要重新編譯內核下被動態加載，作為內核級代碼存在于內核空間，能夠訪問內核的重要數據結構。通常情況下模塊通過合理修改系統的控制轉移地址或添加門來和系統聯系成一個整體，如果是惡意模塊，它就可以進行多種非法操作，留下系統級后門。

1 LKM攻擊方法

1.1 LKM系統調用劫持

在Linux中劫持系統調用的思想是修改程序執行過程中跳轉的目的地址。在Linux 2.4.18內核以前，是直接對sys_call_table[2]表進行修改，sys_call_table表是保存所有系統調用函數地址的指針數組，直接用自定義的函數地址替換原來的地址，即可實現對系統調用的劫持。在Linux2.4.18內核以后，為了解決這個安全問題，sys_call_table表不能直接導出，利用中斷描述符表IDT及字符設備文件/dev/kmem依然可以查找到sys_call_table表的地址，可以通過sIDT指令獲取到中斷向量表的地址，然后通過讀取/dev/kmem來定位到該地址，然后通過調用read函數或者mmap函數的方式來讀取出0×80中斷描述符的內容，然后從其中可以提取出sys_call_table表的地址。2.6內核采用被稱為“快速系統調用”的sysenter指令來完成從用戶態到內核態的快速切換方法，這是一種不檢查特權級的系統調用，在實際情況下，發生系統調用時的特權檢查工作會浪費許多時間且沒有必要，由于通過INT$0×80指令進入系統調用時，其門描述符的描述符特權級DPL為3，而系統調用在正常情況下也是從用戶態進入內核態，故進入之前的權限當前特權級CPL也是3，權限提高前后級別不變，則CPU檢查門描述符的DPL和調用者的CPL就沒有必要。根據sysenter指令的實現原理，MSR_IA32_SYSENTER_EIP寄存器存放著指令到內核態的跳轉地址，只需要通過改變MSR_IA32_SYSENTER_EIP寄存器來完成劫持。首先利用rdmsr指令把系統定義的sysenter指令的目的地址讀到某一變量old_sysenter，然后利用wrmsr指令將自定義的函數地址寫到MSR_IA32_SYSENTER_EIP寄存器，撤消截獲的方法是將old_sysenter通過wrmsr指令寫回到MSR_IA32_SYSENTER_EIP寄存器。

在Linux 2.6內核最新版本中，為了防止惡意模塊通過IDT表和/dev/kmem設備找出sys_call_table表的地址，/dev/kmem設備也不再導出。但對于惡意的LKM，只要它躲過安全檢查進入到內核態下，它仍然可以利用中斷描述符表中的0x80中斷以及MSR_IA32_SYSENTER_EIP寄存器中的跳轉地址來搜索內存，尋找到sys_call_table表的地址來完成系統調用劫持，這是需要改進的地方，在后面會討論這一點。

1.2 LKM注射技術

LKM注射攻擊[3]通過感染系統正常的LKM，在不影響原有功能的情況下將攻擊模塊鏈接到該LKM中。LKM的目標文件格式是ELF格式，其中有兩個重要節.symtab節和.strtab節，.strtab節是一個表示函數或變量名的非空字符串列表，.symtab節是個結構體數組，結構體元素是struct Elf32_Sym類型的，其中字段st_name是.strtab節的索引，字段st_value表示.strtab節中函數或變量的地址值。通過檢查.strtab節里的字符串（如init_module），可以定位模塊中原先init函數的地址，如果修改這個字符串，則可以在模塊被加載時只執行修改后的字符串所對應的惡意函數。如果在這個惡意函數中再調用原來的函數，那么就可以使這種攻擊變得更加隱秘。由于Linux 2.6內核模塊子系統被完全重寫，修改.strtab的方法已經失效，即使修改了.strtab節中init_module，運行的始終是原來的init_module。因為Linux 2.6內核符號的重定位不再需要.strtab節的參與，攻擊的目標從.strtab節變成了.rel.gnu.linkonce.this_module重定位節中的Elf32_Rel項，被注射攻擊的模塊會通過遍歷.rel.gnu.linkonce.this_module節中Elf32_Rel項， 如 orig_init_idx== ELF32_R_SYM （rel－＞r_info）， 就 將rel_r_info的symbol部分替換成被被注射模塊函數的索引號。

1.3 LKM隱藏技術

由于在加載新的LKM后會在/proc/modules文件中留下記錄，只需利用/sbin/lsmod命令就可以查看模塊信息。如果能夠使該攻擊模塊在/proc/modules中不被顯示，就能使系統管理員無從察覺該攻擊模塊的痕跡，從而實現了隱藏。為了完成該攻擊模塊的隱藏，有大致3類方法。

1）將該攻擊模塊從module_list鏈表中摘下而不真正地將它從內存中卸載。由于該模塊加載時通過宏EXPORT_SYMBOL輸出的變量和函數已經被其他模塊和內核所引用，故從鏈表中摘除該攻擊模塊并不影響其功能。

2）截獲并替換查詢模塊信息的系統調用sys_query_module（）函數，在替換后的調用中首先執行原來的sys_query_module（）函數，把所有模塊信息讀到內存某個地方，然后對這些信息進行查詢并過濾掉需要隱藏的模塊信息。

3）不是把自己從module_list鏈表中刪除，而是把某個正常的模塊從該鏈表刪除，然后將該攻擊模塊改名成剛才被刪除的正常模塊。但這樣會導致系統在使用這個被刪除的正常模塊時出現問題，不利于自己的隱藏。

在Linux 2.6內核中，絕大部分內核數據結構都改用雙向鏈表組織，模塊也不例外。因為雙向鏈表從鏈表中間刪除數據項比單向鏈表簡單，而且還可以從后往前遍歷鏈表。

2 LSM框架與LKM安全

2.1 LSM框架原理

LSM[4]框架為了實現一個通用的訪問控制框架，為安全模塊的開發提供一致性接口。它是在內核對象的數據結構中添加一個透明安全字段，并在內核源代碼的適當位置放置鉤子函數，LSM框架只提供這些字段以及這些鉤子函數的調用接口，字段的分配、釋放、管理等是由安全模塊處理的，鉤子函數的實現是在安全模塊完成的，其用來對內核對象的訪問權限進行判斷，LSM框架鉤子函數結構如圖1所示。LSM框架指定的內核對象有task_struct（進程）、super_block（文件系統）、inode（文件、管道、套接字）、sk_buff（套接字緩沖區）等等。LSM框架提供了兩種鉤子函數，一種用來分配、釋放、管理內核對象的安全字段，如alloc_security、free_security；另一種用來對內核對象進行訪問控制。對這兩種鉤子函數的調用方式是security_ops－＞鉤子函數名，其中security_ops是指向struct security_opertaions結構體的函數指針，這些鉤子函數被放置在內核源代碼的某些關鍵點，以完成相應安全檢查。

還需要向LSM框架注冊安全模塊，安全模塊的注冊和注銷功能是由 register_security（）和 unregister_security（）函數分別完成的，注冊函數將設置全局表指針security_ops，使其指向這個安全模塊的鉤子函數表。一旦這個安全模塊被加載，就不會被后面的register_security（）函數覆蓋，直至這個安全模塊使用unregister_security（）向LSM框架注銷。LSM框架只允許注冊一個主安全模塊，為了完善主安全模塊的不足，它還提供了輔助安全模塊的模塊堆棧機制：輔助安全模塊向主安全模塊注冊，使用mod_reg_security（）和mod_unreg_security函數分別向主安全模塊注冊和注銷。

圖1 LSM框架鉤子函數結構圖Fig.1 Structure of LSM frame’s hook

2.2 LSM框架對LKM安全的保障

在Linux2.6內核中，LSM框架對LKM安全的控制可以從模塊加載過程中得知，它主要是通過基于安全鉤子函數的調用來為系統的各種訪問控制提供可擴展的安全模塊框架。模塊是通過insmod程序進行加載的，insmod中的執行過程是先調用grabfile函數在用戶態下獲取文件的內存映象，然后調用sys_init_module函數進入內核態進行模塊鏈接。在grabfile函數中，需要調用security_inode_permission函數來對inode索引節點的訪問權限進行檢查以及調用security_dentry_open函數來對文件打開權限進行檢查。在sys_init_module函數中，需要調用security_capable函數進行基于CAP_SYS_MODULE能力的加載權限的檢查。所以專門針對module的安全鉤子的調用只有 security_inode_permission、security_dentry_open、security_capable這3個函數。在攻擊方式的分析中，如果不導出sys_call_table表，LKM惡意程序需要訪問/dev/kmem文件，在LSM框架下，訪問文件的時候內核會調用security_inode_permission函數以及security_inode_permission函數來對訪問文件的權限進行檢查。在一些Linux 2.6最新內核中，/dev/kmem文件不再導出。但惡意模塊仍然可以通過中斷描述符和MSR的方法搜索出sys_call_table表的起始地址，但這一方法的前提是這個惡意模塊已經被加載到內核中，這樣惡意模塊在加載的時候就需要這3個函數的檢查。這3個安全鉤子函數是基于進程是否對文件具有訪問權以及對模塊加載權，其具體的判斷準則是以LSM模塊的具體實現為標準。

2.3 LKM框架與安全模塊管理器

由于在LSM框架下內核對象的數據結構中的安全域指針只有一個，這種設計決定了LSM框架只能同時支持一個安全模塊，多個獨立設計且分別具有自己相應安全域的安全模塊，不能夠在LSM框架共存，即使采用模塊疊加技術，本質上還是只支持一個獨立安全模塊，因為主安全策略決定了從模塊的安全策略。為了真正解決這個問題，實現多個安全模塊策略綜合的安全模塊管理器（SMM）[5]就出現了，它支持多個獨立的安全模塊共存，可對多安全模塊進行有效管理，且與LSM框架兼容。SMM也以LKM形式存在。裝載到內核的安全模塊并沒有直接向LSM框架注冊，而是先在SMM注冊，即在安全模塊鏈表中添加一個節點。LSM框架首先調用SMM的鉤子函數，再由SMM鉤子函數調用各個安全模塊中的安全鉤子函數。當用戶進程進行系統調用時，系統調用內要調用SMM中的鉤子函數進行安全檢測，SMM把這個安全檢測交給各個獨立安全模塊分別進行檢測，只要有一個安全模塊的檢測沒有通過，系統調用就會被SMM拒絕而退出整個檢測過程。最后SMM將各個安全模塊的檢測結果綜合并返回給系統調用，然后系統調用根據結果決定是否繼續執行。當然在SMM上加載多個安全模塊會增加系統開銷，且略大于各個單個安全模塊開銷的代數和，這主要是因為LSM和各個安全模塊之間多了SMM模塊。為此可以對多模塊的調用順序進行算法優化，而且可以引入Cache機制，來緩存一些安全檢測結果，從而來提高SMM的時間效率。另外為了適應不同環境下特定的安全應用，還可以通過設計策略開關靈活地進行安全策略的動態選擇。SMM工作原理圖如圖2所示。

3 SELinux模型與LKM安全

3.1 SELinux模型

LSM框架自身并不提供任何安全策略，它只是為安全模型提供了一致性接口。它使得各種不同的安全模型以內核模塊的方式得到實現，而且不需改動內核源代碼以及重新編譯內核。目前基于LSM框架實現的最主要的安全模塊主要有SELinux[6]（安全增強型 Linux）、LIDS（Linux 入侵檢測系統）、POSIX 1e Capabilities以及DTE（域和類安全增強）。

圖2 SMM工作原理圖Fig.2 Working principle of SMM

SELinux模型的安全體系結構被稱為Flask體系，其體系結構如圖3所示，它是基于動態策略配置的MAC（強制訪問控制）子系統，能夠支持較細粒度的權限管理，開始是以內核補丁的方式實現，在Linux 2.6內核中是以模塊形式出現。SELinux由3部分組成：安全服務器，訪問向量緩存，對象管理器。安全服務器為獲得安全策略的決策判定提供通用接口，使其余部分保持安全策略的獨立性。訪問向量緩存AVC提供了從安全服務器獲得的訪問策略決策結果的緩沖區，以減少性能開銷。對象管理器集成在內核的各個子系統，如進程管理子系統，文件子系統，它從安全服務器或者訪問向量緩存AVC中獲得安全策略判定結果，然后應用這些判定結果給進程和對象的安全標記賦值，最后根據這些安全標記控制系統上的各種操作。

圖3 FLASK體系結構圖Fig.3 Architecture of FLASK

3.2 SELinux模型保障LKM安全

在傳統的安全機制下，Linux安全是基于自主存取控制（DAC）機制的，只要符合規定的權限，如規定的所有者和文件屬性（讀、寫、執行）等，就可存取資源。一些通過setuid/setgid的程序就能形成嚴重的安全隱患，甚至一些錯誤的配置就可引發巨大漏洞，使系統被輕易攻擊。而SELinux則基于強制存取控制（MAC），透過強制性的安全策略，應用程序或用戶必須同時符合DAC及對應SELinux的MAC才能進行正常操作，否則都將遭到拒絕或失敗，而這些問題將不會影響其他正常運作的程序和應用，并保持它們的安全系統結構。

LKM 注入攻擊一般是對/lib/modules/（uname-r）/kernel/下的模塊文件進行修改，SELinux下的權限設置能限制對模塊文件的修改，為模塊文件的完整性提供保證，從而防止針對模塊文件的LKM注入攻擊。同時SELinux下的權限設置限制了惡意程序對/dev/目錄下文件訪問和修改。由于進行了基于CAP_SYS_MODULE權能的加載權限的檢查，阻止了許多獲取root權限后的惡意加載。

雖然SELinux對LKM的安全有很好的保證，但是一旦由于訪問策略的設置失誤以及直接在原模塊代碼中植入惡意函數片段，這樣的LKM惡意模塊依然能鏈接進內核，由于LSM框架并沒有相應的安全鉤子函數來保障諸如IDT表、sys_call_table表等內核重要數據結構的安全，惡意程序就可以利用這些信息進行惡意攻擊。為此可以擴展LSM框架，在內核源代碼相應關鍵點插入鉤子函數。由于LKM攻擊的根本特性是init_module函數的執行，init_module函數能修改內核數據中跳轉地址值，所以init_module的正確運行是模塊安全的關鍵。如果能在init_module的前后進行重要數據結構內容的檢測和恢復，則可保障內核重要數據結構的安全，因此我們可以在init_module函數的前后位置各放置一個安全鉤子函數，分別用于記錄重要數據結構在init_module函數執行之前的值以及在init_module函數執行之后校驗這些數據結構的值，從而防止已加載進內核的惡意模塊利用這些信息進行攻擊。

4 結束語

針對LKM的攻擊手段有很多，以介紹Linux 2.4內核下的LKM攻擊技術為切入點，重點介紹Linux 2.6內核下LKM攻擊技術的原理和方法，同時著重分析了針對這些攻擊的防御體系LSM框架，針對目前的LSM防御體系只支持一個獨立安全模塊的不足，提出了安全管理器SMM的解決方案。通過分析已經在Linux下實現的基于LSM框架的SELinux模型針對LKM安全性的作用以及不足之處，提出了使用LSM擴展技術在init_module函數的前后位置各放置安全鉤子函數的解決方案。

[1]博韋，西斯特.深入理解LINUX內核[M].3版.陳莉君，張瓊聲，張宏偉，譯.北京:中國電力出版社，2007.

[2]毛德操，胡希明.Linux內核源代碼情景分析（上、下冊）[M].杭州:浙江大學出版社，2001.

[3]耿顯虎.Linux下LKM安全的分析與改進研究[D].成都：電子科技大學，2008.

[4]馬桂媛.基于通用訪問控制框架LSM的Linux安全內核的研究[D].四川：西南交通大學，2004.

[5]李婷妤.基于LSM框架的安全模塊管理器的設計與實現[D].湖南：中南大學，2008.

[6]龔友.Linux下內核級Rootkit檢測防護機制的研究 [D].成都：電子科技大學，2009.