H's 手札

來源： http://www.linuxuser.com.tw/skill_detail.php?cid=1399

利用capability特徵加強Linux系統安全

摘要

　　傳統UNIX系統的訪問控制模型非常簡單--普通用戶對超級用戶。在這種模型中，一個進程或者帳戶要麼只有很小的許可權，要麼具有全部的系統許可權。顯然，這樣對系統的安全沒有什麼好處。從Linux-2.1內核開始，引入了能力(capability)的概念，實現了更細粒度的訪問控制。(2002-07-15 09:53:08)

By nixe0n

1.簡介

　　UNIX是一種安全作業系統，它給普通用戶儘可能低的許可權，而把全部的系統許可權賦予一個單一的帳戶--root。root帳戶用來管理系統、安裝軟體、管理帳戶、運行某些服務、安裝/卸載檔系統、管理用戶、安裝軟體等。另外，普通用戶的很多操作也需要root許可權，這通過setuid實現。
　　這種依賴單一帳戶執行特權操作的方式加大了系統的面臨風險，而需要root許可權的程式可能只是為了一個單一的操作，例如：綁定到特權埠、打開一個只有root許可權可以訪問的檔。某些程式可能有安全漏洞，而如果程式不是以root的許可權運行，其存在的漏洞就不可能對系統造成什麼威脅。
　　從2.1版開始，內核開發人員在Linux內核中加入了能力(capability)的概念。其目標是消除需要執行某些操作的程式對root帳戶的依賴。從2.2版本的內核開始，這些代基本可以使用了，雖然還存在一些問題，但是方向是正確的。

2.Linux內核能力詳解

　　傳統UNIX的信任狀模型非常簡單，就是「超級用戶對普通用戶」模型。在這種模型中，一個進程要麼什麼都能做，要麼幾乎什麼也不能做，這取決於進程的UID。如果一個進程需要執行綁定到私有埠、載入/卸載內核模組以及管理檔系統等操作時，就需要完全的root許可權。很顯然這樣做對系統安全存在很大的威脅。UNIX系統中的SUID問題就是由這種信任狀模型造成的。例如，一個普通用戶需要使用ping命令。這是一個SUID命令，會以root的許可權運行。而實際上這個程式只是需要RAW套接字建立必要ICMP資料包，除此之外的其他root許可權對這個程式都是沒有必要的。如果程式編寫不好，就可能被攻擊者利用，獲得系統的控制權。
　　使用能力(capability)可以減小這種風險。系統管理員為了系統的安全可以剝奪root用戶的能力，這樣即使root用戶也將無法進行某些操作。而這個過程又是不可逆的，也就是說如果一種能力被刪除，除非重新啟動系統，否則即使root用戶也無法重新添加被刪除的能力。

2.1.能力的概念

　　Linux內核中使用的能力(capability)概念非常容易被混淆。電腦科學中定義了很多種能力(capability)。能力就是一個進程能夠對某個物件進行的操作，它標誌物件以及允許在這個物件上進行的操作。檔描述符就是一種能力，你使用open系統調用請求獲得讀或者寫的許可權，如果open系統調用成功，系統的內核就會建立一個檔描述符。然後，如果收到讀或者寫的請求，內核就使用這個檔描述符作為一個資料結構的索引，檢索相關的操作是否允許。這是一種檢查許可權的有效方式，在執行open系統調用是，內核一次性建立必要的資料結構，然後的讀寫等操作檢查只需要在資料結構中梭梭即可。對能力的操作包括：複製能力、進程間的遷移能力、修改一個能力以及撤銷一個能力等。修改一個能力類似與把一個可以讀寫的檔描述符改為唯讀。目前，各種系統對能力的應用程度並不相同。
　　POSIX 1003.1e中也提出了一種能力定義，通常稱為POSIX能力(POSIX capabilities)，Linux中的定義不大一樣。內核使用這些能力分割root的許可權，因為傳統*NIX系統中root的許可權過於強大了。

2.2.Linux是如何使用POSIX capabilities代替傳統的信任狀模型的

　　每個進程有三個和能力有關的點陣圖：inheritable(I)、permitted(P)和effective(E)，對應進程描述符task_struct(include/linux/sched.h)裡面的cap_effective, cap_inheritable, cap_permitted。每種能力由一位表示，1表示具有某種能力，0表示沒有。當一個進程要進行某個特權操作時，作業系統會檢查cap_effective的對應位是否有效，而不再是檢查進程的有效UID是否為0。例如，如果一個進程要設置系統的時鐘，Linux的內核就會檢查cap_effective的CAP_SYS_TIME位(第25位)是否有效，
　　cap_permitted表示進程能夠使用的能力。在cap_permitted中可以包含cap_effective中沒有的能力，這些能力是被進程自己臨時放棄的，也可以說cap_effective是cap_permitted的一個子集。進程放棄沒有必要的能力對於提高安全性大有助益。例如，ping只需要CAP_NET_RAW，如果它放棄除這個能力之外的其他能力，即使存在安全缺陷，也不會對系統造成太大的損害。cap_inheritable表示能夠被當前進程執行的程式繼承的能力。

3.Linux支援的能力

　　Linux實現了7個POSIX 1003.1e規定的能力，還有21個(截止到2.4.7-10版本的內核)Linux所特有的，這些能力在/usr/src/linux/include/linux/capability.h檔中定義。其細節如下：
能力名 數字 描述
CAP_CHOWN 0 允許改變檔的所有權
CAP_DAC_OVERRIDE 1 忽略對檔的所有DAC訪問限制
CAP_DAC_READ_SEARCH 2 忽略所有對讀、搜索操作的限制
CAP_FOWNER 3 如果檔屬於進程的UID，就取消對檔的限制
CAP_FSETID 4 允許設置setuid位
CAP_KILL 5 允許對不屬於自己的進程發送信號
CAP_SETGID 6 允許改變組ID
CAP_SETUID 7 允許改變用戶ID
CAP_SETPCAP 8 允許向其他進程轉移能力以及刪除其他進程的任意能力
CAP_LINUX_IMMUTABLE 9 允許修改檔的不可修改(IMMUTABLE)和只添加(APPEND-ONLY)屬性
CAP_NET_BIND_SERVICE 10 允許綁定到小於1024的埠
CAP_NET_BROADCAST 11 允許網路廣播和多播訪問
CAP_NET_ADMIN 12 允許執行網路管理任務：介面、防火牆和路由等，詳情請參考/usr/src/linux/include/linux/capability.h文件
CAP_NET_RAW 13 允許使用原始(raw)套接字
CAP_IPC_LOCK 14 允許鎖定共用記憶體片段
CAP_IPC_OWNER 15 忽略IPC所有權檢查
CAP_SYS_MODULE 16 插入和刪除內核模組
CAP_SYS_RAWIO 17 允許對ioperm/iopl的訪問
CAP_SYS_CHROOT 18 允許使用chroot()系統調用
CAP_SYS_PTRACE 19 允許跟蹤任何進程
CAP_SYS_PACCT 20 允許配置進程記帳(process accounting)
CAP_SYS_ADMIN 21 允許執行系統管理任務：載入/卸載檔系統、設置磁片配額、開/關交換設備和檔等。詳情請參考/usr/src/linux/include/linux/capability.h文件。
CAP_SYS_BOOT 22 允許重新啟動系統
CAP_SYS_NICE 23 允許提升優先順序，設置其他進程的優先順序
CAP_SYS_RESOURCE 24 忽略資源限制
CAP_SYS_TIME 25 允許改變系統時鐘
CAP_SYS_TTY_CONFIG 26 允許配置TTY設備
CAP_MKNOD 27 允許使用mknod()系統調用
CAP_LEASE 28 Allow taking of leases on files

4.能力邊界集

　　Linux2.2內核提供了對能力的基本支援。但是在引入了能力之後遇到了一些困難，雖然2.2版本的內核能夠理解能力，但是缺乏一個系統和用戶之間的介面。除此之外，還存在其他的一些問題。從2.2.11版本開始，這種情況發生了很大的改觀，在這個版本中引入了能力邊界集(capability bounding set)的概念，解決了和系統和用戶之間的介面問題。能力邊界集(capability bounding set)是系統中所有進程允許保留的能力。如果在能力邊界集中不存在某個能力，那麼系統中的所有進程都沒有這個能力，即使以超級用戶許可權執行的進程也一樣。
　　能力邊界集通過sysctl命令導出，用戶可以在/proc/sys/kernel/cap-bound中看到系統保留的能力。在默認情況下，能力邊界集所有的位都是打開的。
　　root用戶可以向能力邊界集中寫入新的值來修改系統保留的能力。但是要注意，root用戶能夠從能力邊界集中刪除能力，卻不能再恢復被刪除的能力，只有init進程能夠添加能力。通常，一個能力如果從能力邊界集中被刪除，只有系統重新啟動才能恢復。
　　刪除系統中多餘的能力對提高系統的安全性是很有好處的。假設你有一台重要的伺服器，比較擔心可載入內核模組的安全性。而你又不想完全禁止在系統中使用可載入內核模組或者一些設備的驅動就是一些內核模組。在這種情況下，最好使系統在啟動時載入所有的模組，然後禁止載入/卸載任何內核模組。在Linux系統中，載入/卸載內核模組是由CAP_SYS_MODULE能力控制的。如果把CAP_SYS_MODULE從能力邊界集中刪除，系統將不再允許載入/卸載任何的內核模組。
　　CAP_SYS_MODULE能力的值是16，因此我們使用下面的命令就可以把它從能力邊界集中刪除：
　　echo 0xFFFEFFFF >/proc/sys/kernel/cap-bound

5.lcap

