SEAndroid安全機(jī)制框架分析報(bào)告

1、 范文范例 指導(dǎo)參考 SEAndroid安全機(jī)制框架分析 SEAndroid安全機(jī)制所要保護(hù)的對(duì)象是系統(tǒng)中的資源，這些資源分布在各個(gè)子系統(tǒng)中，例 如我們經(jīng)常接觸的文件就是分布文件子系統(tǒng)中的。 實(shí)際上 ，系統(tǒng)中需要保護(hù)的資源非常 多，除了前面說的文件之外，還有進(jìn)程 、socket 和 IPC 等等 。 對(duì)于 Android系統(tǒng)來說 ，由 于使用了與傳統(tǒng)Linux 系統(tǒng)不一樣的用戶空間運(yùn)行時(shí)，即應(yīng)用程序運(yùn)行時(shí)框架，因此它在 用戶空間有一些特有的資源是需要特別保護(hù)的，例如系統(tǒng)屬性的設(shè)置。 接下來 ，我們就通過圖1 來觀察 SEAndroid 安全機(jī)制的整體框架，如下所示 ： 從圖 1 可以看到 ，以

2、 SELinux 文件系統(tǒng)接口為邊界， SEAndroid 安全機(jī)制包含有內(nèi)核空間和 word 版整理 范文范例 指導(dǎo)參考 用戶空間兩部分支持。 在內(nèi)核空間 ，主要涉及到一個(gè)稱為SELinux LSM 的模塊 。而在用戶 空間中 ，涉及到 Security Context、 Security Server和 SEAndroid Policy等模塊 。 這些內(nèi)核 空間模塊和用戶空間模塊的作用以及交互如下所示： 1. 內(nèi)核空間的SELinux LSM 模塊負(fù)責(zé)內(nèi)核資源的安全訪問控制。 2. 用戶空間的SEAndroid Policy描述的是資源安全訪問策略。系統(tǒng)在啟動(dòng)的時(shí) 候，用戶空間的Secur

3、ity Server需要將這些安全訪問策略加載內(nèi)核空間的SELinux LSM 模 塊中去 。 這是通過 SELinux 文件系統(tǒng)接口實(shí)現(xiàn)的。 3. 用戶空間的Security Context描述的是資源安全上下文。SEAndroid的安全訪 問策略就是在資源的安全上下文基礎(chǔ)上實(shí)現(xiàn)的。 4. 用戶空間的Security Server一方面需要到用戶空間的Security Context去檢索 對(duì)象的安全上下文，另一方面也需要到內(nèi)核空間去操作對(duì)象的安全上下文。 5. 用戶空間的 selinux 庫封裝了對(duì) SELinux 文件系統(tǒng)接口的讀寫操作 。 用戶空間的 Security Server訪問

4、內(nèi)核空間的SELinux LSM 模塊時(shí) ，都是間接地通過selinux 進(jìn)行的 。 這 樣可以將對(duì)SELinux 文件系統(tǒng)接口的讀寫操作封裝成更有意義的函數(shù)調(diào)用。 6. 用戶空間的Security Server到用戶空間的Security Context去檢索對(duì)象的安全 上下文時(shí) ，同樣也是通過selinux 庫來進(jìn)行的 。 接下來 ，我們就從內(nèi)核空間和用戶空間兩個(gè)角度來分析SEAndroid安全機(jī)制框架 。 一 . 內(nèi)核空間 word 版整理 范文范例 指導(dǎo)參考 在內(nèi)核空間中 ，存在一個(gè)SELinux LSM 模塊，這個(gè)模塊包含有一個(gè)訪問向量緩沖 （Access Vector Cache）

5、和一個(gè)安全服務(wù)（ Security Server）。 Security Server負(fù)責(zé)安全 訪問控制邏輯 ，即由它來決定一個(gè)主體訪問一個(gè)客體是否是合法的。這里說的主體一般就 是指進(jìn)程 ，而客體就是主體要訪問的資源，例如文件 。 與 SELinux Security Server相關(guān)的一個(gè)內(nèi)核子模塊是LSM ，全稱是 Linux Security Model 。 LSM 可以說是為了SELinux 而設(shè)計(jì)的 ，但是它是一個(gè)通用的安全模塊， SELinux 可 以使用 ，其它的模塊也同樣可以使用。這體現(xiàn)了Linux 內(nèi)核模塊的一個(gè)重要設(shè)計(jì)思想，只 提供機(jī)制實(shí)現(xiàn)而不提供策略實(shí)現(xiàn)。 在我們這個(gè)例子中

