热门问题
时间线
聊天
视角
安全增強式Linux
Linux核心安全模組 来自维基百科，自由的百科全书
Remove ads
安全增強式Linux（SELinux，Security-Enhanced Linux）是一個Linux內核的安全模組，其提供了訪問控制安全策略機制，包括了強制訪問控制（Mandatory Access Control，MAC）。
 | 此條目翻譯品質不佳。 |
SELinux是一組內核修改和用戶空間工具，已經被添加到各種Linux發行版中。其軟件架構力圖將安全決策的執行與安全策略分離，並簡化涉及執行安全策略的軟件的數量。[2][3]SELinux的核心概念可以追溯回美國國家安全局（NSA）的一些早期項目。
Remove ads
概覽
美國國家安全局的安全增強式Linux團隊稱：[4]
安全增強式Linux是一組給Linux核心的修補程式，並提供一些更強、更安全的強制存取控制架構來和核心的主要子系統共同運作。基於機密及完整性原則，它提供一個架構來強制資訊的分離，以對付入侵的威脅或任何企圖略過安全架構的應用程式。藉此限制惡意或設計不良的程式可能造成的破壞。它包含一組安全性原則組態設定檔的範本以符合一般的安全性目標
整合SELinux的Linux內核將執行限制用戶程序和系統服務器訪問文件與網絡資源的強制訪問控制策略。將權限限制到最小以減少或完全清除程序和守護進程在失效或出錯的情況（如緩存區溢出或錯誤配置）下對系統造成危害的可能性。此種限制機制獨立與於傳統的Linux自主訪問控制（Discretionary Access Control, DAC）進行。SELinux沒有「root」用戶的概念，也沒有傳統Linux安全機制的缺點。（如依賴於setuid/setgid庫）
「未修改過的」Linux系統安全性（即未整合SELinux的系統）依賴於內核、授權應用與其配置的正確性。三者中任意一個發生問題都將有可能導致整個系統被破解。相反，「修改過的」系統安全性（基於SELinux內核）主要基於其內核和配置的正確性。雖然當應用程序的正確性或配置出現問題可能會導致獨立的用戶程序和系統守護進程發生有限破解，但是它們並不會對其他用戶程序和系統守護進程或整個系統的安全性造成威脅。
純粹來看，SELinux提供了一個從強制訪問控制、強制完整性控制、以角色為基礎的存取控制和類型強制架構提取出的概念與功能的混合體。第三方工具可以使開發者構建多種安全策略。
Remove ads
歷史
早期工作主要指向在UNIX計算環境（準確而言是POSIX）下標準化強制和自主訪問控制條款的方法。這歸因於美國國家安全局受信UNIX（TRUSIX）工作組，他們在1987到1991年間接觸並發布了一本彩虹書 （#020A），並製造了一個原初模型和最初未發布的關聯評估證據原型（#020B）。
SELinux最初設計向Linux社區展示強制訪問控制的價值和這些控制加入Linux的方法。起初，組成SELinux的補丁只能通過明確添加在Linux內核源碼中來工作；在2.6系列的Linux內核中SELinux已被整合入。
作為最初SELinux的主要開發者，美國國家安全局於2000年12月22日基於GNU通用公共許可證發行了第一版SELinux給了開放原始碼開發社群。[5]
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）。
Remove ads
用戶、策略和安全上下文
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特性包含了：
實現
SELinux通過Red Hat Enterprise Linux第四版及其所有未來的發行版中的商業支持得以可用。它的存在也在對應版本的CentOS和Scientific Linux中呈現。RHEL4中所支持的策略目標為最大化簡易使用程度而並沒有它能成為的那樣有約束性。RHEL的未來版本準備將在目標策略中寫入更多的目標，也就意味着有更多的限制策略。SELinux在Android4.3版本中就已得以實現。[7]
在自由社區所支持的GNU/Linux發行版中，Fedora (作業系統)Fedora是最早採用SELinux的，在Fedora Core 2中就已默認包含了對其的支持。其他發行版中，Debian在Etch發行版中包含了對它的支持[8]，Ubuntu則在8.04版代號堅強的蒼鷺（Hardy Heron）中加入。[9]截止openSUSE版本11.1中，它包含了SELinux的「基礎實現」。[10] SUSE Linux Enterprise 11將SELinux作為「技術預覽」。[11]
SELinux在基於Linux容器的系統中流向,比如CoreOS和rkt。[12]其作為額外的安全控制來幫助隔離容器和它們的主機十分有用。
Remove ads
使用情形
SELinux可以潛在地通過詳細的參數來控制允許系統每個用戶的活動、進程以及守護進程。但是，它主要用於限制守護進程比如被更顯著定義數據訪問和活動權限的數據庫引擎或者網頁服務器。這限制了被破解的限制守護進程的潛在危害。普通的用戶進程通常運行於受限域中，不被SELinux所限制但被經典Linux訪問權限所限制。
命令行工具包含：[13]
chcon,[14]
restorecon,[15]
restorecond,[16]
runcon,[17]
secon,[18]
fixfiles,[19]
setfiles,[20]
load_policy,[21]
booleans,[22]
getsebool,[23]
setsebool,[24]
togglesebool[25]
setenforce,
semodule,
postfix-nochroot,
check-selinux-installation,
semodule_package,
checkmodule,
selinux-config-enforcing,[26]
selinuxenabled,[27]
及 selinux-policy-upgrade[28]
Remove ads
將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通過路徑名而非inode識別目標文件。這意味着在AppArmor下，一個不可訪問的文件可以通過創建硬鏈接得以訪問（此時文件路徑產生變化，而inode不變）；而在SELinux下，即使通過創建了硬鏈接改變文件路徑，訪問也會被阻止。
- 結果，AppArmor可被稱為不是一個類型強制系統，因為文件並沒有被分配類型；相反，它們僅僅在配置文件中被引用。
- SELinux和AppArmor在管理和整合系統的方面存在着極大的不同。[29]
- 由於其尋求使用強制訪問控制級執行來重建傳統的自主訪問控制，AppArmor的一系列操作也認為比大多數SELinux實現要小得多。例如，AppArmor的一系列操作包含了：讀、寫、附加、執行、鎖定和鏈接。[30]大多數的SELinux實現將支持一系列多於其的操作序列。比如，SELinux通常支持相同權限，但同時對於mknod包含了控制、綁定到網絡包、隱性使用POSIX的能力、加載並卸載內核模塊和多種訪問共享內存的方法等。
- AppArmor沒有能明確限制POSIX功能的控制項。由於當前功能實現的方法不包含操作主題的概念（只有執行者和操作本身），防止執行者外的強制控制領域（即沙箱）授權文件操作通常由MAC層完成。AppArmor可以防止其策略被更改和文件系統被掛載/卸載，但不能防止用戶踏出他們的控制域。
- 例如，人們通常認為桌面員工更改他們所不擁有的特定文件（例如：部門文件共享）的所有權或權限是有益的。你絕對不會想給用戶機器的root權限，所以你會給他們
CAP_FOWNER或CAP_DAC_OVERRIDE。在SELinux下，管理員或平台供應商可以通過配置SELinux禁止所有其他未受限用戶的能力，然後新建一個給員工的受限域以在登陸後進行過渡。這種情況可以給員工修改權限的能力，但僅限於合適類型的文件。
- 例如，人們通常認為桌面員工更改他們所不擁有的特定文件（例如：部門文件共享）的所有權或權限是有益的。你絕對不會想給用戶機器的root權限，所以你會給他們
- AppArmor沒有多層安全的概念，因此也沒有硬性的貝爾-拉帕杜拉模型或比巴模型強制執行。
- AppArmor的配置通過唯一常規平面文件完成。SELinux（在大多數實現中為默認）則使用平面文件組合（在編譯前由管理員和開發者編寫人類可讀的策略）和擴展屬性完成。
- SELinux支持作為策略配置替代源的"遠程策略服務器"概念（可在/etc/selinux/semanage.conf中配置）。AppArmor的中心化管理通常十分複雜，這是因為管理員必須決定策略部署工具以root權限運行（以允許策略更新）或在每台服務器上手動配置。
Remove ads
相似系統
孤立進程也可以通過類似作業系統層虛擬化的機制實現；比如在OLPC項目的首次實現中[31]它使用了沙盒技術在輕量的Vserver環境中隔離獨立的應用程序。同樣美國國家安全局也在安全增強型Android中採用了一些SELinux概念。[32]
參見
- Grsecurity
- 以規則集為基礎的存取控制
- 簡化強制訪問控制內核
- Solaris受信擴展
- TOMOYO Linux
- FreeBSD
- Qubes OS
參考文獻
外部連結
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads