Selinux是什麼?

在新的基於RHEL通常都自帶了selinux，多數狀況下咱們把selinux禁用了，事實上既然RHEL要集成它，必然有他的優勢和長處，咱們經過下文來了解selinux，也許你會喜歡用上它。

英文原文來自www.RedHat.com
by Russell Coker
翻譯：胡智江
主要內容
介紹：
SELinux概覽：
SELinux深刻研究：
Fedora中策略的實現：
Fedora的缺省SELinux策略：
更多關於SELinux的資料：
關於做者和譯者：

介紹：
當今世界，無處不在高速互聯網鏈接、如備有無線接入點的咖啡館和在網上處處傳播的各類黑客工具使得出於對計算機安全的考慮成爲老生常談。出於解決安全問題，NSA在Linux社區的幫助下開發了一種訪問控制體系，在這種訪問控制體系的限制下，進程只能訪問那些在他的任務中所須要文件。這種體系叫作 Security-Enhanced Linux或簡化爲SELinux。

SELinux概覽：

SELinux是一種基於 域-類型 模型（domain-type）的強制訪問控制（MAC）安全系統，它由NSA編寫並設計成內核模塊包含到內核中，相應的某些安全相關的應用也被打了SELinux的補丁，最後還有一個相應的安全策略。

衆所周知，標準的UNIX安全模型是"任意的訪問控制"DAC。就是說，任何程序對其資源享有徹底的控制權。假設某個程序打算把含有潛在重要信息的文件仍到/tmp目錄下，那麼在DAC狀況下沒人能阻止他！

而MAC狀況下的安全策略徹底控制着對全部資源的訪問。這是MAC和DAC本質的區別。

SELinux裏實現的MAC容許程序在/tmp目錄下創建文件，也容許這個文件按照UNIX權限字的要求對全世界可讀，可是當UNIX許可檢查應用後， SELinux許可檢查還要進一步判斷對資源的訪問是否被許可。
換 句話說，儘管某些UNIX文件的權限被設定爲0777可是你也許仍然會被禁止讀，寫和執行該UNIX文件。在只有DAC的狀況下，用戶能夠查看或更改屬於 他的任何文件。SELinux則能夠限制每個進程對各類資源的訪問，和訪問的權級。就是說當一個程序在使用含有敏感數據時，這些數據會被禁止寫入那些低 權級進程可讀的文件中。

SELinux提供了比傳統的UNIX權限更好的訪問控制。

例如，管理員能夠只容許一個應用程序添加記錄到一個日誌文件但不容許其重寫或者刪除該日誌文件的內容。雖然ext2和ext3文件系統有一個 append-only標籤（使用chattr設置）,可是這屬性不區分某一個進程（不能在爲一個訪問 append-only的同時，又容許另外一個進程據有徹底可寫的權利）；另外一方面，一個應用程序能夠被容許在一個文件夾中創建文件和向其寫入數據，但不能 刪除文件：這種特性是沒有SELinux的普通的Linux內核所不能作到的。還有，網絡應用程序能夠綁定到其須要的端口上（如BIND的53端口），但不能綁定其它端口。

域-類型模型意味着在安全域中運行着的每個進程和每個資源（通常文件、目錄文件和套接字等）都有一個與之相聯繫的"類型"（type）。

在這基礎之上創建了一系列規則，這些規則列出了某個域能夠在每個類型上執行的全部動做。 域-類型模型的一個優勢就是咱們能夠對策略進行分析，從而判斷出哪些信息有可能外溢。在標準的UNIX環境中，用戶通常可使用ps命令來互相查看彼此的 進程列表，然而這也會爲攻擊者提供有價值的信息。甚至就算徹底阻止用戶使用ps命令，信息仍是會意外的或故意的泄露，其實在一個給定的UNIX環境中，哪 些信息會發生泄露是沒法判斷的。

而在SELinux狀況下，咱們會有不少工具用來分析SELinux策略並判斷哪些信息泄露是可能的。舉個例子，假若有兩個應用程序被容許向一個日 志文件添加數據，且他們互相不能直接通訊。那麼若是一個其中進程又得到了對該日誌的讀權限的話，那麼一個單方通訊就有可能造成。

對訪問/etc/shadow文件作訪問限制是個很好的例子，經過該例子咱們能夠看出策略分析的好處。
若是你裝了Fedora Core 3,而且選擇了嚴格的SElinux策略配置，那麼將會有17個域被容許訪問shadow_t(/etc/shadow的type)，其中有9個域據有寫 權利。這17個域中有2個能夠從用戶域（user domain）進入，他們是/usr/bin/passwd和 /sbin/unix_chkpwd(一個爲無特權應用程序提供密碼檢查的輔助程序，好比向鎖屏程序就須要使用到unix_chkpwd)。這17個域中 的某些域是爲一些不常見的應用程序準備的（如radius_t域就是爲RADIUS服務器準備的），因此，也就是說，就算除去這個不經常使用的域，通常的系統 中還有16個可訪問的域可以訪問/etc/shadow呢！

值得注意的是，Fedora髮型版的SELinux策略已經變得愈來愈靈活；將來版本的策略也許會使何以訪問/etc/shadow的域超過17 個，這取決於可調節選項的實際配置。還要注意的是，17這個數字是基於嚴格的策略設定以後而得出的，實際上一個默認的安裝會大於這個數字。

在一個沒有SE的機器上，任何以root身份運行的進程均可以訪問/etc/shadow文件。這意味着任何被"SETUID root"的二進制代碼或以root身份運行的網絡服務守護進程，它們所產生的任何安全問題都將會是災難性的。

SELinux容許咱們限制這些守護進程只訪問其所需：
BIND只能在53端口提供服務、DHCP服務器可使用原始套接字（raw network access）、DHCP客戶端也可使用原始套接字並能夠改變網絡接口，可是它們誰都別想訪問/etc/shadow,/home,/root等等這些重要的資源。
因此，在SElinux的狀況下，若是BIND受到了危害，它最多也就是發送一些僞造的報文罷了。若是DHCPD受到了危害，最壞的可能就是你的ip地址分配被搞亂。這比root權力被遠程濫用好多了！

你們很清楚，一個進程能夠援引另外一個進程。

在這種狀況下，拿DHCPD爲例，DHCPD也許會嘗試援引 /sbin/unix_chkpwd對密碼進行強力攻擊。（But even that potential vulnerability is closed）:SELinux可以提供"過渡"規則，這種規則能夠用來判斷各類域間過渡是否合法。有了"過渡"規則之後，由用戶執行的屏幕保護程序能夠 順利過渡到/sbin/unix_chkpwd這樣一個特權域，然而DHCPD就別想了。

上述這些限制功能可使你對系統的狀態瞭如指掌。若是你發現你的DHCP服務器有BUG，那你只要簡單的升級DHCP服務器到新版本而且肯定每個客戶端都能正常得到IP地址就能夠了。但是若是沒有SE的話，你還要考慮你的新服務器是否已被黑客入侵併擦除了痕跡。

      SElinux 對不一樣的域作了嚴格的隔離。我之前運行一個Debian系統有兩年時間，在這期間我開放了他的root密碼。最近兩個月我在一個Fedora系統上作一樣 的事情。但這兩個系統已經抵抗住了不少次以root身份的攻擊（見httphttp://www.coker.com.au/selinux /play.html）。（譯者注：這裏有一些做者對其playmachine的介紹被忽略了）

爲了給RHEL4作代碼測試，Fedora core 2已經嘗試集成了SELinux，可是默認是關閉的。並且未來RHEL和Fedora Core的SE還會有很是大的差異的。咱們計劃在RHEL中，將把SELinux的策略設置的比Fedora Core要嚴格，咱們相信這樣作也符合用戶的要求。將來的Fedora版本的SELinux策略將會愈來愈嚴格，但再嚴格也不會超過RHEL。