6、， LSM 實(shí)現(xiàn)的就是機(jī)制，而 SELinux 就是在這套機(jī)制下的一個(gè)策略實(shí)現(xiàn)。 也就是說 ，你也可以通過LSM 來實(shí)現(xiàn)自己的一套MAC 安全機(jī)制 。 SELinux、 LSM 和內(nèi)核中的子系統(tǒng)是如何交互的呢？首先 ，SELinux 會(huì)在 LSM 中注 冊(cè)相應(yīng)的回調(diào)函數(shù)。其次 ， LSM 會(huì)在相應(yīng)的內(nèi)核對(duì)象子系統(tǒng)中會(huì)加入一些Hook 代碼 。 例 如，我們調(diào)用系統(tǒng)接口read 函數(shù)來讀取一個(gè)文件的時(shí)候，就會(huì)進(jìn)入到內(nèi)核的文件子系統(tǒng) 中。在文件子系統(tǒng)中負(fù)責(zé)讀取文件函數(shù)vfs_read 就會(huì)調(diào)用 LSM 加入的 Hook 代碼 。這些 Hook 代碼就會(huì)調(diào)用之前SELinux 注冊(cè)進(jìn)來的回調(diào)函數(shù)，以

7、便后者可以進(jìn)行安全檢查。 SELinux 在進(jìn)行安全檢查的時(shí)候，首先是看一下自己的Access Vector Cache是否 已經(jīng)有結(jié)果 。 如果有的話 ，就直接將結(jié)果返回給相應(yīng)的內(nèi)核子系統(tǒng)就可以了。如果沒有的 話，就需要到 Security Server中去進(jìn)行檢查 。 檢查出來的結(jié)果在返回給相應(yīng)的內(nèi)核子系統(tǒng) 的同時(shí) ，也會(huì)保存在自己的Access Vector Cache中，以便下次可以快速地得到檢查結(jié)果。 上面描述的安全訪問控制流程可以通過圖2來總結(jié) ，如下所示 ： word 版整理 范文范例 指導(dǎo)參考 從圖 2可以看到 ，內(nèi)核中的資源在訪問的過程中，一般需要獲得三次檢查通過： 1. 一

8、般性錯(cuò)誤檢查 ，例如訪問的對(duì)象是否存在 、訪問參數(shù)是否正確等 。 2. DAC 檢查，即基于 Linux UID/GID的安全檢查 。 3. SELinux 檢查 ，即基于安全上下文和安全策略的安全檢查。 二 . 用戶空間 在用戶空間中 ， SEAndroid包含有三個(gè)主要的模塊，分別是安全上下文（ Security Context ）、 安全策略 （ SEAndroid Policy）和安全服務(wù) （Security Server）。接下來我們 word 版整理 范文范例 指導(dǎo)參考 就分別對(duì)它們進(jìn)行描述。 1. 安全上下文 SEAndroid是一種基于安全策略的MAC 安全機(jī)制 。這種安全策略

9、又是建立在對(duì)象 的安全上下文的基礎(chǔ)上的。 這里所說的對(duì)象分為兩種類型，一種稱主體 （ Subject ）， 一種 稱為客體 （Object ）。 主體通常就是指進(jìn)程，而客觀就是指進(jìn)程所要訪問的資源，例如文 件、系統(tǒng)屬性等 。 安全上下文實(shí)際上就是一個(gè)附加在對(duì)象上的標(biāo)簽（ Tag）。 這個(gè)標(biāo)簽實(shí)際上就是一 個(gè)字符串 ，它由四部分內(nèi)容組成，分別是 SELinux 用戶 、 SELinux 角色、類型、安全級(jí)別 ， 每一個(gè)部分都通過一個(gè)冒號(hào)來分隔，格式為 “user:role:type:sensitivity”。 例如 ，在開啟了SEAndroid 安全機(jī)制的設(shè)備上執(zhí)行帶-Z 選項(xiàng)的 ls 命令 ，

10、就可以看 到一個(gè)文件的安全上下文： 上面的命令列出文件/init.rc的安全上下文為“u:object_r:rootfs:s0這”表，明文件 /init.rc的 SELinux 用戶 、SELinux 角色 、類型和安全級(jí)別分別為u 、 object_r 、 rootfs和 s0。 又如 ，在開啟了SEAndroid 安全機(jī)制的設(shè)備上執(zhí)行帶-Z 選項(xiàng)的 ps 命令，就可以看 到一個(gè)進(jìn)程的安全上下文： word 版整理 范文范例 指導(dǎo)參考 上面的命令列出進(jìn)程init的安全上下文為“u:r:init:s0這”表，明進(jìn)程init的 SELinux 用戶 、 SELinux 角色 、類型和安全級(jí)別分別

11、為u、 r、 init 和 s0。 在安全上下文中，只有類型 （Type ）才是最重要的， SELinux 用戶 、 SELinux 角色 和安全級(jí)別都幾乎可以忽略不計(jì)的。 正因?yàn)槿绱?， SEAndroid 安全機(jī)制又稱為是基于TE （Type Enforcement）策略的安全機(jī)制。不過為了方便理解安全上下文，接下來我們還是 簡單地對(duì) SELinux 用戶 、SELinux 角色和安全級(jí)別的作用進(jìn)行介紹。 對(duì)于進(jìn)程來說 ， SELinux 用戶和 SELinux 角色只是用來限制進(jìn)程可以標(biāo)注的類型。 而對(duì)于文件來說， SELinux 用戶和 SELinux 角色就可以完全忽略不計(jì)。為了完整

12、地描述一個(gè) 文件的安全上下文，通常將它的SELinux 角色固定為object_r ，而將它的 SELinux 用戶設(shè)置 為創(chuàng)建它的進(jìn)程的SELinux 用戶 。 在 SEAndroid 中，只定義了一個(gè)SELinux 用戶 u，因此我們通過ps -Z 和 ls -Z 命令 看到的所有的進(jìn)程和文件的安全上下文中的SELinux 用戶都為 u 。 同時(shí) ， SEAndroid 也只定 義了一個(gè) SELinux 角色 r，因此 ，我們通過ps -Z 命令看到的所有進(jìn)程的安全上下文中的 SELinux 角色都為r 。 通過 external/sepolicy/users和 external/sepo

13、licy/roles文件的內(nèi)容 ，我們就可以看 到 SEAndroid 所定義的 SELinux 用戶和 SELinux 角色 。 文件 external/sepolicy/users的內(nèi)容如下所示： 上述語句聲明了一個(gè)SELinux 用戶 u，它可用的SELinux 角色為 r ，它的默認(rèn)安全級(jí)別為 word 版整理 范文范例 指導(dǎo)參考 s0，可用的安全級(jí)別范圍為s0mls_systemhigh，其中 ， mls_systemhigh為系統(tǒng)定義的最 高安全級(jí)別 。 文件 external/sepolicy/roles的內(nèi)容如下所示： 第一個(gè)語句聲明了一個(gè)SELinux 角色 r；第二個(gè)語句允

14、許SELinux 角色 r 與類型 domain關(guān) 聯(lián)。 上面提到 ，對(duì)于進(jìn)程來說， SELinux 用戶和 SELinux 角色只是用來限制進(jìn)程可以標(biāo) 注的類型 ，這是如何體現(xiàn)的呢？以前面列出的external/sepolicy/users和 external/sepolicy/roles文件內(nèi)容為例 ，如果沒有出現(xiàn)其它的user 或者 role 聲明，那么就意 味著只有 u 、 r 和 domain可以組合在一起形成一個(gè)合法的安全上下文，而其它形式的安全 上下文定義均是非法的。 前面通過ps -Z 命令看到進(jìn)程init 的安全上下文為“ u:r:init:s0按照上”面，的分析， 這是不是

15、一個(gè)非法的安全上下文呢？答案是否定的 ，因?yàn)樵诹硗庖粋€(gè)文件 external/sepolicy/init.te中，通過 type 語句聲明了類型init ，并且將 domain設(shè)置為類型 init 的屬性 ，如下所示 ： 由于init具有屬性domain ，因此它就可以像domain一樣，可以和SELinux 用戶u 和 SELinux 角色組合在一起形成合法的安全上下文。 word 版整理 范文范例 指導(dǎo)參考 關(guān)于 SELinux 用戶和 SELinux 角色，我們就介紹到這里，接下來我們?cè)俳榻B安全級(jí) 別。安全級(jí)別實(shí)際上也是一個(gè)MAC 安全機(jī)制 ，它是建立在TE 的基礎(chǔ)之上的 。 在 SEL

16、inux 中，安全級(jí)別是可選的，也就是說 ，可以選擇啟用或者不啟用。 安全級(jí)別最開始的目的是用來對(duì)美國政府分類文件進(jìn)行訪問控制的。在基于安全級(jí) 別的 MAC 安全機(jī)制中 ，主體 （ subject ）和客體 （ object ）都關(guān)聯(lián)有一個(gè)安全級(jí)別。其中 ， 安全級(jí)別較高的主體可以讀取安全級(jí)別較低的客體，而安全級(jí)別較低的主體可以寫入安全 級(jí)別較高的客體。前者稱為 “read down ”，而后者稱為 “write up”通。過這種規(guī)則，可以允 許數(shù)據(jù)從安全級(jí)別較低的主體流向安全級(jí)別較高的主體，而限制數(shù)據(jù)從安全級(jí)別較高的主 體流向安全級(jí)別較低的主體，從而有效地保護(hù)了數(shù)據(jù)。注意，如果主體和客體的安

17、全級(jí)別 是相同的 ，那么主體是可以對(duì)客體進(jìn)行讀和寫的。 通過圖 3 可以看到基于安全級(jí)別的MAC 安全機(jī)制的數(shù)據(jù)流向控制，如下所示 ： 在圖 3中，我們定義了兩個(gè)安全級(jí)別：PUBLIC 和 SECRET，其中， SECRET的安全級(jí)別高于 PUBLIC。 word 版整理 范文范例 指導(dǎo)參考 在實(shí)際使用中 ，安全級(jí)別是由敏感性（Sensitivity ）和類別 （ Category ）兩部分內(nèi) 容組成的 ，格式為 “sensitivity:category_set其”中， category_set是可選的 。 例如，假設(shè) 我們定義有s0、 s1兩個(gè) Sensitivity ，以 c0 、c1、

18、 c2 三個(gè) Category ，那么 “s0:c0,c1表”示的就 是 Sensitivity 為 s0、 Category 為 c0 和 c1的一個(gè)安全級(jí)別 。 介紹完成SELinux 用戶 、 SELinux 角色和安全級(jí)別之后，最后我們就介紹類型。在 SEAndroid 中，我們通常將用來標(biāo)注文件的安全上下文中的類型稱為file_type ，而用來標(biāo) 注進(jìn)程的安全上下文的類型稱為domain ，并且每一個(gè)用來描述文件安全上下文的類型都將 file_type設(shè)置為其屬性 ，每一個(gè)用來進(jìn)程安全上下文的類型都將domain設(shè)置為其屬性 。 將一個(gè)類型設(shè)置為另一個(gè)類型的屬性可以通過type 語

19、句實(shí)現(xiàn) 。 例如，我們前面提 到的用來描述進(jìn)程init 的安全策略的文件external/sepolicy/init.te，就使用以下的type 語 句來將類型domain設(shè)置類型init 的屬性 ： 這樣就可以表明init 描述的類型是用來描述進(jìn)程的安全上下文的。 同樣，如果我們查看另外一個(gè)文件external/sepolicy/file.te，可以看到App 數(shù)據(jù) 文件的類型聲明： 上述語句表明類型app_data_file具有屬性file_type ，即它是用來描述文件的安全上下文 的。 word 版整理 范文范例 指導(dǎo)參考 了解了 SEAndroid 安全機(jī)制的安全上下文之后，我們就可

20、以繼續(xù)Android系統(tǒng)中 的對(duì)象的安全上下文是如何定義的了。這里我們只討論四種類型的對(duì)象的安全上下文，分 別是 App 進(jìn)程 、 App 數(shù)據(jù)文件 、系統(tǒng)文件和系統(tǒng)屬性。這四種類型對(duì)象的安全上下文通過 四個(gè)文件來描述： mac_permissions.xml、 seapp_contexts、 file_contexts和 property_contexts，它們均位于external/sepolicy目錄中 。 文件 external/sepolicy/mac_permissions.xml的內(nèi)容如下所示： 文件 mac_permissions.xml給不同簽名的App 分配不同的seinf

