1. 簡介
SELinux提供了一種依賴於類型強制（TE）基於角色的訪問控制（RBAC），角色用於組域類型和限制域類型與用戶之間的關係，SELinux中的用戶關聯一個或多個角色，使用角色和用戶，RBAC特性允許有效地定義和管理最終授予Linux用戶的特權。
域類型<---->用戶
1.1 SELinux與Linux訪問授權的區別
• Linux：將訪問權授予用戶，或通過用戶組或角色的機制進行授權；
• SELinux：訪問權不是直接授予用戶或角色的，訪問權是通過TE allow規則授予類型。
角色扮演是類型強制支持的一個特性，它和用戶一起爲Linux用戶及其允許的程序提供了一種綁定基於類型的訪問控制，SELinux中的RBAC通過定義域類型和用戶之間的關係對類型強制做了更多限制，以控制Linux用戶的特權和訪問許可，RBAC沒有允許訪問權，在SELinux中，所有的允許訪問權都是由類型強制提供的。
注意：Linux和SELinux有它們自己的用戶標識符，這讓人難以理解，爲了避免混淆，在本中，如果指的的/etc/passwd中定義的用戶，我們就用"Linux用戶"來表達，如果沒有明確指出是什麼用戶或用戶標識符，那就指的是SELinux策略中在安全上下文中定義的用戶標識符了。
1.2 SELinux中RBAC
SELinux中的RBAC特性依賴並支持TE特性，我們通過將域類型和一個或多個角色進行關聯，而不是直接將權限授給用戶，RBAC通過在安全上下文中控制域類型、角色和用戶的關聯實現對TE策略更多的約束，也就是說，域轉換是受用戶的角色約束的，最終約束了用戶的總體權限。
其例子如下圖所示：
這個例子顯示了兩類RBAC策略語句：一個用戶聲明語句（user）和兩個角色聲明語句（role）。這些語句在策略中創建了用戶、角色和類型標識符之間的關係。
上圖中的user語句將SELinux用戶joe和角色user_r關聯起來，這條語句告訴SELinux用戶joe和角色user_r在安全上下文中是可以共存的，如果沒有這條語句，上圖中的用戶joe和角色user_r進程安全上下文將是無效的，SELinux將會拒絕創建它們，最後拒絕進行域轉換。
那兩個role語句將角色user_r和域類型user_t和passwd_t關聯起來，與user語句類似，要使進程安全上下文有效，role語句也是必需要有的，如果沒有role語句關聯類型passwd_t，即使TE策略允許，域轉換也會失敗。如果我們不想user_r角色運行密碼程序，我們只需要將role語句移除，內核也就不會創建對應的安全上下文了，即使TE規則允許進行訪問。
1.3 用角色管理用戶權限
如上圖的例子所示，我們不會直接將域類型和用戶進行關聯，相反，域類型是與角色進行關聯的，然後再將角色與SELinux用戶進行關聯，這就間接增加了兩個效果，首先，他簡化了管理所有策略的複雜度，一個系統可能只有三或四個角色，但有成千上萬的用戶和域類型，直接將域類型與用戶進行關聯，將會導致管理非常困難，將域類型分配給一個具描述類型（如普通用戶域類型）特權集的角色，然後將這些角色指派給用戶，這樣就更容易管理了。
關鍵要記住角色僅僅是一套域類型的集合，他可以方便地與用戶建立聯繫，它們不是SELinux中獨立的訪問控制機制。SELinux中的角色也允許我們限制用戶的訪問，對於任何進程，同一時間只有一個角色（即進程安全上下文中的角色）是"活動的"。
1.4 客體安全上下文中的用戶和角色
在密碼策略示例中，沒有包括顯示的文件客體完整的安全上下文（即可執行文件/etc/bin/passwd和shadow密碼文件/etc/shadow），相對主體安全上下文中的用戶和角色部分而言，客體安全上下文的重要性要低一些，然而客體必須要有一個完整的安全上下文，用戶字段支持審覈，而角色沒什麼用，如果我們在我們的示例系統中檢查上圖中的客體，我們會發現如下所示的安全上下文：
- # ls --scontext /usr/bin/passwd /etc/shadow
- system_u:object_r:shadow_t /etc/shadow
- system_u:object_r:passwd_exec_t /usr/bin/passwd
正如你所看到的，這兩個客體都有特殊的角色object_r，它是所有客體代表性的角色，這個角色是硬編碼進SELinux的，它是不需要聲明的，對於所有類型都是隱含允許的，你不要嘗試聲明角色object_r。
客體安全上下文的用戶部分通常設置爲創建進程安全上下文的用戶部分，這個特性有一些潛在的用途，可以跟蹤是哪個用戶創建的這個客體，但通常沒有安全強制效果，在前面的例子中，這個兩個客體的用戶都是system_u，它是一個特殊的用戶，在許多策略中都存在，它代表系統資源和進程。
2. 角色和角色語句
除了object_r外，SELinux沒有內置任何其它的角色，與類型一樣，角色也需要在策略中進行聲明，與角色有關的有4個策略語句：
• 角色聲明語句
• 角色allow規則
• 角色轉換規則
• 角色控制語句。
2.1 角色聲明語句
角色聲明語句（role）聲明一個角色標識符，例子如下：
role user_r types user_t;
role user_r types passwd_t;
這些語句將域類型user_t和passwd_t與角色user_r關聯起來了。
完整的角色聲明語法如下：
role 角色名稱 types [類型 類型集];
• 角色名稱：角色標識符，如果它是在第一條role語句中，這就聲明瞭一個角色，標識符長度任意。
• 類型集：一個或多個類型或標識符屬性，使用大括號{}將多個標識符括起來，標識符之間使用空格分開，如{user_t passwd_t}，類型也是可以被排除的，只需要在類型名稱前加上一個“-”即可，如{exec_type–sbin_t}，如果省略type_set（同關鍵字types一起），角色聲明時就不會關聯任何類型。
角色聲明在單個策略，基礎載入模塊和非基礎載入模塊中都是有效的，但在條件語句中就無效了。
2.2 角色轉換規則
因爲程序在執行過程中角色可能發生變化，某種程度上與類型相似，在策略語言中，我們需要一個方法實現這種轉換的自動化，對於類型而言，我們使用了type_transition規則進行自動化處理，對於角色，我們就使用角色轉換規則role_transition，這個規則在作用和語法上與type_transition很類似，如：
- role_transition sysadm_r http_exec_t system_r;
這個規則說明，當一個角色爲sysadm_r的進程執行一個類型爲http_exec_t的文件時，SELinux將會嘗試將起轉換爲system_r角色。
與type_transition規則一樣，role_transition規則也不允許（allow）規則執行角色改變，假設這樣，要使得角色改變成功，角色allow規則也是必須的，角色轉換規則通常用於系統管理員直接執行系統後臺進程時改變角色，而不是初始化進程（init），如果這種情形下不使用角色轉換規則，後臺進程可能有一個不同的角色，這依賴於是誰啓動的它，除了這種情況外，我們不希望角色被隱含地改變，相反，我們希望用戶在需要的時候明確地改變它們的角色（如newrole命令）。
角色轉換規則指定了執行一個文件時默認的角色變化，角色轉換規則沒有允許訪問權，要成功轉換角色，角色allow規則也是必須的。
角色轉換規則語法如下：
role_transition 角色集 類型集 角色;
• 角色集： 一個或多個角色標識符，多個標識符之間使用空格分隔，並使用大括號將它們括起來，如{staff_r sysadm_r}。
• 類型集：一個或多個類型或屬性標識符，多個標識符之間使用空格進行分隔，並使用大括號將它們括起來，如{user_t passwd_t}。可以使用前綴字符“-”來排除類型，如{exec_type –sbin_t}。
• 角色： 角色轉換後安全上下文中的新角色。
角色轉換規則在單個策略，基礎載入模塊和非基礎載入模塊中都有效，但在條件語句中無效。
2.3 角色控制語句
角色控制語句（dominance）按照其他角色聲明一個角色，我們可以使用這個語句創建一個角色之間的層次關係，假設這樣，"高層角色"可能會自動繼承所有與角色關聯的類型，例如：
- dominance { role super_r {role sysadm_r; role secadm_r; }}
這個角色dominance語句聲明瞭一個角色super_r，如果它沒有聲明，並使它控制角色sysadm_r和secadm_r，角色super_r將擁有與角色sysadm_r和secadm_r合併後的類型，如果這些"高層角色"發生了任何變化，合併內容也將爲super_r發生變化，注意任何添加到控制語句後的高層角色的類型沒有通過dominance語句繼承下來，因此，在前面的例子中，如果在dominance語句後面給secadm_r角色添加了一個類型，super_r角色不會繼承這個新的類型，角色dominance語句在現有策略中也沒有廣泛使用。
完整的角色控制語句語法如下：
dominance {role 角色名稱 {角色集}}
• 角色集：一個或多個以“role 角色名稱”形式指定的角色，多個角色之間使用空格分隔，如{role staff_r;role sysadm_r}。
策略語言不支持更復雜的語法，這裏的角色集可以包括嵌套的控制關係定義，使用大括號進行表示，如：
dominance { role a_r { role b_r; role c_r { role d_r; } } }
在這個例子中，角色定義如下：
d_r 只有它自己的類型
c_r 它的類型和d_r的類型
b_r 只有它自己的類型
a_r 它自己的類型和所有b_r，c_r和d_r的類型
2.4 角色allow規則
角色allow規則語法如下：
allow 角色名 角色名；
例子如下：
- allow cashier_r mgr_r;
指角色爲mgr_r的進程可以轉換到一個角色名爲cashier_r的進程。
3. 用戶和用戶語句
Linux和SELinux用戶標識符是不同的，通常也沒什麼關聯，在SELinux中，進程的Linux用戶標識符和SELinux用戶標識符是不同的（例如：參考稍後討論的user_u），當初設計SELinux用戶標識符時，希望實現一個固定不變的SELinux用戶標識符，所以纔沒有共享Linux的用戶標識符，在標準Linux中，用戶標識符的改變反應的權限的變化（例如：改變爲root賬號），在多數情況下，這兩個真實有效的用戶標識符都可以改變，這使得在跟蹤審覈、認證登陸的用戶變得困難，將Linux用戶標識符和SELinux用戶標識符分隔開來允許Linux用戶標識符按需改變，而不會對SELinux用戶標識符產生任何影響。