　　雖然我們可以直接修改/proc/sys/kernel/cap-bound來刪除系統的某中能力，但是這樣畢竟非常的不方便。有一個程式lcap可以幫助我們更方便的從系統中刪除指定的能力。它可以從http://home.netcom.com/~spoon/lcap/下載。編譯之後就可以直接使用。如果不帶參數，lcap可以列出系統當前支援的各種能力：
[root@nixe0n lcap-0.0.6]# ./lcap
Current capabilities: 0xFFFFFEFF
0) *CAP_CHOWN 1) *CAP_DAC_OVERRIDE
2) *CAP_DAC_READ_SEARCH 3) *CAP_FOWNER
4) *CAP_FSETID 5) *CAP_KILL
6) *CAP_SETGID 7) *CAP_SETUID
8) CAP_SETPCAP 9) *CAP_LINUX_IMMUTABLE
10) *CAP_NET_BIND_SERVICE 11) *CAP_NET_BROADCAST
12) *CAP_NET_ADMIN 13) *CAP_NET_RAW
14) *CAP_IPC_LOCK 15) *CAP_IPC_OWNER
16) *CAP_SYS_MODULE 17) *CAP_SYS_RAWIO
18) *CAP_SYS_CHROOT 19) *CAP_SYS_PTRACE
20) *CAP_SYS_PACCT 21) *CAP_SYS_ADMIN
22) *CAP_SYS_BOOT 23) *CAP_SYS_NICE
24) *CAP_SYS_RESOURCE 25) *CAP_SYS_TIME
26) *CAP_SYS_TTY_CONFIG
* = Capabilities currently allowed
　　如果我們需要刪除某個能力，直接把能力名作為參數就可以，例如我們要刪除載入/卸載內核模組的能力：
[root@nixe0n lcap-0.0.6]# ./lcap CAP_SYS_MODULE
[root@nixe0n lcap-0.0.6]# ./lcap
Current capabilities: 0xFFFBFEFF
0) *CAP_CHOWN 1) *CAP_DAC_OVERRIDE
2) *CAP_DAC_READ_SEARCH 3) *CAP_FOWNER
4) *CAP_FSETID 5) *CAP_KILL
6) *CAP_SETGID 7) *CAP_SETUID
8) CAP_SETPCAP 9) *CAP_LINUX_IMMUTABLE
10) *CAP_NET_BIND_SERVICE 11) *CAP_NET_BROADCAST
12) *CAP_NET_ADMIN 13) *CAP_NET_RAW
14) *CAP_IPC_LOCK 15) *CAP_IPC_OWNER
16) CAP_SYS_MODULE 17) *CAP_SYS_RAWIO
18) *CAP_SYS_CHROOT 19) *CAP_SYS_PTRACE
20) *CAP_SYS_PACCT 21) *CAP_SYS_ADMIN
22) *CAP_SYS_BOOT 23) *CAP_SYS_NICE
24) *CAP_SYS_RESOURCE 25) *CAP_SYS_TIME
26) *CAP_SYS_TTY_CONFIG
* = Capabilities currently allowed

6.能力邊界集的安全問題

　　能力邊界集為系統和管理員之間提供了一個便利的交互介面，但是它存在一些的脆弱性。Patrick Reynolds在提交到BugTraq的一個郵件裡詳細分析了這種脆弱性。對能力邊界集的最大威脅就是能夠被讀/寫的/dev/mem設備。在內核記憶體區中，/proc/sys/kernel/cap-bound直接影射到cap_bset變數中。如果/dev/mem可以寫，攻擊者就能夠直接修改記憶體重置cap_bset變數。從而能夠越過能力邊界集打開所有的能力。使用以下命令就可以獲得cap_bset變數的位址：
$ grep cap_bset System.map
c01f0cd5 ? __kstrtab_cap_bset
c01f7340 ? __ksymtab_cap_bset
c01fb2ac D cap_bset
　　從結果可以看出，cap_bset位於c01fb2ac。攻擊者獲得了/dev/mem的寫許可權，只要寫入0xffffffff就能夠重新打開所有的能力。
　　因此，為了維護能力邊界集的安全，你應該放棄系統的CAP_SYS_RAWIO能力。這樣會造成X系統和其他一些需要訪問/dev/mem或I/O埠的程式無法運行，不過對於伺服器來說，這是值得的。除了關閉CAP_SYS_RAWIO，還應該放棄CAP_SYS_MODULE能力。

7.侷限

　　雖然利用能力可已經以有效地保護系統的安全，但是由於檔系統的制約，Linux的能力控制還不是很完善。我們除了可以使用lcap從總體上放棄一些能力之外，伺服器軟體程式師也應該主動放棄進程的一些多餘的能力。例如，xntpd程式可以通過以下的步驟放棄沒有必要的能力，以加強安全性：
• 以完整的root許可權啟動
•
• 綁定到ntp埠
•
• 除了CAP_SYS_TIME能力之外，放棄其他的能力
•
• 放棄root許可權
•
• 以普通管理帳戶的身份進行正常的操作
•
　　但是，並不是所有的程式師能夠注意到這個問題，如果能夠直接使用chmod和chattr命令限制程式的能力將給為方便。例如：
[root@localhost /root]# chattr +CAP_BIND xntpd
　　目前，由於檔系統的制約，還無法實現。

8.結論

　　在本文，我們討論了Linux的能力，並說明了如何使用相關的工具加強系統的安全性。但是，能力還守制於檔系統的擴展，並不是非常完善。