21、o 字符串 ，例如，在 AOSP 源碼環(huán)境下編譯并且使用平臺(tái)簽名的App 獲得的 seinfo 為 “platform ”使，用第三方簽名安 裝的 App 獲得的 seinfo 簽名為 default 。 word 版整理 范文范例 指導(dǎo)參考 這個(gè) seinfo 描述的其實(shí)并不是安全上下文中的Type ，它是用來在另外一個(gè)文件 external/sepolicy/seapp_contexts中查找對(duì)應(yīng)的Type 的 。 文件 external/sepolicy/seapp_contexts的內(nèi)容如下所示： word 版整理 范文范例 指導(dǎo)參考 文件中的注釋解釋了如何在文件seapp_conte

22、xts查找對(duì)象的Type ，這里不再累述，只是舉 兩個(gè)例子來說明。 從前面的分析可知，對(duì)于使用平臺(tái)簽名的App 來說 ，它的 seinfo 為 “ platform用”。 戶空間的 Security Server在為它查找對(duì)應(yīng)的Type 時(shí)，使用的 user 輸入為 _app 。 這樣在 seapp_contexts文件中 ，與它匹配的一行即為： 這樣我們就可以知道，使用平臺(tái)簽名的App 所運(yùn)行在的進(jìn)程domain為 “platform_app ”，并 且它的數(shù)據(jù)文件的file_type 為 “platform_app_data_file”。 又如 ，使用第三方簽名的App 的 seinfo

23、為 “ default用戶”空。間的Security Server 在為它查找對(duì)應(yīng)的Type 時(shí)，使用的 user 輸入也為 _app 。 我們注意到 ，在 seapp_contexts 文件中 ，沒有一行對(duì)應(yīng)的user 和 seinfo 分別為 “_app和” “default ”但。是有一行是最匹配 word 版整理 范文范例 指導(dǎo)參考 的，即： 這 樣 我 們 就 可 以 知 道 ， 使 用 第 三 方 簽 名 的App所 運(yùn) 行 在 的 進(jìn) 程domain為 “ unstrusted_app并且”它，的數(shù)據(jù)文件的file_type 為 “ app_data_file”。 接下來我們?cè)賮?/p>

24、看系統(tǒng)文件的安全上下文是如何定義的。通過查看 external/sepolicy/file_contexts文件，我們就可以看到系統(tǒng)文件的安全上下文描述，如下 所示 ： 文件 file_contexts通過正則表達(dá)式來描述系統(tǒng)文件的安全上下文。例如，在上面列出的內(nèi) 容的最后三行中，倒數(shù)第三行的正則表達(dá)式表示在/system 目錄下的所有文件的安全上下 word 版整理 范文范例 指導(dǎo)參考 文均為 “u:object_r:system_file:s0最”后，兩行的正則表達(dá)式則表示文件/system/bin/ash和 /system/bin/mksh的安全上下文應(yīng)為“ u:object_r:she

25、ll_exec:s0雖然倒數(shù)第”三。行的正則表 達(dá)式描述的文件涵蓋后面兩個(gè)正則表達(dá)示描述的文件，但是后面兩個(gè)正則表達(dá)式描述的方 式更加具體 ，因此 /system/bin/ash和 /system/bin/mksh兩個(gè)文件的最終安全上下文都被 設(shè)置為 “u:object_r:shell_exec:s0”。 在 Android 系統(tǒng)中 ，有一種特殊的資源 屬性， App 通過讀寫它們能夠獲得相應(yīng)的信息 ，以及控制系統(tǒng)的行為 ，因此 ，SEAndroid 也需要對(duì)它們進(jìn)行保護(hù) 。這意味著 Android系統(tǒng)的屬性也需要關(guān)聯(lián)有安全上下文。這是通過文件 external/sepolicy/proper

26、ty_contexts來描述的 ，它的內(nèi)容如下所示： 屬性的安全上下文與文件的安全上下文是類似的，它們的 SELinux 用戶 、SELinux 角色和安 全級(jí)別均定義為u、 object_r 和 s0。 從上面列出的內(nèi)容可以看出，以 net. 開頭的幾個(gè)屬性， 以及所有以gsm. 開頭的屬性 、 persist.radio和 sys.usb.config屬性的安全上下文均被設(shè)置 為”u:object_r:radio_prop:s0“這。意味著只有有權(quán)限訪問Type 為 radio_prop的資源的進(jìn)程 才可以訪問這些屬性。 word 版整理 范文范例 指導(dǎo)參考 2. 安全策略 上面我們分析了

