LSM是什么？

主、次、獨(dú)占LSM模塊

SELINUX – 安全增強(qiáng)的Linux

SMACK – 簡化的強(qiáng)制訪問控制

APPARMOR

TOMOYO

LOADPIN

YAMA

SAFESETID

LOCKDOWN LSM

結(jié)論

我猜，你讀這篇文章，說明你已經(jīng)對(duì)Linux安全模塊（LSM）有所了解。如果你使用過SELinux或AppArmor，其實(shí)就已經(jīng)用過LSM了。甚至，在你使用的Linux發(fā)行版本或Android系統(tǒng)之上，也使用了LSM。

內(nèi)核5.4版本內(nèi)，有8個(gè)LSM模塊：SELinux、SMACK、AppArmor、TOMOYO、Yama、LoadPin、SafeSetID、Lockdown。還有一些LSM模塊在開發(fā)中，比如SARA?和?KRSI，也許不久就會(huì)合入Linux內(nèi)核源碼中。如果你是關(guān)注安全的系統(tǒng)或軟件工程師，理解為什么有這么多的LSM模塊是非常值得的。它們有一些是解決通用問題，有一些則是解決特定問題。意識(shí)到它們的差異，才能更好地理解Linux的安全特性。

LSM是什么？

一個(gè)LSM模塊是直接編譯Linux內(nèi)核的代碼，利用LSM框架，它可以拒絕某個(gè)進(jìn)程訪問重要的內(nèi)核對(duì)象。這些對(duì)象包括：文件、inode、任務(wù)控制塊、憑證和進(jìn)程間通信對(duì)象。通過指定允許的交互，安全管理員可以讓攻擊者很難利用程序的缺陷從而攻擊系統(tǒng)的其它部分。

LSM框架的第一個(gè)，也是最流行的使用場景是強(qiáng)制訪問控制（MAC）策略。毫無疑問，在內(nèi)核中實(shí)現(xiàn)MAC策略的方法有多種。2001年，美國國家安全局的Peter Loscocco在Linux 2.5?內(nèi)核峰會(huì)上展示了首個(gè)實(shí)現(xiàn)。Linux Weekly News的Jonathan Corbet后來指出：

經(jīng)過這么多年的發(fā)展，這些標(biāo)準(zhǔn)接口已經(jīng)形成了LSM框架。截止到5.4內(nèi)核，該框架已經(jīng)包含224個(gè)hook點(diǎn)，這些hook點(diǎn)包含一個(gè)注冊函數(shù)的API和為LSM模塊保留受保護(hù)內(nèi)核對(duì)象所使用的內(nèi)存的API。到Linux 2.6版本，LSM框架和SELinux合并到了內(nèi)核主線中（使用LSM框架，而不是直接在內(nèi)核代碼中修改）。盡管LSM框架的實(shí)現(xiàn)，隨著時(shí)間的不斷推移而發(fā)生變化，但是它實(shí)現(xiàn)對(duì)重要內(nèi)核對(duì)象的細(xì)粒度訪問控制的基本目標(biāo)沒有改變。

目前的LSM框架已經(jīng)允許用戶將多個(gè)LSM模塊編譯進(jìn)內(nèi)核，存儲(chǔ)在內(nèi)核的堆?？臻g中，并同時(shí)使用它們。下圖展示了一個(gè)文件打開（open()）操作的簡略調(diào)用流程圖（假設(shè)為3個(gè)LSM模塊注冊了hook鉤子函數(shù)。

用戶態(tài)進(jìn)程調(diào)用open()，打開一個(gè)文件；

調(diào)度系統(tǒng)調(diào)用，使用文件路徑作為獲取內(nèi)核文件對(duì)象的參數(shù)。如果參數(shù)非法，返回錯(cuò)誤。

正常的自由訪問控制（Discretionary Access Control）文件訪問權(quán)限檢查。如果沒有權(quán)限，系統(tǒng)調(diào)用終止，返回給用戶錯(cuò)誤。

如果滿足DAC控制，則LSM框架為每個(gè)使能的LSM模塊調(diào)用file_opne鉤子函數(shù)。任何一個(gè)LSM鉤子函數(shù)返回錯(cuò)誤，則系統(tǒng)調(diào)用終止，并返回給用戶錯(cuò)誤。

如果所有的安全檢查通過，則為該進(jìn)程打開該文件，并返回給用戶態(tài)進(jìn)程一個(gè)新的文件描述符fd。

主、次、獨(dú)占LSM模塊

對(duì)LSM有了初認(rèn)識(shí)之后，我們再來看各個(gè)LSM模塊能做什么。首先，我們先看看早期的主LSM模塊：SELinux、SMACK、AppArmor和TOMOYO，它們都是MAC訪問控制策略的實(shí)現(xiàn)，從用戶空間加載配置策略。他們都以自己的方式解決相同的問題。

早期的LSM框架一次只能允許加載一個(gè)LSM模塊。所有的主LSM模塊都假設(shè)自己獨(dú)占內(nèi)核保護(hù)對(duì)象的指針或標(biāo)識(shí)符。因此，所以一次只能使用一個(gè)主LSM模塊。可以在編譯內(nèi)核時(shí)選擇編譯進(jìn)鏡像，如下圖所示；也可以通過內(nèi)核命令行參數(shù)傳遞。

