Pages

Tuesday, 24 May 2016

SELinux初探

小州老師上課提到的重點,整合在底下。

之前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啦!

參考資料: