2008年10月13日 星期一

SELinux初探心得

於 16:40

星期六聽了小州大哥講的SELinux後，發現SELinux真是個不錯的東西。
不過只要去Google一下SELinux，卻會出現這些東西：selinux關閉、turn off selinux 、stop selinux ...

因此小弟就在這邊將小州老師上課提到的重點，加上cdchen老師所寫的RHEL5系統管理寶典中的重點整合在底下。

之前Linux中關於檔案存取的權限處理，有幾種方法：

基礎的權限：

[billy3321@localhost practice]$ ls -l
total 32
drwxrwxr-x  2 billy3321 billy3321 4096 Oct 13 15:33 directory
-rw-rw-r--  1 billy3321 billy3321   16 Oct 13 15:32 file
-rw-rw-r--+ 1 billy3321 billy3321   25 Oct 13 15:53 file_with_acl
-rwxrwxr-x  1 billy3321 billy3321   35 Oct 13 15:24 script

相關指令：
更改擁有者

chown [OPTION]... [OWNER][:[GROUP]] FILE...

更改rwx設定

chmod [OPTION]... MODE[,MODE]... FILE...
chmod [OPTION]... OCTAL-MODE FILE...

判斷方法：
首先判斷檔案的擁有者(user)，擁有群組(group)，以及其他人(other)。以這個方式來判別讀(r)，寫(w)，執行的權限(x)。在目錄上面則是讀取(r)，修改(w)，進入目錄(x)等方式。

附帶一提，檔案的刪除或更名是看目錄的w權限。在檔案系統中，目錄事實上只是一個文件，裡面列出了目錄含有的檔案名稱，以及該檔案的inode為何。因此刪除檔案，實際上就是去移除"目錄"文件裡面關於該檔案的資訊；更名檔案，則是更改該檔案的"檔案名稱"欄位。因此刪除與更名就是編輯並修改"目錄"這個文 件。而要可以編輯修改，就要擁有w屬性，因此檔案的刪除與更名，是看目錄的w權限。

延伸的權限：
Access control lists(ACL)

[billy3321@localhost practice]$ getfacl file_with_acl 
# file: file_with_acl
# owner: billy3321
# group: billy3321
user::rw-
user:sonnet77:rw-
group::rw-
group:users:r--
mask::rw-
other::r--

相關指令：
設定ACL

setfacl [-bkndRLPvh] [{-m|-x} acl_spec] [{-M|-X} acl_file] file ...

檢視ACL設定

getfacl [-dRLPvh] file ...

判斷方式：
讀取檔案時，權限判斷會由上往下依序讀取。因此判斷方式就會更改預設的判斷流程。
原本判斷順序是user > group > other ，這邊判斷順序就改為 user > user:sonnet77 > group > group:users > other 。

以上這兩種權限在判斷上，各位都可以發現，這種判斷方式幾乎都是以擁有者，擁有群組等來判斷存取與否。在行程擁有的權限上，則會看執行者身分或是該程式的擁有者與群組。

這種判斷方式是稱為Discretionary Access Comtrol(DAC)的方式，只要你是檔案擁有者，就擁有至高無上的權力；若你還是root的話，更可以任意存取任何檔案。

舉一個之前的例子，之前OuTian大大在HITCON有揭露一個Tomcat的漏洞。由於Tomcat須以root身分執行，並bind上80 port去listen，經由這個漏洞，Tomcat可以以root身分對檔案系統為所欲為，甚至去觀看/etc/shadow密碼檔案。這就是DAC機制很大的問題，只要入侵任何Deamon行程並獲取控制權，cracker就可以觀看/etc/passwd檔案進行下一步的入侵，甚至去尋找一些設定檔案。

後來有發展出一個機制，可以將deamon行程關在一個特定目錄中，稱為chroot。若是cracker入侵該行程，也只能在該目錄中活動而無法看到重要的系統檔案。不過chroot只針對某些行程有效果，不能防範來自其他行程的攻擊。

chroot執行方式：

chroot NEWROOT [COMMAND...]
chroot OPTION


有鑒於這些設定已經無法因應目前的資訊安全要求，因此美國國家安全局(NAS)就在Linux中實作一個機制，稱為SELinux，利用資料庫查詢的方式來維護作業系統的安全。SELinux採用Mandatory Access Control(MAC)機制，會對所有的檔案、行程、用戶給予一個Security content，用戶端通過傳統DAC認證後，SELinux會進一步的去檢視Security content，並決定是否授與權限。SELinux後來在RedHat的支持下，得到了長足的進步，且收錄於2.6的核心之中。可再編譯時選擇是否將SELinux功能編入kernel之中。

下面就來簡介SELinux的運作機制及各項指令。

SELinux是由核心實作的功能，因此若是需要SELinux功能，要先確定核心中是否已將SELinux編譯進去。SELinux的啟動與否可由開機參數加以指定(selinux = [0|1])

SELinux的設定檔案可編輯/etc/sysconfig/selinux這個檔案，這是/etc/selinux/config之Symbolic Link。其中含有兩種主要的設定：