LSM框架不斷優(yōu)化，已經(jīng)消除了主、次LSM模塊之間的區(qū)別?，F(xiàn)在區(qū)分主、次LSM模塊的優(yōu)選方法是使用LSM_FLAG_EXCLUSIVE獨(dú)占標(biāo)志。一個(gè)用戶可以配置多個(gè)LSM，只要給其中的一個(gè)設(shè)置LSM_FLAG_EXCLUSIVE標(biāo)志即可。

次LSM是將大部分策略直接編碼到內(nèi)核代碼中。通常情況下，次LSM模塊只有enable/disable選項(xiàng)，而不是將策略文件在系統(tǒng)啟動(dòng)時(shí)從用戶空間加載。

SELINUX – 安全增強(qiáng)的Linux

SELinux最早是在Linux2.6版本合入內(nèi)核的，RedHat發(fā)布的Linux發(fā)行版將其作為默認(rèn)的MAC強(qiáng)制訪問策略。它以功能強(qiáng)大和復(fù)雜著稱。

SELinux基于屬性實(shí)現(xiàn)，將文件的安全屬性存儲(chǔ)在文件系統(tǒng)的擴(kuò)展文件屬性中。比如，使用ls -Z /bin/bash文件的安全屬性，如下所示。我們可以看到有四個(gè):冒號(hào)分割的屬性，分別代表usertype:level。

?

$ ls -Z /bin/bash
-rwxr-xr-x. root root system_ushell_exec_t:s0 /bin/bash

?

SELinux的常用方法是指定主體（在此也就是指user）對(duì)某種類型的對(duì)象采取什么動(dòng)作。再看上面的ls的輸出，自由訪問控制（DAC）權(quán)限表示所有的用戶都允許讀、執(zhí)行bash，但使用?SELinux，安全管理員可以進(jìn)一步指定允許執(zhí)行或讀取策略文件中的shell_exec_t類型文件的主體。比如說，安全工程師不許web服務(wù)器執(zhí)行shell，因?yàn)閣eb服務(wù)器易受遠(yuǎn)程攻擊。

SELinux使用擴(kuò)展屬性實(shí)現(xiàn)的副作用是，對(duì)于那些不支持?jǐn)U展屬性的文件系統(tǒng)中對(duì)象無法保護(hù)，比如掛載NFSv4版本的NFS文件系統(tǒng)。

由于SELinux的復(fù)雜性和強(qiáng)大功能，可以參考Red Hat’s SELinux User’s and Administrator’s Guide獲取更多信息。

SMACK – 簡化的強(qiáng)制訪問控制

與SELinux一樣，SMACK也是基于文件擴(kuò)展屬性的MAC實(shí)現(xiàn)，是開發(fā)者合并到Linux內(nèi)核中的第二個(gè)LSM模塊（2.6.24）。但是與SELinux不一樣的是，SMACK是專為嵌入式系統(tǒng)設(shè)計(jì)的，對(duì)于系統(tǒng)管理員來說更簡單。SMACK是車級(jí)Linux（AGL）和Tizen操作系統(tǒng)的默認(rèn)MAC實(shí)現(xiàn)。

APPARMOR

AppArmor是另一種MAC實(shí)現(xiàn)，最初由Immunix開發(fā)，2.6.36版本合入內(nèi)核。AppArmor是基于?Debian的系統(tǒng)的主要MAC實(shí)現(xiàn)。

除了減少了工具數(shù)量和復(fù)雜性之外，AppArmor和SELinux最大的不同就是，它是基于Path而不是基于屬性。

基于Path的實(shí)現(xiàn)有利有弊。積極的一面是，基于Path的策略可以保護(hù)任何文件系統(tǒng)的文件，因?yàn)榇鎯?chǔ)安全信息不需要擴(kuò)展屬性。甚至可以為不存在的文件指定安全規(guī)則，因?yàn)檫@種方式下，可以將Path存儲(chǔ)在配置文件中而無需標(biāo)注任何實(shí)際的文件或目錄。另一方面，最常被提及的負(fù)面影響是，因?yàn)槟軌騽?chuàng)建硬鏈接，對(duì)于同一個(gè)物理文件可能存在多個(gè)Path。那么，單個(gè)文件的安全策略可能會(huì)因?yàn)椴煌腜ath而不同，這可能會(huì)導(dǎo)致安全漏洞。

TOMOYO

與AppArmor一樣，TOMOYO是另一個(gè)基于Path的MAC實(shí)現(xiàn)，Linux 2.6.30版本首次合入。TOMOYO是專為嵌入式系統(tǒng)設(shè)計(jì)的，允許安全管理員在測試時(shí)記錄所有的用戶進(jìn)程交互，從而根據(jù)開發(fā)、測試期間互相看見的進(jìn)程才能夠交互。如果使用了TOMOYO策略的系統(tǒng)，落入不可信的用戶或敵對(duì)環(huán)境中，用戶態(tài)進(jìn)程僅執(zhí)行那些之前允許的交互，簡化了策略生成。

LOADPIN

LoadPin，是一個(gè)次LSM模塊，Linux4.7版本合入，用以保證加載內(nèi)核的所有文件（內(nèi)核模塊、固件等）來自相同的文件系統(tǒng)，并期望這樣的文件系統(tǒng)是由只讀的設(shè)備提供。這旨在簡化從只讀設(shè)備啟動(dòng)的嵌入式系統(tǒng)，讓其無需對(duì)內(nèi)核模塊進(jìn)行簽名或檢查。

因?yàn)楹唵我子?，LoadPin能夠簡化某些類型的嵌入式系統(tǒng)的內(nèi)核免受惡意代碼攻擊的過程。

YAMA

Yama，Linux 3.4合入內(nèi)核的LSM模塊，旨在收集主內(nèi)核沒有處理的系統(tǒng)內(nèi)的DAC安全限制。目前，它支持縮小ptrace()系統(tǒng)調(diào)用的范圍，阻止通過已經(jīng)攻擊成功的用戶進(jìn)程作為跳板，從相同用戶的其它進(jìn)程中抽取敏感數(shù)據(jù)信息。

SAFESETID

SafeSetID是在Linux 5.1版本合入的一個(gè)LSM模塊，用來限制將UID/GID轉(zhuǎn)換成白名單中允許的那些UID/GID。

我認(rèn)為Linux內(nèi)核中對(duì)SafeSetID使用場景的描述是非常準(zhǔn)確的：

This can be used to allow a non-root program to transition to other untrusted uids without full blown?CAP_SETUID?capabilities. The non-root program would still need?CAP_SETUID?to do any kind of transition, but the additional restrictions imposed by this LSM would mean it is a “safer” version of?CAP_SETUID?since the non-root program cannot take advantage of?CAP_SETUID?to do any unapproved actions (e.g. setuid to uid 0 or create/enter new user namespace). The higher level goal is to allow for uid-based sandboxing of system services without having to give out?CAP_SETUID?all over the place just so that non-root programs can drop to even-lesser-privileged uids. This is especially relevant when one non-root daemon on the system should be allowed to spawn other processes as different uids, but its undesirable to give the daemon a basically-root-equivalent CAP_SETUID.

通俗的說就是，如果非特權(quán)程序想要生成具有不同uid的進(jìn)程時(shí)，無需賦予其CAP_SETUID能力，而是通過SafeSetID就可以修改uid。

—?Documentation/admin-guide/LSM/SafeSetID.rst

LOCKDOWN LSM

lockdown是Linux 5.4版本合入內(nèi)核的，實(shí)現(xiàn)對(duì)kernel的鎖定。啟用了lockdown功能后，就可以通過內(nèi)核命令行參數(shù)鎖定kernel，以便保護(hù)其完整性和機(jī)密性。當(dāng)設(shè)置lockdown為保護(hù)完整性，它的特性就不允許用戶空間修改kernel。這些特性包括：未簽名的內(nèi)核模塊加載，訪問/dev/{mem,kmem,port}，訪問/dev/efi_test，未簽名鏡像的執(zhí)行，休眠，直接PCI訪問，原始IO端口訪問，原始MSR訪問，修改ACPI表，直接PCMCIA CIS存儲(chǔ)，串行端口的重新配置，不安全的內(nèi)核模塊參數(shù)，不安全的MMIO內(nèi)存，以及debugfs訪問。當(dāng)設(shè)置lockdown為保護(hù)機(jī)密性時(shí)，所有的完整性保護(hù)都被啟用，另外還要禁止的功能有：用戶空間從正在運(yùn)行的內(nèi)核中提取潛在的機(jī)密信息，例如/proc/kcore訪問，使用kprobe和bpf讀取內(nèi)核RAM，perf?的不安全使用以及tracefs的使用。

lockdown可以通過SELinux、AppArmor、SMACK、或TOMOYO策略文件實(shí)現(xiàn)，這種基于靜態(tài)策略的獨(dú)立LSM策略文件的實(shí)現(xiàn)方式，意味著它可以跨平臺(tái)運(yùn)行，而無關(guān)于具體的MAC實(shí)現(xiàn)機(jī)制。

結(jié)論

LSM并不是專門設(shè)計(jì)用來阻止對(duì)進(jìn)程攻擊的工具。良好的編程實(shí)踐，配置管理和內(nèi)存安全的編程語言才是實(shí)現(xiàn)阻止攻擊的工具。但是，當(dāng)系統(tǒng)中運(yùn)行的程序存在漏洞時(shí)，LSM確實(shí)能夠阻止利用漏洞攻擊系統(tǒng)的其它組件。所以說，LSM是Linux系統(tǒng)縱深防御的重要一層，通過理解它們能夠提供什么保護(hù)，可以增加對(duì)保護(hù)系統(tǒng)的哪些部分以及如何實(shí)現(xiàn)這些保護(hù)有一個(gè)更好的理解。

　　審核編輯：湯梓紅