SELinux深刻研究：

SELinux的策略數據庫控制着SELinux的方方面面。它能夠判斷一個程序可能會運行在哪一個域中，還能夠說明某個域能夠訪問哪些資源。這種規 定被叫作規則，一個典型的策略每每擁有100,000條規則。別被這數字嚇壞，咱們根本沒必要去關心它，由於當咱們撰寫策略時，咱們可使用高級宏，這些高 級宏的一行就能生成10,000條規則。除了宏之外，還有一些工具，使用他們能夠分析這些生成的規則是否能達到你對安全的要求。其實再和設置每一個文件的 UNIX 權限位這樣的工做比起來，這100,000個規則也是至關小的工做量了。

Fedora Core 2安全策略的目標是知足大多數用戶無需改動就能夠工做的要求，但也有一些普通的簡單的選項能夠調節策略，通常都是簡簡單單的一行選項。好比是否容許用戶通 過dmesg閱讀內核的日誌，是否容許管理員（sysadm_r）直接經過SSH登錄或登錄圖形會話，還有是否容許用戶綁定TCP套接字。
那 100,000個左右的規則存儲在一個大約2.6MB的文件中，當系統啓動時隨內核一塊兒裝入內存並佔用一樣大小（大約2.6MB）的內核空間。 Fedora Core 3默認的strict策略有着多餘290,000條規則，佔用7MB的內核空間。Fedora Core 3默認的target策略有大約5,000條規則，佔用150K的內核空間。