27、SEAndroid 安全機(jī)制中的對(duì)象安全上下文，接下來我們就繼續(xù)分析 SEAndroid 安全機(jī)制中的安全策略。 SEAndroid 安全機(jī)制中的安全策略是在安全上下文的 基礎(chǔ)上進(jìn)行描述的，也就是說 ，它通過主體和客體的安全上下文，定義主體是否有權(quán)限訪 問客體 。 前面提到 ，SEAndroid安全機(jī)制主要是使用對(duì)象安全上下文中的類型來定義安全策 略，這種安全策略就稱Type Enforcement，簡稱 TE。 在 external/sepolicy目錄中 ，所有 以.te 為后綴的文件經(jīng)過編譯之后，就會(huì)生成一個(gè)sepolicy 文件 。 這個(gè) sepolicy文件會(huì)打包 在 ROM 中，并

28、且保存在設(shè)備上的根目錄下，即它在設(shè)備上的路徑為/sepolicy 。 接下來 ，我們就通過app.te 文件的內(nèi)容來分析SEAndroid 安全機(jī)制為使使用平臺(tái)簽 名的 App 所定義的安全策略，相關(guān)的內(nèi)容如下所示： 前面在分析seapp_contexts文件的時(shí)候 ，我們提到 ，使用平臺(tái)簽名的App 所運(yùn)行在的進(jìn)程 的 domain指定為 platform_app。從上面列出的內(nèi)容可以看出， platform_app接下來會(huì) 通 過app_domain、 platform_app_domain、 net_domain、 bluetooth_domain和 word 版整理 范文范例 指導(dǎo)參考

29、 unconfined_domain宏分別加入到其它的domain中去，以便可以獲得相應(yīng)的權(quán)限。接下 來我們就以u(píng)nconfined_domain宏為例 ，分析 platform_app獲得了哪些權(quán)限。 宏 unconfined_domain 定義在文件 te_macros 文件中 ，如下所示 ： $1 引用的就是unconfined_domain的參數(shù) ，即 platform_app。通過接下來的兩個(gè) typeattribute語句 ，為 platform_app設(shè)置了 mlstrustedsubject和 unconfineddomain兩 個(gè)屬性 。 也就是說 ， mlstrusteds

30、ubject和 unconfineddomain這兩個(gè) Type 具有權(quán)限 ， platform_app這個(gè) Type 也具有 。 接下來我們主要分析unconfineddomain這個(gè) Type 具有 哪些權(quán)限 。 文件 unconfined.te定義了 unconfineddomain這個(gè) Type 所具有的權(quán)限 ，如下所 示： word 版整理 范文范例 指導(dǎo)參考 一個(gè) Type 所具有的權(quán)限是通過allow 語句來描述的 ，以下這個(gè)allow 語句： 表明 domain為 unconfineddomain的進(jìn)程可以與其它進(jìn)程進(jìn)行binder ipc通信 （call ）， 并且能夠向這些

31、進(jìn)程傳遞Binder 對(duì)象 （ transfer ），以及將自己設(shè)置為Binder 上下文管理 器（ set_context_mgr）。 注意， SEAndroid 使用的是最小權(quán)限原則，也就是說 ，只有通過 allow 語句聲明的 權(quán)限才是允許的，而其它沒有通過allow 語句聲明的權(quán)限都是禁止，這樣就可以最大限度 地保護(hù)系統(tǒng)中的資源。 如果我們繼續(xù)分析app.te 的內(nèi)容 ，會(huì)發(fā)現(xiàn)使用第三方簽名的App 所運(yùn)行在的進(jìn)程 同樣是加入到unconfineddomain這個(gè) domain的，如下所示 ： word 版整理 范文范例 指導(dǎo)參考 這是不是意味著使用平臺(tái)簽名和第三方簽名的App 所具有

32、的權(quán)限都是一樣的呢？答案是 否定的 。 雖然使用平臺(tái)簽名和第三方簽名的App 在 SEAndroid安全框架的約束下都具有 unconfineddomain這個(gè) domain所賦予的權(quán)限，但是別忘記 ，在進(jìn)行 SEAndroid安全檢查 之前 ，使用平臺(tái)簽名和第三方簽名的App 首先要通過DAC 檢查，也就是要通過傳統(tǒng)的 Linux UID/GID安全檢查 。 由于使用平臺(tái)簽名和第三方簽名的App 在安裝的時(shí)候分配到的 Linux UID/GID是不一樣的 ，因此就決定了它們所具有權(quán)限是不一樣的。 同時(shí)，這里使用平臺(tái)簽名和第三方簽名的App 之所以會(huì)同時(shí)被賦予 unconfineddomain

