安全增强式Linux

**安全增強式 Linux**（SELinux，Security-Enhanced Linux）是一個 Linux 核心的安全模組，其提供了存取控制安全策略機制，包括了強制存取控制（Mandatory Access Control，MAC）。

SELinux 是一組核心修改和使用者空間工具，已經被添加到各種 Linux 發行版中。其軟體架構力圖將安全決策的執行與安全策略分離，並簡化涉及執行安全策略的軟體的數量。SELinux 的核心概念可以追溯回美國國家安全局（NSA）的一些早期專案。

## 概覽

美國國家安全局的安全增強式 Linux 團隊稱：

> 安全增強式 Linux 是一組給 Linux 核心的修補程式，並提供一些更強、更安全的強制存取控制架構來和核心的主要子系統共同運作。基於機密及完整性原則，它提供一個架構來強制資訊的分離，以對付入侵的威脅或任何企圖略過安全架構的應用程式。藉此限制惡意或設計不良的程式可能造成的破壞。它包含一組安全性原則組態設定檔的範本以符合一般的安全性目標
> 
> 

整合 SELinux 的 Linux 核心將執行限制使用者程式和系統伺服器存取檔案與網路資源的強制存取控制策略。將權限限制到最小以減少或完全清除程式和守護行程在失效或出錯的情況（如快取區溢位或錯誤組態）下對系統造成危害的可能性。此種限制機制獨立與於傳統的 Linux 自主存取控制（Discretionary Access Control, DAC）進行。SELinux 沒有「root」使用者的概念，也沒有傳統 Linux 安全機制的缺點。（如依賴於 setuid/setgid 庫）

「未修改過的」Linux 系統安全性（即未整合 SELinux 的系統）依賴於核心、授權應用與其組態的正確性。三者中任意一個發生問題都將有可能導致整個系統被破解。相反，「修改過的」系統安全性（基於 SELinux 核心）主要基於其核心和組態的正確性。雖然當應用程式的正確性或組態出現問題可能會導致獨立的使用者程式和系統守護行程發生有限破解，但是它們並不會對其他使用者程式和系統守護行程或整個系統的安全性造成威脅。

純粹來看，SELinux 提供了一個從強制存取控制、強制完整性控制、以角色為基礎的存取控制和類型強制架構提取出的概念與功能的混合體。第三方工具可以使開發者構建多種安全策略。

## 歷史

早期工作主要指向在 UNIX 計算環境（準確而言是 POSIX）下標準化強制和自主存取控制條款的方法。這歸因於美國國家安全局受信 UNIX（TRUSIX）工作群組，他們在 1987 到 1991 年間接觸並發布了一本彩虹書 （#020A），並製造了一個原初模型和最初未發布的關聯評估證據原型（#020B）。

SELinux 最初設計向 Linux 社群展示強制存取控制的價值和這些控制加入 Linux 的方法。起初，組成 SELinux 的修補程式只能通過明確添加在 Linux 核心原始碼中來工作；在 2.6 系列的 Linux 核心中 SELinux 已被整合入。

作為最初 SELinux 的主要開發者，美國國家安全局於 2000 年 12 月 22 日基於 GNU 通用公共許可證發行了第一版 SELinux 給了開放原始碼開發社群。

SELinux 隨後被整合進了 Linux 核心 2.6.0-test3 版本的主分支，並在 2003 年 8 月 8 日發布。其他的顯要貢獻者有紅帽公司、邁克菲、安全計算公司、特瑟思科技（Tresys Technology）和可信電腦解決方案（Trusted Computer Solutions）。FLASK/TE 實現通過 FreeBSD 專案成功移植到了 FreeBSD 和 Darwin 作業系統上。

SELinux 實現了通量進階安全核心。這種核心包含了以錨爪作業系統為原型的架構部件。這些提供給了強制執行多種強制存取控制策略許多通常支援，包括了基於類型強制、以角色為基礎的存取控制和多層安全概念的策略。FLASK 基於馬赫衍生的（Mach-derived）分散式受信作業系統（DTOS）和來自對 DTOS 的設計和實現有著影響的受信資訊系統的一個研究專案 —— 受信馬赫（Trusted Mach）。

## 使用者、策略和安全上下文

SELinux 使用者和角色不需要與實際系統使用者與角色相關。對每個正在進行的使用者或行程，SELinux 分配一個三字串上下文，包含了使用者名稱、角色和域（或者類型）。此系統比通常所需要的系統更靈活：作為規定之一，大多數真實使用者享有著相同的 SELinux 使用者名稱，且所有的存取控制都經由第三個標籤 —— 域來進行。在一個行程被允許進入域的情況下必須在策略中組態。命令 `runcon` 允許啟動行程進入一個顯性定義上下文（使用者、角色和域）環境中，但如果政策中未允許的話那麼 SELinux 可能會拒絕此請求。