目前，SELinux並無在內存使用方面進行優化；但如今對這些優化工做已經有了計劃和一些下降內存使用的方法。若是你不打算使用某些守護進程， 你能夠簡單的將其對應的策略文件刪除以便得到佔用空間更少的策略。2003年，在Ottawa舉辦的一次Linux討論會上，我提交過一篇文章，那是關於 我在把 SELinux移植到HP iPAQ PDA上所作的工做的文章(在http //archive.linuxsymposium.org/ols2003/Proceedings/能夠得到)。

證實我可使SELinux（且選擇 strict策略）很好的工做在一臺只有 64 MBs的RAM 和32 MBs 存儲空間的小平臺上，而且我相信我還可使它運行在更小的平臺上。針對Fedora Core2系統，咱們只把目光定位在目前最多見的硬件平臺，從而得出了默認的策略配置。但那些使用老機器的用戶們也許會但願配置出最小限度的策略以便減小 內存使用和提升性能。

在使用了SELinux的系統中，每個進程的上下文都包含三個組成部分：一個ID（identity），一個角色（role）和一個域（domain）

ID是指這個進程的全部者，就是UNIX帳戶，但前提是這個帳戶必須被預先編譯到SELinux策略中去使SELinux認識這個帳戶，否則的話 SELinux默認地將那些未知的系統進程ID記爲 system_u ，將那些未知的用戶進程ID記爲 user_u；角色用來判斷某個處於此角色的ID能夠進入哪些域，還用來防止某個處於此角色的ID進入其它不應進入的域。好比， user_r角色就不容許進入 sysadm_t （重要的系統管理域）。

換句話說就是，那些只有 user_u ID的進程只能扮演 user_r 這個角色，而 user_r 這個角色 永遠不能被許可進入 sysadm_t 域。從而，那些只有 user_u 這個ID的人是別想進入 sysadm_t 域的。這些特點在缺省的Fedora Core2策略中並無徹底使用，當前咱們只是把努力花在制定守護進程上，而對用戶域的策略限制的不多（targeted策略沒有對用戶登錄作任何限 制）。

一個安全上下文能夠像 identity:role:domain 這樣一種描述符的方式簡明的表現出來。

好比，典型的系統管理上下文能夠表示成 root:sysadm_r:sysadm_t 。任何能夠被訪問的對象均可以這樣來表示。值得注意的是，"域"其實也是和一個進程相對應的一個"類型"。因此當檢查某個進程是否有權向另外一個進程發送信 號（好比爲ps命令檢閱/proc文件系統）時，接受信號的進程的"域"就會充當"域-類型"模型中的"類型"的角色，從而完成"域-類型"的規則檢查。 即完成了進程間通訊權限的檢查。因爲對於文件尚未使用角色這個機制，因此目前每一個文件都被規定爲object_r 角色（這個角色只是佔個位置罷了，對策略沒有任何影響）。

文件的ID就是文件建立者的ID。constraints 策略源文件中使用這個方式來判斷一個訪問是否有權改變某個文件的上下文描述符。除非被訪問的文件的描述符中的ID字段和訪問該文件的進程的全部者ID字段 相同，不管是改變前仍是改變後，不然進程無權改變一個文件的上下文描述符。

例如，一個擁有 rjc:user_r:user_t 描述符的進程能夠將一個擁有 rjc:object_r:user_games_rw_t 描述符的文件的描述符改成rjc:object_r:user_games_ro_t ，可是它無權改變一個擁有 john:object_r:user_games_rw_t 描述符的文件的任何屬性。

要想查看當前運行的進程的上下文描述符，可使用ps命令並加入 "-Z"選項，如例一："ps ax -Z的輸出"：
  PID CONTEXT                                  COMMAND
1634 root:user_r:user_t                       -bash
1662 root:user_r:user_t                       ps ax -Z

Example 1. Example Output of ps ax -Z

要想查看目錄下的文件的上下文描述符，可使用ls命令並加入 "-Z"選項，如例一："ls -Z的輸出"：
drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
drwxr-xr-x  root     root     system_u:object_r:device_t       dev
drwxr-xr-x  root     root     system_u:object_r:etc_t          etc
drwxr-xr-x  root     root     system_u:object_r:home_root_t    home
drwxr-xr-x  root     root     system_u:object_r:root_t         initrd
drwxr-xr-x  root     root     system_u:object_r:lib_t          lib
drwx------  root     root     system_u:object_r:lost_found_t   lost+found
drwxr-xr-x  root     root     system_u:object_r:default_t      misc
drwxr-xr-x  root     root     system_u:object_r:mnt_t          mnt
drwxr-xr-x  root     root     system_u:object_r:usr_t          opt
?---------  ?        ?                                         oracle
dr-xr-xr-x  root     root                                      proc
drwxr-x---  root     root     system_u:object_r:user_home_dir_t root
drwxr-xr-x  root     root     system_u:object_r:sbin_t         sbin
drwxr-xr-x  root     root                                      selinux
drwxr-xr-x  root     root     system_u:object_r:default_t      srv
drwxr-xr-x  root     root                                      sys
drwxrwxrwt  root     root     system_u:object_r:tmp_t          tmp
drwxr-xr-x  root     root     system_u:object_r:usr_t          usr
drwxr-xr-x  root     root     system_u:object_r:var_t          var

Example 2. Example Output of ls -Z

值得注意的是：對於那些沒有指定上下文的文件（通常是指那些不支持rwx標籤的文件系統，如/sys、/proc、/selinux），ls命令就 不會顯示其上下文。對於不能用stat命令查看當前狀態的那些文件系統。ls命令返回"?---------",其全部者和全部組也被標記爲"？"，一樣 的，他的上下文也不會顯示。
      如例三所示，id命令將返回當前shell的上下文
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=root:user_r:user_t
Example 3. Example Output of the id Command

      若是你的SELinux系統使用了strict 策略，你會發現應用程序作一些不正常的事情是很容易發生的。你常常會發現某些程序中會有些bug，這些bug使程序作那些你的SELinux策略不容許其作的其它事情。
SELinux 要求進程的上下文只有在被執行的"那一刻"才容許改變。新進程的域和角色信息能夠從exec系統函數的上下文和文件類型中自動得到。進程也能夠在執行 exec以前被指明上下文。這些過程天然受SELinux策略的控制，由於ID，角色和域都受SELinux策略的控制。

Fedora中策略的實現：

從 Fedora Core 3 開始，SELinux的策略數據存儲於/etc/security/selinux/X/src/policy/目錄下（X指你選則的策略，能夠是 "strict" 或者 "targeted"）。在這個目錄中，你可使用"make load"來編譯並裝在策略。也就是用那個命令將策略編譯成二進制格式並裝在到內核中，並當即生效。除了裝如內核，該命令還將策略的二進制格式存儲到 /etc/selinux/X/policy/policy.YY文件中，這裏X指你選則的策略，能夠是"strict" 或者 "targeted"，YY是策略的版本號（Fedora Core 3支持最新的版本是18）。這是爲了在系統開機的第一時間，init能夠迅速裝載策略到內核。/etc/selinux/config這個配置文件用來告 訴init那些策略須要裝載。

當你啓動一個SELinux時，init所作的第一件事就是掛載/proc文件系統，並判斷SELinux是否被激活。init經過 selinuxfs文件系統類型來判斷內核中是否有SELinux，若是內核中沒有SELinux或者內核參數中 selinux=0 這一項，那麼系統就會以一種叫作 non-SE的狀態被繼續引導啓動。若是發現了SELinux，那麼/selinux虛擬文件系統將被建立，而後，init經過 /selinux/policyvers來檢查內核所支持的SELinux版本。最後，相應的策略數據 /etc/selinux/X/policy/policy.YY就會被裝在到內核中去了。

當策略被裝載完以後，全部正在運行着的進程（指的就是init和內核的全部線程）都將被指定 system_u:system_r:kernel_t 這樣一種上下文（內核線程其實不管在什麼時間被建立，其上下文都是system_u:system_r:kernel_t ）。當init裝載完策略以後，它還要從新執行本身。策略中有一個規則叫domain_auto_trans(kernel_t, init_exec_t, init_t)。他的意思就是當 kernel_t 域執行了一個據有 init_exec_t 類型的可執行文件（如/sbin/init）,那麼該執行文件對應的進程的域就會自動過渡到 init_t 域（這是/sbin/init正確的所在域）。當這些都完成以後，init就繼續完成那些一般的任務來完成機器的啓動。內核線程自始至終都以 kernel_t 這個類型運行。

文件和目錄的上下文存儲於擴展屬性當中 (XATTRs)。更多關於XATTRs的信息請參考attr(5), getfattr(1) 和 setfattr(1)的manpage。

簡單的說，一個XATTR就是硬盤上某個文件的全部權，它由文件名和其它一些信息組成。對於每一個 persistent 文件系統來講，它的每一個文件或目錄的SELinux上下文就存儲在 security.selinux屬性當中。雖然/proc文件系統不是persistent 文件系統，但SELinux仍是在幕後爲其文件和目錄作了上下文標記，只是不能用getxattr得到罷了。和它對比，devpts文件系統（應用於 /dev/pts Unix98僞終端）中各個文件（各個僞終端）的上下文是能夠經過getxattr來得到的，並能夠經過 setxattr 來更改每一個設備的上下文（以便sshd等相似程序能夠更改tty設備的上下文）。對於那些擁有固定存儲的文件系統(ext2, ext3, Reiserfs, XFS, vfat, 等等) 有兩種選擇用於設定文件上下文：
第一種：文件系統的類型就規定了其內部每個文件英據有統一的上下文；
第二種：使用 XATTRs 爲每一個文件標記不一樣上下文。例如，在iso9660（CD-ROM）文件系統中的每個文件的上下文都是system_u:object_r:iso9660_t ，這被稱作 genfs標記。

Ext2, ext3 和XFS支持 XATTRs 並且 Fedora 系統也支持安全標記名字空間，因此Fedora默認使用 XATTRs 來標記文件的上下文，但這也是可選方法之一。由於 直到 Reiser4發佈以前 ，Hans Reiser對 支持XATTR沒多大興趣，因此Fedora的 ReiserFS 文件系統不能很好的支持SELinux標記操做。也就是說，使用 ReiserFS 文件系統做爲SELinux的根文件系統是不可能的事情。

XFS有一個與XATTRs相關的重要的問題：若是XATTRs不能被裝入超級塊（inode），那麼它們就會被裝入數據塊，每個超級塊就要使用 一個數據塊用來裝 SELinux XATTR 。創建XFS時，mkfs.xfs在默認狀況下建立的數據塊大小爲4096,超級塊大小爲256（要是用於安裝 SELinux XATTR ，大約缺乏30字節）。這就是說，默認的XFS文件系統中，每個超級塊要佔用4096字節用來裝載 SELinux XATTR ，這對於磁盤空間來講是嚴重的浪費！當你使用"-i size=512"選項建立一個XFS文件系統時，超級塊的大小就變成了512字節，這樣就能夠將SELinux XATTR 裝入超級塊，即節省了空間，又提升的性能。512字節的超級塊也有可能給其它操做帶來好處。因此，若是你使用XFS而且打算未來使用 SELinux 的話，將超級塊的大小規定爲512字節確定是個好主意。

若是你使用的是較新的內核（如最新的Fedora內核或標準2.6.8.1內核）而且使用最新的mount工具，那麼當你掛載一個文件系統時，有一 個選項能夠用來爲整個文件系統指定上下文標籤。好比你要掛載的文件系統是一個郵件池（mail spool），你可使用"-o context=system_u:object_r:mail_spool_t"選項來掛載他，這樣會將其內部的所有文件的上下文標記爲 system_u:object_r:mail_spool_t。若是你的這個郵件池很大，並且仍是XFS文件系統，這個方法還能夠避免上一段所討論的 inode大小的問題。甚至對於ext3那樣的對XATTRs 開銷較小的文件系統來講，使用context=選項掛載文件系統也會進一步減小開銷，也能夠避免爲已經創建的文件系統從新設置 SElinux上下文（若是文件系統中文件較多的話，會浪費很長的時間）。

Fedora的缺省SELinux策略：

在Fedora Core 3系統中，缺省的策略是"targeted "策略。對於此種選擇人們議論紛紛，問題在於咱們但願能使盡量多得人使用SELinux。若是人們以爲這玩意太可怕而且妨礙了人們作他們想作的事，那麼 人們會把它關掉。因此咱們在這個時候寧願爲大多數人提供適量的保護策略，也不會爲了少部分人而提供嚴格的保護策略。缺省的Fedora Core 3安裝會激活 SELinux 並使用"targeted "策略，你也能夠經過運行 system-config-securitylevel 這個程序將策略改成更加嚴格的 "strict "策略。

若是你安裝了策略的源文件包，那麼策略的源文件就在/etc/selinux/X/src/policy/目錄裏面（X指你選則的策略，能夠是 "strict" 或者 "targeted"）在這個目錄下有一個叫做domains/program/的子目錄，裏面爲每個守護進程對應了一個.te文件。你能夠刪去那些你 不使用也不打算使用的守護進程所對應的.te文件，從而減小內核內存空間的使用，並提升性能。好比，你的系統沒有BIND服務，你徹底能夠刪掉 named.te 文件。而後若是你使用"make load"命令從新裝載策略到內核的話，內核對內存的使用量就會減小。然而也要當心，若是你誤刪了其它文件，那麼你的系統將不能正常啓動進入 enforcing模式。因此目前，這種調節最好仍是由內行來作。

剛開始接觸SElinux的你，要注意一個內核參數，它用來決定你係統的內核運行於 強制（enforcing ）模式仍是自由（permissive）模式，那就是"enforcing"參數。在自由模式下SELinux只是記錄他該作什麼，而事實上並不作任何動 做。在強制模式下SElinux會來真格的。若是你的策略有錯誤，在強制模式下系統可能會阻止你登錄！因此正常狀況下你應改在啓動時傳 enforcing=1 給內核，當你的SELinux策略有問題時，你能夠臨時傳enforcing=0給內核來查錯。在/etc/selinux/config這個init的 配置文件中相應的有一個選項，經過設置它，也可使系統進入自由模式。

若是你打算停止使用SELinux，你可使用 selinux=0 這個內核參數。這會關閉SELinux的所有功能，就好像你的內核並無把SElinux機制編譯進去同樣。因此當系統出了問題時，好比系統崩潰，有些人 就用此方法進行理事的恢復工做，可是我並不同意這種作法。當你臨時使用 selinux=0 進入系統後，你所創建的任何文件將不會擁有SELinux上下文標記。這就意味着，若是你替換了諸如/etc/passwd 或/etc/shadow等重要文件，那麼下一次進入SELinux時，系統就不會正常的工做。這不是嚴重的問題，當你從CD引導時，作系統恢復時，或使 用一個不支持 XATTRs備份軟件恢復系統時，一樣的問題也會發生。這個問題雖然能夠經過爲受到影響的文件系統從新標記上下文來解決，可是使用 enforcing=0 來代替 selinux=0 不是更好嗎？
你能夠編輯/etc/selinux/config來臨時關閉SELinux。

Fedora Core 2的釋放是SELinux一次重要的發展。他是第一套提供對SELinux完整支持的主流Linux發行版本。Fedora Core 3 也是一個重要的里程碑，由於他是第一套將SELinux做爲默認安裝選項的Linux發行版本。
Red Hat Enterprise Linux 4 見會跟隨 Fedora Core 的開發步伐，其對SELinux的支持也會獲得進一步的發展。當 RHEL 4 發佈時，她將會從 Fedora Core 系統和在Fedora 上學習SELinux的用戶那裏得到很是大的益處。

你能夠在 irc.freenode.net的 IRC服務器上的#fedora-selinux頻道找到對SELinux的支持。還有 Fedora SELinux郵件列表 http://www.redhat.com/mailman/listinfo/fedora-selinux-list。我常常掛在#fedora-selinux上面，並也訂閱了郵件列表，我指望着在那裏回答您提出的任何問題。

更多關於SELinux的資料：

NSA site for Security-Enhanced Linux:http://www.nsa.gov/selinux/
Fedora Core SELinux FAQ:http://people.redhat.com/kwade/fedora-docs/selinux-faq/
IRC channel for SELinux in Fedora Core: irc.freenode.net, #fedora-selinux
Mailing list for SELinux in Fedora Core:http://www.redhat.com/mailman/listinfo/fedora-selinux-list
SELinux play machine:http://www.coker.com.au/selinux/play.html

關於做者和譯者：

Russell Coker 從2003年就爲RedHat的 SELinux 工程工做。在那以前他是一個獨立的顧問並在閒暇時間研究SELinux。他第一次瞭解SELinux 是在 2001 年Ottawa Linux 討論會上，當時 NSA 的Pete Loscocco 針對SELinux作了一個演講。在2002 的OLS 上他介紹了他如何將SELinux移植到Debian Linux上. 做爲移植工做的一部分, 他還撰寫了用於支持全部他使用的程序的策略, 這些策略後來成爲了SELinux策略的主要來源. 在OLS2003 和 Linux Kongress 2002上他也發表了文章。

譯者：胡智江，就讀於江蘇大學通訊工程系。從1999年開始使用Linux，2003年經過了RHCT認證。對Linux系統和嵌入式系統都很感興趣。翻譯這篇文章主要是爲了學習SELinux，而後和你們分享成果。但願你們對譯文的錯誤做出批評和指正。

來源：http://blog.csdn.net/flaght/article/details/2973910