1.SELinux執行模式(SELINUX=STATUS)，可分為強制(enforce)、寬容(permissive)、以及停用(disable)。除了停用、啟用需重開機外，強制與寬容模式的切換可以setenforce來設定。要觀看目前執行模式則可以用getenforc以及較為廣域的sestatus來觀看。在強制模式中，只要SELinux不允許，就會無法執行；但在寬容模式中，只會將事件紀錄下來，依然允許執行。因此若是懷疑是SELinux造成的問題，可以將SELinux切換為寬容模式，若是依然無法執行，那麼問題就不是在SELinux上。

切換強制與寬容模式

setenforce [ Enforcing | Permissive | 1 | 0 ]

觀看目前SELinux執行模式

getenforce
sestatus [-v] [-b]

2.所使用的安全原則名稱(SELINUXTYPE=POLICY)，可概分為targeted、strict、與mls。targeted保護常見的網路服務，為預設的policy。strict提供符合Role-based-Access Control(RBAC)之policy，而mls則提供符合Multi-Level Security(MLS)的policy。這些policy放置於/etc/selinux/以policy為名的資料夾中，只有在開機時會載入。

如果想要改變policy，就得要重開機，才能重新載入policy。如果更換policy，物件的security context也要重新產生，因此在重開機前一定要記得在根目錄下放置.autorelabel檔案，這樣所有的security context才會重新產生。為了避免在開機期間因為錯誤的security context導致開機失敗，請先將selinux的執行模式更改為permissive。如果忘記更改導致開機時的kernel panic，開機時對核心參數加上selinux=0的選項暫時性的關閉SELinux系統，待其產生完畢後，再一次的重開機以打開SELinux。

對於policy的檢視，有以下方法
檢視policy規則

seinfo [OPTIONS] [POLICY_FILE]

搜尋policy規則

sesearch [OPTIONS] [POLICY_FILE]

3.但是如果SELinux只有policy可以選擇，不是太沒彈性了？因此在決定好policy後，可以使用SELinux Boolean來變更一些細項。
比如說，大家最容易為SELinux困擾的一樣設定就是Apache的home_dir設定。
只要更改httpd_enable_homedirs這項SELinux Boolean，就可以允許Apache顯示各使用者的public_html資料夾了。

以下是一些設定管理SELinux Boolean的方式

顯示指定或全部的SELinux Boolean

getsebool [-a] [boolean]

設定指定的SELinux Boolean

setsebool [ -P ] boolean value | bool1=val1 bool2=val2 ...

4.在SELinux中，每個登入的使用者根據登入的方式不同，會由PAM子系統中的pam_selinux.so模組設定該使用者執行行程的security context。此後，除非特別要求，否則子行程預設會繼承父行程的security context。在檔案的部分，由rpm所安裝的檔案會依照儲存於rpm中的紀錄來設定security context，若是手動建立，則依照policy中所制定的security context來設定。另外，如果是cp(複製)，會以新建檔案的方式重新配置security context，若是mv(搬移)，則會保留。

針對security context的操作，有以下幾種方法

檢視帳號的security context

id -Z 

檢視行程的security context

ps -Z

檢視檔案的security context

ls -Z

變更security context

chcon [OPTION]... CONTEXT FILE...
chcon [OPTION]... --reference=RFILE FILE...

修復security context，可修復來自套件的檔案

fixfiles  [-F]  [  -R  rpmpackagename[,rpmpackagename...] ] [ -C PREVI-
       OUS_FILECONTEXT ] [-l logfile ] [-o outputfile ] { check  |  restore  |
       [-F] relabel | verify }"
fixfiles  [-F]  [-l  logfile  ] [-o outputfile ] { check | restore|[-f]
       relabel | verify } [[dir/file] ... ]

還原security context，可還原原先設定的security context。

restorecon [-o outfilename ] [-R] [-n] [-v] [-e directory ] pathname...
restorecon -f infilename [-o outfilename ] [-e directory  ]  [-R]  [-n]
       [-v] [-F]

在開機時重新產生所有的security context

# touch /.autorelabel
其他設定工具
圖形化的SELinux設定工具：

system-config-selinux


了解了security context以及policy以後，我們就可以重新看SELinux究竟是怎麼運作。

當一個行程(object)去存取檔案(subject)時，Linux核心會先判斷先前提到的權限判定，若是通過了，就會進入到SELinux的判斷流程中。
1.以object與subject之security context，判斷policy中是否已有符合之規則。
2.若不符合任何規則，則傳回禁止；若符合規則，則查看規則為允許(Allow)或拒絕(Deny)。
3.若規則為拒絕(Deny)，則存取失敗；若規則為允許(Allow)，則存取成功。

以上狀況如果在enforce模式下，只有規則為允許者才可存取；若為permissive模式，所有被SELinux所拒絕的依然可以存取，只是會顯示錯誤訊息到log檔案中。

如果要檢視SELinux的錯誤訊息，可以看以下兩個檔案

/var/log/messages
/var/log/audit/audit.log

由於audit.log較不易閱讀，因此SELinux有提供工具來轉換為適合人類閱讀的模式

# audit2why < /var/log/audit/audit.log

另外也有圖形化的工具setroubleshoot，除了顯示deny的message以外，還會給予不少實用的建議。

# sealert -b


如果好好的使用，SELinux將是個強大的工具，捍衛伺服器的安全。
以後大家不要在安裝完系統就關閉SELinux啦！

參考資料：
小州老師上課講義：
RHEL5系統管理寶典：

標籤：

0 意見:

張貼留言