33、這個(gè) domain的權(quán)限 ，是因?yàn)榍懊嫖覀兎治龅腶pp.te 文件是來自于 Android 4.3的。 在 Android 4.3中， SEAndroid安全機(jī)制是試驗(yàn)性質(zhì)的，并且啟用的是 Permissive 模式 ，也就是即使主體違反了安全策略，也只是會(huì)發(fā)出警告，而不會(huì)真的拒絕 執(zhí)行 。 如果我們分析的是Android 4.4的 app.te 文件 ，就會(huì)發(fā)現(xiàn) ，使用第三方簽名的App 不再具有大部分unconfineddomain這個(gè) domain的權(quán)限 ，因?yàn)?Android 4.4的 SEAndroid 安全機(jī)制不再是試驗(yàn)性質(zhì)的，并且啟用的是Enforcing模式。 以上描述的就是基

34、于TE 的安全策略 ，它的核心思想就是最小權(quán)限原則，即主體對(duì) 客體擁有的權(quán)限必須要通過allow 語句定義才允許，否則的話 ，一切都是禁止的。 前面我們還提到， SEAndroid安全機(jī)制的安全策略經(jīng)過編譯后會(huì)得到一個(gè)sepolicy word 版整理 范文范例 指導(dǎo)參考 文件 ，并且最終保存在設(shè)備上的根據(jù)目錄下。注意 ，如果我們什么也不做，那么保存在這 個(gè) sepolicy 文件中的安全策略是不會(huì)自動(dòng)加載到內(nèi)核空間的SELinux LSM 模塊去的 。 它需 要我們?cè)谙到y(tǒng)啟動(dòng)的過程中進(jìn)行加載。 系統(tǒng)中第一個(gè)啟動(dòng)的進(jìn)程是init 進(jìn)程 。 我們知道 ，Init 進(jìn)程在啟動(dòng)的過程中，執(zhí)行 了很多

35、的系統(tǒng)初始化工作，其中就包括加載SEAndroid安全策略的工作，如下所示 ： 上述代碼定義在文件system/core/init/init.c中。 這里調(diào)用到了三個(gè)與SEAndroid相關(guān)的函數(shù) ： selinux_set_callback 、 selinux_android_load_policy和 selinux_init_all_handles，其中 ， selinux_set_callback和 selinux_android_load_policy來自于 libselinux ，而 selinux_init_all_handles也是定義在文件 word 版整理 范文范例 指導(dǎo)參考

36、 system/core/init/init.c中，并且它最終也是通過調(diào)用libselinux的函數(shù)來打開前面分析 file_contexts和 property_contexts文件 ，以便可以用來查詢系統(tǒng)文件和系統(tǒng)屬性的安全上 下文 。 函數(shù) selinux_set_callback用來向 libselinux設(shè)置 SEAndroid 日志和審計(jì)回調(diào)函數(shù)， 而函數(shù) selinux_android_load_policy則是用來加載安全策略到內(nèi)核空間的SELinux LSM 模 塊中去 。 我們重點(diǎn)關(guān)注函數(shù)selinux_android_load_policy的實(shí)現(xiàn) 。 函數(shù) selinux

37、_android_load_policy定義在文件external/libselinux/src/android.c， 它的實(shí)現(xiàn)如下所示： word 版整理 范文范例 指導(dǎo)參考 SELINUXMNT 、 OLDSELINUXMNT和SELINUXFS是 三 個(gè) 宏 ， 它 們 定 義 在 文 件 external/libselinux/src/policy.h文件中 ，如下所示 ： 回到函數(shù)selinux_android_load_policy中，我們不難發(fā)現(xiàn)它的實(shí)現(xiàn)邏輯如下所示： A. 以 /sys/fs/selinux為安裝點(diǎn) ，安裝一個(gè)類型為selinuxfs的文件系統(tǒng) ，也就是 SEL

38、inux 文件系統(tǒng) ，用來與內(nèi)核空間的SELinux LSM 模塊通信 。 B. 如果不能在 /sys/fs/selinux這個(gè)安裝點(diǎn)安裝SELinux 文件系統(tǒng) ，那么再以 /selinux為安裝點(diǎn) ，安裝 SELinux 文件系統(tǒng) 。 C. 成功安裝SELinux 文件系統(tǒng)之后 ，接下來就調(diào)用另外一個(gè)函數(shù) selinux_android_reload_policy來將 SEAndroid安全策略加載到內(nèi)核空間的SELinux LSM 模 塊中去 。 在較舊版本的Linux 系統(tǒng)中 ， SELinux 文件系統(tǒng)是以 /selinux為安裝點(diǎn)的 ，不過后 面較新的版本都是以/sys/fs/se

39、linux為安裝點(diǎn)的 ， Android系統(tǒng)使用的是后者。 函數(shù) selinux_android_reload_policy也是定義在文件 external/libselinux/src/android.c中，它的實(shí)現(xiàn)如下所示： word 版整理 范文范例 指導(dǎo)參考 函數(shù) selinux_android_reload_policy的執(zhí)行過程如下所示： word 版整理 范文范例 指導(dǎo)參考 A. 依次從 /data/security/current和根目錄尋找sepolicy文件，找到之后就打 開，獲得一個(gè)文件描述符fd 。 B. 通過文件描述符fd 將前面打開的sepolicy 文件的內(nèi)容映射

40、到內(nèi)存中來，并且 得到它的起始地址為map 。 C. 調(diào)用另外一個(gè)函數(shù)security_load_policy將已經(jīng)映射到內(nèi)存中的sepolicy 文件 內(nèi)容 ，即 SEAndroid安全策略 ，加載到內(nèi)核空間的SELinux LSM 模塊中去 。 D. 加載完成后 ，釋放 sepolicy文件占用的內(nèi)存，并且關(guān)閉sepolicy 文件 。 函數(shù) security_load_policy定義在文件external/libselinux/src/load_policy.c中， 它的實(shí)現(xiàn)如下所示： selinux_mnt是一個(gè)全局變量，它描述的是SELinux 文件系統(tǒng)的安裝點(diǎn)。在我們這個(gè)情景 w

41、ord 版整理 范文范例 指導(dǎo)參考 中，它的值就等于/sys/fs/selinux。 函數(shù) security_load_policy的實(shí)現(xiàn)很簡單 ，它首先打開 /sys/fs/selinux/load文件 ， 然后將參數(shù)data 所描述的安全策略寫入到這個(gè)文件中去。由于 /sys/fs/selinux是由內(nèi)核空 間的 SELinux LSM 模塊導(dǎo)出來的文件系統(tǒng)接口，因此當(dāng)我們將安全策略寫入到位于該文件 系統(tǒng)中的 load 文件時(shí) ，就相當(dāng)于是將安全策略從用戶空間加載到SELinux LSM 模塊中去 了。以后 SELinux LSM 模塊中的Security Server就可以通過它來進(jìn)行安

42、全檢查。 3. Security Server 用戶空間的Security Server主要是用來保護(hù)用戶空間資源的，以及用來操作內(nèi)核 空間對(duì)象的安全上下文的，它由應(yīng)用程序安裝服務(wù)PackageManagerService、應(yīng)用程序安 裝守護(hù)進(jìn)程installd 、應(yīng)用程序進(jìn)程孵化器Zygote 進(jìn)程以及 init 進(jìn)程組成 。其中 ， PackageManagerService和 installd負(fù)責(zé)創(chuàng)建 App 數(shù)據(jù)目錄的安全上下文， Zygote 進(jìn)程負(fù) 責(zé)創(chuàng)建 App 進(jìn)程的安全上下文，而 init 進(jìn)程負(fù)責(zé)控制系統(tǒng)屬性的安全訪問。 應(yīng)用程序安裝服務(wù)PackageManagerService在啟動(dòng)的時(shí)候 ，會(huì)在 /etc/security目 錄中找到我們前面分析的mac_permissions.xml文件 ，然后對(duì)它進(jìn)行解析，得到 App 簽名 或者包名與seinfo 的對(duì)應(yīng)關(guān)系 。 當(dāng) PackageManagerService安裝 App 的時(shí)候 ，它就會(huì)根據(jù) 其簽名或者包名查找到對(duì)應(yīng)的seinfo ，并且將這個(gè)seinfo 傳遞給另外一個(gè)守護(hù)進(jìn)程 installed 。 守護(hù)進(jìn)程installd 負(fù)責(zé)創(chuàng)建 App 數(shù)據(jù)目錄 。 在創(chuàng)建 App 數(shù)據(jù)目錄的時(shí)候，需要給 它設(shè)置安全上下文，使得 SEAndroid安全機(jī)制可以對(duì)