檔案、網路埠和其他硬體均有可能含有 SELinux 上下文，有一個名字、角色（不常使用）和類型組成。檔案系統在檔案和安全上下文之間的對映被稱為標記（Labeling）。標記在策略檔案中被定義但也可以在不更改策略的情況下手動調整。硬體類型十分詳細，比如 `bin_t`（顯示 /bin 下的所有檔案）或 `postgresql_port_t`（PostgreSQL 埠 5432）。遠端檔案系統的 SELinux 上下文可以在被掛載時顯性定義。

SELinux 給 Shell 命令 `ls`、`ps` 等中添加了 `-Z` 開關使得檔案或行程的安全上下文可見。

典型的政策規則包含了顯性權限；使用者必須擁有哪些域才能用給定目標進行特定的行為（讀、執行，網路埠中則是繫結或連接）等等。也可以進行更多複雜的對映，包括在角色級和安全級進行。

一個典型的策略包含了一個對映檔案（標記）檔案、一個規則檔案和一個定義域過渡的介面檔案。這三個檔案必須被同時使用 SELinux 工具編譯來生成單一的策略檔案。生成的策略檔案可以被載入到核心中並工作。載入和解除安裝策略並不需要重新啟動。策略檔案既有可能是手打也可能是用容易使用的 SELinux 管理工具生成。它們通常先在允許模式（Permissive Mode）下測試，在此模式下違反策略的行為都將被記錄但被允許。`audit2allow` 工具可以隨後使用來生成擴充 SELinux 策略以允許受限應用的合法活動的附加規則。

## 特性

SELinux 特性包含了：

* 在執行情況下將策略完全分離
* 定義充分的策略介面
* 支援問詢策略並執行存取控制的應用程式（例如 Cron 在正確的上下文環境中執行工作）
* 獨立於特定政策和策略語言
* 獨立於特定安全標籤格式與內容
* 對核心目標和服務的獨立標記
* 支援策略更改
* 分離保護系統完整性（域名類）和資料保密（多層安全）的措施
* 靈活的策略
* 控制行程初始化與繼承和程式執行
* 控制檔案系統、目錄、檔案和開放性檔案描述子
* 控制通訊端、資訊和網路介面
* 控制使用「容量」（Capabilities）
* 在存取決定中通過_存取向量快取_（Access Vector Cache, AVC）預快取資訊

## 實現

SELinux 通過 Red Hat Enterprise Linux 第四版及其所有未來的發行版中的商業支援得以可用。它的存在也在對應版本的 CentOS 和 Scientific Linux 中呈現。RHEL4 中所支援的策略目標為最大化簡易使用程度而並沒有它能成為的那樣有約束性。RHEL 的未來版本準備將在目標策略中寫入更多的目標，也就意味著有更多的限制策略。SELinux 在 Android4.3 版本中就已得以實現。

在自由社群所支援的 GNU/Linux 發行版中，Fedora (作業系統) Fedora 是最早採用 SELinux 的，在 Fedora Core 2 中就已預設包含了對其的支援。其他發行版中，Debian 在 Etch 發行版中包含了對它的支援，Ubuntu 則在 8.04 版代號堅強的蒼鷺（Hardy Heron）中加入。截止 openSUSE 版本 11.1 中，它包含了 SELinux 的「基礎實現」。 SUSE Linux Enterprise 11 將 SELinux 作為「技術預覽」。

SELinux 在基於 Linux 容器的系統中流向，比如 CoreOS 和 rkt。其作為額外的安全控制來幫助隔離容器和它們的主機十分有用。

## 使用情形

SELinux 可以潛在地通過詳細的參數來控制允許系統每個使用者的活動、行程以及守護行程。但是，它主要用於限制守護行程比如被更顯著定義資料存取和活動權限的資料庫引擎或者網頁伺服器。這限制了被破解的限制守護行程的潛在危害。普通的使用者行程通常執行於受限域中，不被 SELinux 所限制但被經典 Linux 存取權限所限制。

命令列工具包含：`chcon`,`restorecon`,`restorecond`,`runcon`,`secon`,`fixfiles`,`setfiles`,`load_policy`,`booleans`,`getsebool`,`setsebool`,`togglesebool``setenforce`,
`semodule`,
`postfix-nochroot`,
`check-selinux-installation`,
`semodule_package`,
`checkmodule`,
`selinux-config-enforcing`,`selinuxenabled`,
and `selinux-policy-upgrade`

## 範例

將 SELinux 設定為強制模式（Enforcing Mode）：

　
: `$ sudo setenforce 1`

查詢 SELinux 狀態：

　
: `$ getenforce`

## 與 AppArmor 的對比

SELinux 代表了多個可能解決限制安裝軟體活動的方法之一。另外一個受歡迎的替代品被稱為 AppArmor，它在 SUSE Linux Enterprise Server（SLES）、OpenSUSE 和其他 Linux 平台中可用。AppArmor 原初是作為現不存在的 Immunix Linux 平台組件之一開發的。由於 AppArmor 和 SELinux 大相逕庭，它們產生了兩種完全不同的軟體存取限制軟體。雖然 SELinux 重新提出了特定的概念以提供更豐富的策略選擇表達集，但 AppArmor 通過擴充用於自主存取控制級的特定相同自主存取控制管理語言設計來簡化其使用。

它們之間存在幾個顯著的不同：

* 一個重要的區別是，AppArmor 通過路徑名而非索引節點，來辨識檔案系統目標。打個比方，這意味著，在 AppArmor 下，當建立了硬連結之後，一個不可存取的檔案將得以存取。而 SELinux 下，即使新建立了硬連結，存取也會被阻止。
  * 結果，AppArmor 可被稱為不是一個類型強制系統，因為檔案並沒有被分配類型；相反，它們僅僅在設定檔中被參照。
* SELinux 和 AppArmor 在它們如何管理和整合系統的方面也存在著極大的不同。
* 由於其尋求使用強制存取控制級執行來重建傳統的自主存取控制，AppArmor 的一系列操作也認為比大多數 SELinux 實現要小得多。例如，AppArmor 的一系列操作包含了：讀、寫、附加、執行、鎖定和連結。大多數的 SELinux 實現將支援一系列多於其的操作序列。比如，SELinux 通常支援相同權限，但同時對於 mknod 包含了控制、繫結到網路包、隱性使用 POSIX 的能力、載入並解除安裝核心模組和多種存取共享記憶體的方法等。
* AppArmor 沒有能明確限制 POSIX 功能的控制項。由於當前功能實現的方法不包含操作主題的概念（只有執行者和操作本身），防止執行者外的強制控制領域（即沙箱）授權檔案操作通常由 MAC 層完成。AppArmor 可以防止其策略被更改和檔案系統被掛載 / 解除安裝，但不能防止使用者踏出他們的控制域。
  * 例如，人們通常認為桌面員工更改他們所不擁有的特定檔案（例如：部門檔案分享）的所有權或權限是有益的。你絕對不會想給使用者機器的 root 權限，所以你會給他們 `CAP_FOWNER` 或 `CAP_DAC_OVERRIDE`。在 SELinux 下（或你的平台製造商下），你可以組態 SELinux 來禁止所有其他未受限使用者的能力，然後新建一個給員工的受限域以在登陸後進行過渡。這種情況可以給員工修改權限的能力，但僅限於合適類型的檔案。
* AppArmor 沒有多層安全的概念，因此也沒有硬性的貝爾 - 拉帕杜拉模型或比巴模型強制執行。
* AppArmor 的組態通過唯一常規平面檔案完成。SELinux（在大多數實現中為預設）則使用平面檔案組合（在編譯前由管理員和開發者編寫人類可讀的策略）和擴充屬性完成。
* SELinux 支援作為策略組態替代源的 "遠端策略伺服器" 概念（可在 /etc/selinux/semanage.conf 中組態）。AppArmor 的中心化管理通常十分複雜，這是因為管理員必須決定策略部署工具以 root 權限執行（以允許策略更新）或在每台伺服器上被手動組態。
* 

## 相似系統

孤立行程也可以通過類似作業系統層虛擬化的機制實現；比如在 OLPC 專案的首次實現中它使用了沙盒技術在輕量的 Vserver 環境中隔離獨立的應用程式。同樣美國國家安全局也在安全增強型 Android 中採用了一些 SELinux 概念。

## 參見

## 參考文獻

## 外部連結

* 官方網站
* NSA:
  * Security-Enhanced Linux （頁面存檔備份，存於網際網路檔案館） at NSA
  * Mailing list （頁面存檔備份，存於網際網路檔案館）
  * NSA shares security enhancements to Linux. Press release. Jan 2, 2001 [2018-02-19]. （原始內容存檔於 2018-02-20）.
* GitHub 上的 SELinux
* Walsh, Daniel J. Visual how-to guide for SELinux policy enforcement. Opensource.com. 13 Nov 2013 [2018-02-19]. （原始內容存檔於 2017-07-07）.