文章《SELinux 導致 Keepalived 檢測腳本無法執行》以【keepalived 無法執行檢測腳本】為案例向大家簡單介紹了關於 SELinux 的一些概念
比如說什麼是自主訪問控制 DAC 和 強制訪問控制 MAC；SELinux 安全上下文的概念等等
那麼今天鹹魚將單獨寫一篇文章向大家專門介紹一下 SELinux
初識 SELinux
SELinux（Security Enhanced Linux，安全增強型 Linux），這玩意由美國國家安全局（NSA）利用 Linux 安全模組（LSM）開發而成
安全增強型 Linux，看名字就感覺是跟安全相關的。SELinux 是 Linux 核心中的一個模組，用來解決進程與檔案資源之間許可權相關的一些問題
提到進程與檔案資源之間的許可權問題，我們腦子裡首先想到的應該就是rwx許可權了吧
- 自主訪問控制（Discretionary Access Control, DAC）
在傳統的 UNIX 類系統中，檔案資源都與特定的使用者和群組相關聯，並且訪問許可權通過rwx來控制
普通使用者想要去讀寫系統中的檔案資源受限於其所屬的使用者和群組的rwx許可權
對於 root 使用者來說rwx許可權設置是無效的，因為 root 使用者擁有完全訪問控制權
比如說某個進程想要對檔案進行讀寫時，系統就會根據該進程的屬主和屬組去比對檔案許可權，只有通過許可權檢查才能進一步操作
這種許可權控制方式被稱為自主訪問控制（Discretionary Access Control, DAC）
DAC 是 Linux 作業系統中的一種基本許可權控制機制，用於限制使用者對系統資源的訪問許可權
但是後面大家發現 DAC 有許多不足之處：比如說 root 的許可權太高了，如果某個惡意進程拿到了 root 許可權，那麼將是一件很可怕的事情
又或者不小心把某一個檔案的許可權設置成了 777，那麼這個檔案就會被任何人任何進程操作
為了彌補 DAC 的一些不足之處，MAC 模型隨之誕生
- 強制訪問控制（MAC，Mandatory Access Control）
MAC 是 Linux 作業系統中一種更加嚴格和細粒度的訪問控制機制，用於加強對系統資源的保護和控制
它有趣的地方在於可以針對特定的進程與特定的檔案資源來管理許可權，不僅考慮了前面 DAC 機制中的rwx許可權、還考慮了更多因素（例如安全策略和標籤）
即使你是 root 使用者，在使用不同的進程時你所能獲取的許可權也不一定是 root
SELinux 引用了 MAC ，每個進程和系統資源都有一個特殊的安全性標籤，稱為 SELinux 上下文（context）
依據這個安全上下文，SELinux 制定了一系列規則，用來限制進程之間如何互相互動以及如何與各類系統資源互動
SELinux 的規則能夠精細到是否允許特定使用者或進程訪問特定資源
舉個例子：
使用 SELinux時，httpd 進程能夠訪問
/var/www/html/，但是不允許訪問/tmp和/var/tmp/中的檔案即使你的 web 伺服器被攻擊，駭客控制了 httpd 進程，就算擁有 root 許可權也無法訪問
/tmp和/var/tmp/中的檔案
需要注意的是：
- 對於受 SELinux 管制的進程，會先檢查 SELinux 策略規則，然後再檢查 DAC 規則
- 對於不受 SELinux 管制的進程，仍然會執行 DAC 規則
- 如何看一個進程受不受 SELinux 管制，看它的安全上下文
基礎概念
我們知道，SELinux 通過 MAC 的方式來管理進程或使用者的許可權
即 SELinux 控制的主體是【進程】或【使用者】，而【目標】則是該進程或使用者能否訪問的檔案資源
- 主體（subject）：SELinux 主要管理的就是進程，一般代指進程
- 目標（object）：主體能否訪問的目標，一般代指檔案資源
- 策略（policy）：SELinux 根據特定的服務或應用程序來制定基本的安全策略，以控制進程對檔案資源的讀寫訪問；每一個策略都由許多規則組成
關於 SELinux 策略，以 CentOS 7.x 為例：
- targeted：針對網路服務限制較多，本機限制較少。默認的策略
- minimum：由 target 自定義而來，僅針對選擇的進程來保護
- mls：完整的 SELinux 限制，限制嚴格
/etc/selinux/config
安全上下文
我們知道，每個主體進程和目標資源都有一個安全標籤，稱為 SELinux 安全上下文（Security Context）
SELinux 會根據主體的安全上下文以及目標的安全上下文來決定是否允許主體訪問目標，以及允許何種類型的訪問
即主體與目標的安全上下文必須一致才能夠順利讀寫，有點像 DAC 中的rwx許可權
安全上下文存放在檔案的 inode 內，可以通過下面的命令去查看（需要先開啟 SELinux）
以unconfined_u:object_r:admin_home_t為例，可以看到安全上下文主要用冒號分割了三個欄位，分別代表三個主要類型
User(使用者）
在 SELinux 中，身份是指作業系統中的使用者（User）。每個 user 都有一個唯一的身份標識
不同的 user 可以被分配不同的角色（role）和類型（type），以控制他們對系統資源的訪問
比如unconfined_u（不受限的使用者）表示該檔案來自於不受限（不受 SELinux 限制）的使用者
一般來講默認的 bash 環境是不受 SELinux 管制的，所以 bash 進程產生的檔案 user 大多數為
unconfined_u不受限使用者
比如system_u，如果是網路服務所產生或系統服務運行過程中產生的檔案，那 user 大部分就是system_u
role（角色）
角色是 SELinux 中的一個概念，用於定義使用者在系統中的角色或角色組
role 可以幫助限制 user 的行為，使其在不同的角色下有不同的許可權
通過 role ，就可以知道這個資料是屬於進程還是檔案資源，_r表示role
object_r（檔案或目錄）system_r（進程）
type（類型）
type 是 SELinux 中非常重要的一個概念，它用於對檔案、進程等資源進行分類，每個檔案、進程都被賦予一個唯一的 type 標識
type 定義了資源可以被哪些進程和使用者訪問，以及資源可以訪問哪些其他資源
這種基於類型的訪問控制使得即使使用者有相同的許可權，但只有在特定的 type 下才能進行訪問，從而增強了系統的安全性
type 在檔案與進程方面的定義有一些區別：
1)type：在檔案資源（Object）上面稱為類型（type）
2)domain：在主體進程（Subject）上面稱為域（domain）
type與domain需要相互適配，該進程才能夠順利讀取檔案資源
以crond為例，先看下crond進程的安全上下文內容
再來看下crond的執行檔案、配置檔案等安全上下文內容
當我們執行/usr/sbin/crond之後，這個進程的domain類型是crond_t，能夠讀取的配置檔案則為system_cron_spool_t這種類型
如果配置檔案的 type 不是system_cron_spool_t，就算進程擁有rwx許可權也無法讀取
總結
最後總結一下
SELinux 基於 MAC 模型進一步更加嚴格和細分地對進程與資源之間的許可權進行控制，用於加強對系統資源的保護
在 SELinux 中，有三個重要的概念：
- 主體（subject）：SELinux 主要管理的就是進程，一般代指進程
- 目標（object）：主體能否訪問的目標，一般代指檔案資源
- 策略（policy）：SELinux 根據特定的服務或應用程序來制定基本的安全策略，以控制進程對檔案資源的讀寫訪問；每一個策略都由許多規則組成
SELinux 控制的主體是【進程】或【使用者】，而【目標】則是該進程或使用者能否訪問的檔案資源
SELinux 為每個主體進程和目標資源都打上一個安全標籤，稱為 SELinux 安全上下文（Security Context），它會根據主體的安全上下文以及目標的安全上下文來決定是否允許主體訪問目標，以及允許何種類型的訪問
即主體與目標的安全上下文必須一致才能夠順利讀寫，有點像 DAC 中的rwx許可權
