http://blog.csdn.net/innost/article/details/19299937
一 SELinux背景知識
1. DAC和MAC
SELinux出現之前，Linux上的安全模型叫DAC，全稱是Discretionary Access Control，翻譯爲自主訪問控制。DAC的核心思想很簡單，就是：
進程理論上所擁有的權限與執行它的用戶的權限相同。比如，以root用戶啓動Browser，那麼Browser就有root用戶的權限，在Linux系統上能幹任何事情。
顯然，DAC太過寬鬆了，所以各路高手想方設法都要在Android系統上搞到root權限。那麼SELinux如何解決這個問題呢？原來，它在DAC之外，設計了一個新的安全模型，叫MAC（Mandatory Access Control），翻譯爲強制訪問控制。MAC的處世哲學非常簡單：即任何進程想在SELinux系統中幹任何事情，都必須先在安全策略配置文件中賦予權限。凡是沒有出現在安全策略配置文件中的權限，進程就沒有該權限。來看一個SEAndroid中設置權限的
[例子1]
/*
from external/sepolicy/netd.te
下面這條SELinux語句表示 允許（allow ）netd域（domain）中的進程 ”寫（write）“
類型爲proc的文件
注意，SELinux中安全策略文件有自己的一套語法格式，下文我們將詳細介紹它
*/
allow netd proc:file write
如果沒有在netd.te中使用上例中的權限配置allow語句，則netd就無法往/proc目錄下得任何文件中寫數據，即使netd具有root權限。
顯然，MAC比DAC在權限管理這一塊要複雜，要嚴格，要細緻得多。
那麼，關於DAC和MAC，此處筆者總結了幾個知識點：
Linux系統先做DAC檢查。如果沒有通過DAC權限檢查，則操作直接失敗。通過DAC檢查之後，再做MAC權限檢查。
SELinux中也有用戶的概念，但它和Linux中原有的user概念不是同一個東西。什麼意思呢？比如，Linux中的超級用戶root在SELinux中可能就是一個沒權限，沒地位，打打醬油的”路人甲“。當然，這一切都由SELinux安全策略的制定者來決定。
2. SELinux Policy語言介紹
Linux中有兩種東西，一種死的（Inactive），一種活的（Active）。死的東西就是文件（Linux哲學，萬物皆文件。注意，萬不可狹義解釋爲File），而活的東西就是進程。此處的“死”和“活”是一種比喻，映射到軟件層面的意思是：進程能發起動作，例如它能打開文件並操作它。而文件只能被進程操作。
SELinux中，每種東西都會被賦予一個安全屬性，官方說法叫Security Context。Security Context（以後用SContext表示）是一個字符串，主要由三部分組成。例如SEAndroid中，進程的SContext可通過ps -Z命令查看，如圖1所示：
LABEL USER PID PPID VSIZE RSS WCHAN PC NAME
u:r:mediacodec:s0 mediacodec 2884 1 25200 6496 binder_thr b0d87968 S media.codec
u:r:mediadrmserver:s0 media 2885 1 25628 7476 binder_thr b40de968 S /system/bin/mediadrmserver
u:r:mediaextractor:s0 mediaex 2886 1 47532 7400 binder_thr b1446968 S media.extractor
u:r:mediaserver:s0 media 2887 1 139856 23384 binder_thr a4865968 S /system/bin/mediaserver
u:r:netd:s0 root 2888 1 27560 3440 binder_thr b0aee968 S /system/bin/netd
u:r:remotedisplay:s0 remotedisplay 2890 1 25548 7432 binder_thr a824b968 S /system/bin/remotedisplay
圖1中最左邊的那一列是進程的SContext，以第一個進程/system/bin/remotedisplay的SContext爲例，其值爲u:r:remotedisplay:s0，其中：
u爲user的意思。SEAndroid中定義了一個SELinux用戶，值爲u。
r爲role的意思。role是角色之意，它是SELinux中一種比較高層次，更方便的權限管理思路，即Role Based Access Control（基於角色的訪問控制，簡稱爲RBAC）。簡單點說，一個u可以屬於多個role，不同的role具有不同的權限。RBAC我們到最後再討論。
init，代表該進程所屬的Domain爲init。MAC的基礎管理思路其實不是針對上面的RBAC，而是所謂的Type Enforcement Accesc Control（簡稱TEAC，一般用TE表示）。對進程來說，Type就是Domain。比如init這個Domain有什麼權限，都需要通過[例子1]中allow語句來說明。
S0和SELinux爲了滿足軍用和教育行業而設計的Multi-Level Security（MLS）機制有關。簡單點說，MLS將系統的進程和文件進行了分級，不同級別的資源需要對應級別的進程才能訪問。後文還將詳細介紹MLS。
文件的SContext，讀者可通過ls -Z來查看，如圖2所示
圖2中，倒數第二列所示爲Nexus 7根目錄下幾個文件和目錄的SContext信息，以第一行root目錄爲例，其信息爲u:object_r:rootfs:s0：
u：同樣是user之意，它代表創建這個文件的SELinux user。
object_r：文件是死的東西，它沒法扮演角色，所以在SELinux中，死的東西都用object_r來表示它的role。
rootfs：死的東西的Type，和進程的Domain其實是一個意思。它表示root目錄對應的Type是rootfs。
s0：MLS的級別。
根據SELinux規範，完整的SContext字符串爲：
user:role:type[:range]
注意，方括號中的內容表示可選項。s0屬於range中的一部分。下文再詳細介紹range所代表的Security Level相關的知識。
看，SContext的核心其實是前三個部分：user:role:type。
剛纔說了，MAC基本管理單位是TEAC（Type Enforcement Accesc Control），然後是高一級別的Role Based Accesc Control。RBAC是基於TE的，而TE也是SELinux中最主要的部分。
下面來看看TE。
2.1 TE介紹
在例子1中，大家已經見過TE的allow語句了，再來細緻研究下它：
[例子2]
allow netd proc:file write
這條語句的語法爲：
allow：TE的allow語句，表示授權。除了allow之外，還有allowaudit、dontaudit、neverallow等。
netd：source type。也叫subject，domain。
proc：target type。它代表其後的file所對應的Type。
file：代表Object Class。它代表能夠給subject操作的一類東西。例如File、Dir、socket等。在Android系統中，有一個其他Linux系統沒有的Object Class，那就是Binder。
write：在該類Object Class中所定義的操作。
根據SELinux規範，完整的allow相關的語句格式爲：
rule_name source_type target_type : class perm_set
我們直接來看幾個實例：
[例子3]
//SEAndroid中的安全策略文件policy.conf
#允許zygote域中的進程向init type的進程（Object Class爲process）發送sigchld信號
allow zygote init:process sigchld;
#允許zygote域中的進程search或getattr類型爲appdomain的目錄。注意，多個perm_set
#可用{}括起來
allow zygote appdomain:dir { getattr search };
#來個複雜點的：
#source_type爲unconfineddomain target_type爲一組type，由
#{ fs_type dev_type file_type }構成。object_class也包含兩個，爲{ chr_file file }
#perm_set語法比較奇特，前面有一個~號。它表示除了{entrypoint relabelto}之外，{chr_file #file}這兩個object_class所擁有的其他操作
allow unconfineddomain {fs_type dev_type file_type}:{ chr_file file } \
~{entrypoint relabelto};
#特殊符號除了~外，還有-號和*號，其中：
# 1）：-號表示去除某項內容。
# 2）：*號表示所有內容。
#下面這條語句中，source_type爲屬於appdomain，但不屬於unconfinedomain的進程。
#而 *表示所有和capability2相關的權限
#neverallow：表示絕不允許。
neverallow { appdomain -unconfineddomain } self:capability2 *;
特別注意，前面曾提到說權限必須顯示聲明，沒有聲明的話默認就沒有權限。那neverallow語句就沒必要存在了。因爲”無權限“是不需要聲明的。確實如此，neverallow語句的作用只是在生成安全策略文件時進行檢查，判斷是否有違反neverallow語句的allow語句
下面我們來看上述allow語句中所涉及到的object class和perm set。
（1） Object class和Perm Set
Object class很難用語言說清楚它到底是怎麼定義的，所以筆者也不廢話，直接告訴大家常見的Object class有哪些。見下面的SEPolicy示例：
[system/sepolicy/security_classes示例]
.......
#此文件定義了Android平臺中支持的Object class
#根據SELinux規範，Object Class類型由class關鍵字申明
# file-related classes
class filesystem
class file #代表普通文件
class dir #代表目錄
class fd #代表文件描述符
class lnk_file #代表鏈接文件
class chr_file #代表字符設備文件
......
# Service manager
class service_manager # userspace
#Android平臺特有的屬性服務。注意其後的userspace這個詞
class property_service # userspace和用戶空間中的SELinux權限檢查有關，下文再解釋
上述示例展示了SEAndroid中Object Class的定義，其中：
Object Class需要通過class語句申明。這些申明一般放在一個叫security_class的文件中。
另外，這些class和kernel中相關模塊緊密結合。
再來看Perm set。Perm set指得是某種Object class所擁有的操作。以file這種Object class而言，其擁有的Perm set就包括read，write，open，create,execute等。
和Object class一樣，SELinux或SEAndroid所支持的Perm set也需要聲明，來看下面的例子：
[external/sepolicy/access_vectors]
#SELinux規範中，定義perm set有兩種方式，一種是使用下面的common命令
#其格式爲：common common_name { permission_name ... } common定義的perm set能
#被另外一種perm set命令class所繼承
#以下是Android平臺中，file對應的權限（perm set）。其大部分權限讀者能猜出是幹什麼的。
#有一些權限需要結合文後的參考文獻來學習
class service_manager
{
add
find
list
}
（2） type，attribute和allow等
現在再來看type的定義，和type相關的命令主要有三個，如下面的例子所示：
[external/sepolicy相關文件]
#type命令的完整格式爲：type type_id [alias alias_id,] [attribute_id]
#其中，方括號中的內容爲可選。alias指定了type的別名，可以指定多個別名。
#下面這個例子定義了一個名爲shell的type，它和一個名爲domain的屬性（attribute）關聯
type shell, domain; #本例來自shell.te，注意，可以關聯多個attribute
#屬性由attribute關鍵字定義，如attributes文件中定義的SEAndroid使用的屬性有：
attribute domain
attribute file_type
#可以在定義type的時候，直接將其和某個attribute關聯，也可以單獨通過
#typeattribue將某個type和某個或多個attribute關聯起來，如下面這個例子
#將前面定義的system類型和mlstrustedsubject屬性關聯了起來
typeattribute system mlstrustedsubject
特別注意：對初學者而言，attribute和type的關係最難理解，因爲“attribute”這個關鍵詞實在是沒取好名字，很容易產生誤解：
實際上，type和attribute位於同一個命名空間，即不能用type命令和attribute命令定義相同名字的東西。
其實，attribute真正的意思應該是類似type（或domain） group這樣的概念。比如，將type A和attribute B關聯起來，就是說type A屬於group B中的一員。
使用attribute有什麼好處呢？一般而言，系統會定義數十或數百個Type，每個Type都需要通過allow語句來設置相應的權限，這樣我們的安全策略文件編起來就會非常麻煩。有了attribute之後呢，我們可以將這些Type與某個attribute關聯起來，然後用一個allow語句，直接將source_type設置爲這個attribute就可以了：
這也正是type和attribute位於同一命名空間的原因。
這種做法實際上只是減輕了TE文件編寫者的煩惱，安全策略文件在編譯時會將attribute拓展爲其包含的type。如例子4所示：
[例子4]
#定義兩個type，分別是A_t和B_t，它們都管理到attribute_test
type A_t attribute_test;
type B_t attribute_test;
#寫一個allow語句，直接針對attribute_test
allow attribute_test C_t:file {read write};
#上面這個allow語句在編譯後的安全策略文件中會被如下兩條語句替代：
allow A_t C_t:file {read write};
allow B_t C_t:file {read write};
前面講過，TE的完整格式爲：
rule_name source_type target_type : class perm_set
所以，attribute可以出現在source_type中，也可以出現在target_type中。
提示：一般而言，定義type的時候，都會在名字後添加一個_t後綴，例如type system_t。而定義attribute的時候不會添加任何後綴。但是Android平臺沒使用這個約定俗成的做法。不過沒關係，SEAndroid中定義的attribute都在external/sepolicy/attribute這個文件中，如果分不清是type還是attribute，則可以查看這個文件中定義了哪些attribute。
最後我們來看看TE中的rule_name，一共有四種：
allow：賦予某項權限。
allowaudit：audit含義就是記錄某項操作。默認情況下是SELinux只記錄那些權限檢查失敗的操作。allowaudit則使得權限檢查成功的操作也被記錄。注意，allowaudit只是允許記錄，它和賦予權限沒關係。賦予權限必須且只能使用allow語句。dontaudit：對那些權限檢查失敗的操作不做記錄。neverallow：前面講過，用來檢查安全策略文件中是否有違反該項規則的allow語句。如例子5所示：
[例子5]
#來自external/sepolicy/netd.te文件
#永遠不允許netd域中的進程 讀寫 dev_type類型的 塊設備文件（Object class爲blk_file）
neverallow netd dev_type:blk_file { read write }
3） RBAC和constrain
絕大多數情況下，SELinux的安全配置策略需要我們編寫各種各樣的xx.te文件。由前文可知，.te文件內部應該包含包含了各種allow，type等語句了。這些都是TEAC，屬於SELinux MAC中的核心組成部分。
在TEAC之上，SELiunx還有一種基於Role的安全策略，也就是RBAC。RBAC到底是如何實施相關的權限控制呢？我們先來看SEAndroid中Role和User的定義。
[external/sepolicy/roles]
#Android中只定義了一個role，名字就是r
role r;
#將上面定義的r和attribute domain關聯起來
role r types domain;
再來看user的定義。
[external/sepolicy/users]
#支持MLS的user定義格式爲：
#user seuser_id roles role_id level mls_level range mls_range;
#不支持MLS user定義格式爲：
#user seuser_id roles role_id;
#SEAndroid使用了支持MLS的格式。下面定義的這個user u，將和role r關聯。
#注意，一個user可以和多個role關聯。
#level之後的是該user具有的安全級別。s0爲最低級，也就是默認的級別，mls_systemHigh
#爲u所能獲得的最高安全級別（security level）。此處暫且不表MLS
user u roles { r } level s0 range s0 - mls_systemhigh;
那麼，Roles和User中有什麼樣的權限控制呢？
1）首先，我們應該允許從一個role切換（SELinux用Transition表達切換之意）到另外一個role，例如：
#注意，關鍵字也是allow，但它和前面TE中的allow實際上不是一種東西
#下面這個allow允許from_role_id切換到to_role_id
allow from_role_id to_role_id;
2) 角色之間的關係。SELinux中，Role和Role之間的關係和公司中的管理人員的層級關係類似，例如：
#dominance語句屬於deprecated語句，MLS中有新的定義層級相關的語句。不過此處要介紹的是
#selinux中的層級關係
#下面這句話表示super_r dominate（統治，關鍵詞dom） sysadm_r和secadm_r這兩個角色
#反過來說，sysadm_r和secadm_r dominate by (被統治，關鍵詞 domby) super_r
#從type的角度來看，super_r將自動繼承sysadm_r和secadm_r所關聯的type（或attribute）
dominance { role super_r {role sysadm_r; role secadm_r; }
3）其他內容，由於SEAndroid沒有使用，此處不表。讀者可閱讀後面的參考文獻。
話說回來，怎麼實現基於Role或User的權限控制呢？SELinux提供了一個新的關鍵詞，叫constrain，來看下面這個例子：
關於constrain，再補充幾個知識點：
SEAndroid中沒有使用constrain，而是用了MLS中的mlsconstrain。所以下文將詳細介紹它。
constrain是對TEAC的加強。因爲TEAC僅針對Type或Domain，沒有針對user和role的，所以constrain在TEAC的基礎上，進一步加強了權限控制。在實際使用過程中，SELinux進行權限檢查時，先檢查TE是否滿足條件，然後再檢查constrain是否也滿足條件。二者都通過了，權限才能滿足。
關於RBAC和constrain，我們就介紹到此。
提示：筆者花了很長時間來理解RBAC和constrain到底是想要幹什麼。其實這玩意很簡單。因爲TE是Type Enforcement，沒user和role毛事，而RBAC則可通過constrain語句來在user和role上再加一些限制。當然，constrain也可以對type進行限制。如此而已！
2.2 Labeling介紹
前面陸陸續續講了些SELinux中最常見的東西。不過細心的人可能會問這樣一個問題：這些SContext最開始是怎麼賦給這些死的和活的東西的？Good Question！
提示：SELinux中，設置或分配SContext給進程或文件的工作叫Security Labeling，土語叫打標籤
initial_sids：定義了LSM初始化時相關的信息。SID是SELinux中一個概念，全稱是Security Identifier。SID其實類似SContext的key值。因爲在實際運行時，如果老是去比較字符串（還記得嗎，SContext是字符串）會嚴重影響效率。所以SELinux會用SID來匹配某個SContext。
initial_sid_context：爲這些SID設置最初的SContext信息。
來看這兩個文件的內容：
[external/sepolicy/initial_sids和initial_sid_context]
#先看initial_sids
sid kernel #sid是關鍵詞，用於定義一個sid
sid security
sid unlabeled
sid fs
sid file
sid file_labels
sid init
......
#再來看initial_sid_context
sid kernel u:r:kernel:s0 #將initial_sids中定義的sid和初始的SContext關聯起來
sid security u:object_r:kernel:s0
sid unlabeled u:object_r:unlabeled:s0
sid fs u:object_r:labeledfs:s0
sid file u:object_r:unlabeled:s0
sid file_labels u:object_r:unlabeled:s0
sid init u:object_r:unlabeled:s0
2） Domain/Type Transition和宏
SEAndroid中，init進程的SContext爲u:r:init:s0，而init創建的子進程顯然不會也不可能擁有和init進程一樣的SContext（否則根據TE，這些子進程也就在MAC層面上有了和init一樣的權限）。那麼這些子進程的SContext是怎麼被打上和其父進程不一樣的SContext呢？
SELinux中，上述問題被稱爲Domain Transtition，即某個進程的Domain切換到一個更合適的Domain中去。Domain Transition也是需要我們在安全策略文件中來配置的，而且有相關的關鍵詞，來看例子7。
[例子7-1]
#先要使用type_transition語句告訴SELinux
#type_transition的完整格式爲：
# type_transition source_type target_type : class default_type;
#對Domain Transition而言有如下例子：
type_transition init_t apache_exec_t : process apache_t;
DT(domain transtition) 太麻煩了，不細看了
....................................................
2.3 Security Level和MLS
（1） Security Level
上文介紹的TE，RBAC基本滿足了“平等社會”條件下的權限管理，但它無法反映現實社會中等級的概念。爲此，SELinux又添加了一種新的權限管理方法，即Multi-Lever Security，多等級安全。多等級安全信息也被添加到SContext中。所以，在MLS啓用的情況下（注意，你可以控制SELinux啓用用MLS還是不啓用MLS），完整的SContext由
MLS未啓用前：user_u:role_r:type_t。
MLS啓用後，user:role:type:sensitivity[:category,...]- sensitivity [:category,...]。
看，MLS啓用後，SContext type後面的字段變得非常複雜，看着有些頭暈（至少筆者初學它時是這樣的）。下面馬上來解釋它。
[Security-level解析]
|-->low security level<--| - |-->high security level<--|
sensitivity[:category,...] - sensitivity [:category,...]
上述字符串由三部分組成：
low security level：表明當前SContext所對應的東西（活的或死的）的當前（也就是最小）安全級別。
連字符“-”，表示range
high security level：表明當前SContext所對應的東西（活的或死的）的最高可能獲得的安全級別（英文叫clearance，不知道筆者的中文解釋是否正確）。
2.4 編譯安全策略文件
到此，SELinux Policy語言中的基本要素都講解完畢，相信讀者對着真實的策略文件再仔細研究下就能徹底搞明白。
不過，我們前面反覆提到的安全策略文件到底是什麼？我們前面看到的例子似乎都是文本文件，難道就它們是安全策略文件嗎？
拿個例子說事，來看圖6中Android的策略文件：
Android中，SELinux的安全策略文件如圖6所示。這麼多文件，如何處理呢？來看圖7
左邊一列代表安全配置的源文件。也即是大家在圖6中看到的各種te文件，還有一些特殊的文件，例如前文提到的initial_sid，initial_sid_contexts，access_vectors、fs_use,genfs_contexts等。在這些文件中，我們要改的一般也是針對TE文件，其他文件由於和kernel內部的LSM等模塊相關，所以除了廠家定製外，我們很難有機會去修改。
這些文件都是文本文件，它們會被組合到一起（圖7中是用cat命令，不同平臺處理方法不相同，但大致意思就是要把這些源文件的內容搞到一起去）。
搞到一起後的文件中有使用宏的地方，這時要利用m4命令對這些宏進行拓展。m4命令處理完後得到的文件叫policy.conf。前面我們也見過這個文件了，它是所有安全策略源文件的集合，宏也被替換。所以，讀者可以通過policy.conf文件查看整個系統的安全配置情況，而不用到圖6中那一堆文件中去找來找去的。
policy.conf文件最終要被checkpolicy命令處理。該命令要檢查neverallow是否被違背，語法是否正確等。最後，checkpolicy會將policy.conf打包生成一個二進制文件。在SEAndroid中，該文件叫sepolicy，而在Linux發行版本上，一般叫policy.26等名字。26表示SELinux的版本號。
最後，我們再把這個sepolicy文件傳遞到kernel LSM中，整個安全策略配置就算完成
.......................................................................
總結：
sepolicy的重頭工作是編譯sepolicy安全策略文件。這個文件來源於衆多的te文件，初始化相關的文件（initial_sid,initial_sid_context,users,roles,fs_context等）。
file_context：該文件記載了不同目錄的初始化SContext，所以它和死貨打標籤有關。
seapp_context：和Android中的應用程序打標籤有關。
property_contexts：和Android系統中的屬性服務（property_service）有關，它爲各種不同的屬性打標籤。
4 小試牛刀
下面，筆者將通過修改shell的權限，使其無法設置屬性。
先來看shell的te，如下所示：
[external/sepolicy/shell.te]
# Domain for shell processes spawned by ADB
type shell, domain;
type shell_exec, file_type;
#shell屬於unconfined_domain，unconfined即是不受限制的意思
unconfined_domain(shell)
# Run app_process.
# XXX Split into its own domain?
app_domain(shell)
unconfied_domain是一個宏，它將shell和如下兩個attribute相關聯：
[external/sepolicy/te_macros]
#####################################
# unconfined_domain(domain)
# Allow the specified domain to do anything.
#
define(`unconfined_domain', `
typeattribute $1 mlstrustedsubject; #這個和MLS有關
typeattribute $1 unconfineddomain;
')
unconfineddomain權限很多，它的allow語句定義在unconfined.te中：
[external/sepolicy/unconfined.te]
......
allow unconfineddomain property_type:property_service set;
從上面可以看出，shell所關聯的unconfineddomain有權限設置屬性。所以，我們把它改成：
allow {unconfineddomain -shell} property_type:property_service set;
通過一個“-”號，將shell的權限排除。
然後：
我們mmm external/sepolicy，得到sepolicy文件。
將其push到/data/security/current/sepolicy目錄下
接着調用setprop selinux.reload_policy 1，使得init重新加載sepolicy，由於/data目錄下有了sepolicy，所以它將使用這個新的。
===========================================================================
1.2.1 How SELinux Works
Figure 1-1 depicts the operation of SELinux in a highly simplified fashion. SELinux works by associating each program or process with a sandbox known as a domain. Each domain is assigned a set of permissions sufficient to enable it to function properly but do nothing else. For instance, a domain is limited in the files it can access and the types of operations it can perform on those files. To enable specification of such permissions, each file is labeled with information called a security context. The definition of a domain spells out what operations it can perform on files having specific security contexts. A domain cannot access files having security contexts other than those for which it is explicitly granted access.
An SELinux facility known as type enforcement (TE) ensures that the rules governing domains are always observed. SELinux also has a secondary facility known as role-based access control (RBAC). RBAC limits user access to domains. For instance, some domains are defined to be accessible only to the system administrator, whereas other domains are defined to be publicly available to any user.
2.1 Linux and SELinux: Dueling Security Mechanisms?
As explained in the preceding chapter, Linux has its own system of discretionary access control (DAC). How does Linux DAC interoperate with the mandatory access control (MAC) provided by SELinux? Do we end up with dueling security mechanisms?
Fortunately, Linux DAC and SELinux MAC play well together. When making security decisions, SELinux first hands off the decision to Linux DAC. If DAC forbids an action, the action is not permitted. If, on the other hand, DAC permits an action, then SELinux performs its own authorization check, based on MAC. A requested action is allowed to occur only if both the Linux DAC and SELinux MAC authorizations are approved.
2.2 Security Contexts
simplify decision making, similar subjects can be grouped and similar objects
can be grouped
User identity
The user identity indicates the SELinux user account associated with a subject or object. In the case of a subject, the user identity gives the SELinux user account under which the process is running. In the case of an object, the user identity gives the user account that owns the object.
Role
Under SELinux, users are authorized to enter one or more roles, each of which defines a set of permissions a user can be granted. At a given time, a user can reside in only a single role. A user can transition from one authorized role to another by using the special command newrole. This command changes the user's SELinux role similar to the way the Linux su command changes a user's Linux identity. SELinux establishes a special role, sysadm_r, used for administering SELinux facilities.
Type
Types, which are also known as domains, divide subjects and objects into related groups. Types are the primary security attribute SELinux uses in making authorization decisions. They establish the sandboxes that constrain processes and prevent privilege escalation. Therefore, you can think of a type as naming a related sandbox.
2.4 Access Decisions |
The three access vectors have the following functions:
Allow
The allow access vector identifies operations that the subject is permitted to perform on the object. No log entry is made of the operation.
Auditallow (就是不允許)
The auditallow access vector causes a log entry to be made when the indicated operation is performed. Despite its name, it doesn't allow any operation; only the Allow vector does so.
Dontaudit（不允許，同時不記錄到log）
The dontaudit access vector identifies operations that the subject is not permitted to perform on the object, but that don't cause the denial to be logged.
5.3 Anatomy of a Simple SELinux Policy Domain
Security context
The security context specifies the SELinux user, role, and type with which the directory or file is to be labeled.
5.3.2.1 The type line
The line:
type snort_etc_t, file_type, sysadmfile;
defines snort_etc_t as a type. The attributes file_type and sysadmfile mark this type as pertaining to file objects that can be accessed and modified by users associated with the sysadm_r (system administrator) role. Many such attributes are defined in the attrib.te file.
5.3.2.2 The allow lines
beginning with the keyword allow specify access vector rules authorizing operations on various object types. For instance, the line:
allow snort_t etc_t:file { getattr read };specifies that processes running in the snort_t domain can read and get the attributes of files labeled with the etc_t type. Notice the use of curly braces, { and }, to enclose the list