摘要：傳統UNIX系統的訪問控制模型非常簡單--普通用戶對超級用戶。在這種模型中，一個進程或者帳戶要麼只有很小的權限，要麼具有全部的系統權限。顯然，這樣對系統的安全沒有什麼好處。從Linux-2.1內核開始，引入了能力(capability)的概念，實現了更細粒度的訪問控制。
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系統調用成功，系統的諍司突嶠 ⒁桓鑫募 枋齜 Ｈ緩螅 綣 盞蕉粱蛘噝吹那肭螅 諍司褪褂謎飧鑫募 枋齜 魑 桓鍪 萁峁溝乃饕 燜饗喙氐牟僮魘欠裨市懟Ｕ饈且恢旨觳槿ㄏ薜撓行Х絞劍 諡蔥衞pen系統調用是，內核一次性建立必要的數據結構，然後的讀寫等操作檢查只需要在數據結構中梭梭即可。對能力的操作包括：複製能力、進程間的遷移能力、修改一個能力以及撤消一個能力等。修改一個能力類似與把一個可以讀寫的文件描述符改爲只讀。目前，各種系統對能力的應用程度並不相同。
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的能力，並說明了如何使用相關的工具加強系統的安全性。但是，能力還守制於文件系統的擴展，並不是非常完善。