Linux Capabilities 入門教程：進階實戰篇

原文連接：fuckcloudnative.io/posts/linux…

該系列文章總共分爲三篇：

• Linux Capabilities 入門教程：概念篇
• Linux Capabilities 入門教程：基礎實戰篇
• Linux Capabilities 入門教程：進階實戰篇

Linux capabilities 很是晦澀難懂，爲此我專門寫了兩篇文章來解釋其基本原理和設置方法。本文將會繼續研究 Linux capabilities 更高級的應用案例，並結合 Docker 和 Kubernetes 來加深理解。

1. 快速回顧

若是你看過該系列教程的第一篇，那你應該大體瞭解下面的計算公式：

P'(ambient) = (file is privileged) ? 0 : P(ambient)

P'(permitted) = (P(inheritable) & F(inheritable)) |
(F(permitted) & P(bounding))) | P'(ambient)

P'(effective) = F(effective) ? P'(permitted) : P'(ambient)

P'(inheritable) = P(inheritable) [i.e., unchanged]

P'(bounding) = P(bounding) [i.e., unchanged]

想不起來也不要緊，請回去再閱讀消化一遍，而後再來看本文，否則你會跟不上個人思路。

你還須要複習第二篇文章中的內容，瞭解如何經過基本的工具來設置 capabilities。若是一切準備就緒，下面咱們就開始了。

在 Ubuntu 18.04 上，以普通用戶的身份運行 capsh 將會獲得以下結果：

$ capsh --print
Current: =
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) uid=1000(fox) gid=1000(fox) groups=4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd),114(docker),1000(fox) 複製代碼

能夠看到普通用戶當前所在的 shell 進程沒有任何 capabilities（即 Effective 集合爲空），Bounding 集合包含了全部 capabilities。

這個命令輸出的信息比較有限，完整的信息能夠查看 /proc 文件系統，好比當前 shell 進程就能夠查看 /proc/$$/status。

$ grep Cap /proc/$$/status
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000003fffffffff
CapAmb:	0000000000000000
複製代碼

輸出中的 16 進制掩碼錶示對應集合中的 capabilities，可使用 capsh 對其進行解碼：

$ capsh --decode=0000003fffffffff
0x0000003fffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read
複製代碼

和 capsh --print 命令輸出的結果同樣。

若是是 root 用戶，獲得的結果和普通用戶是不同的：

$ grep Cap /proc/$$/status
CapInh:	0000000000000000
CapPrm:	0000003fffffffff
CapEff:	0000003fffffffff
CapBnd:	0000003fffffffff
CapAmb:	0000000000000000
複製代碼

全部的 capabilities 都包含在了 Permitted、Effective 和 Bounding 集合中，因此 root 用戶能夠執行任何內核調用。

2. 爲可執行文件分配 capabilities

我在上一篇文章中提到過，經過適當的配置，進程能夠獲取可執行文件的 Bounding 集合中的 capabilities。下面經過一個例子來加深理解。

以 ping 這個命令爲例，它的二進制文件被設置了 SUID，因此能夠以 root 身份運行：

$ which ping
/bin/ping
$ ls -l /bin/ping
-rwsr-xr-x 1 root root 64424 Mar 9 2017 /bin/ping
複製代碼

更安全的機制是使用 capabilities，不過 Ubuntu 上面的 ping 沒有這麼作。不要緊，咱們能夠經過 ping 的源碼來本身編譯，首先克隆源代碼：

$ git clone https://github.com/iputils/iputils
複製代碼

安裝編譯所需的依賴：

$ sudo apt install -y ninja-build meson libcap-dev gettext
複製代碼

開始編譯：

$ cd iputils
$ ./configure
$ make
複製代碼

新編譯的 ping 文件並無設置 SUID：

$ ls -l builddir/ping/ping
-rwxrwxr-x 1 fox fox 168K Oct 19 15:26 builddir/ping/ping
複製代碼

也沒有任何的 capabilities：

$ getcap builddir/ping/ping
複製代碼

因此沒法正常工做：

$ builddir/ping/ping www.baidu.com
builddir/ping/ping: socket: Operation not permitted
複製代碼

咱們能夠手動設置 capabilities：

$ setcap 'cap_net_raw+p' builddir/ping/ping
unable to set CAP_SETFCAP effective capability: Operation not permitted

$ sudo setcap 'cap_net_raw+p' builddir/ping/ping

$ getcap builddir/ping/ping
builddir/ping/ping = cap_net_raw+p

$ builddir/ping/ping www.baidu.com -c 1
PING www.a.shifen.com (180.101.49.12) 56(84) bytes of data.
64 bytes from 180.101.49.12 (180.101.49.12): icmp_seq=1 ttl=53 time=10.0 ms

--- www.a.shifen.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 10.028/10.028/10.028/0.000 ms
複製代碼

這裏再活學活用一下，爲何普通用戶沒法執行 setcap 呢？由於執行 setcap 的用戶須要在 Permitted 集合中包含 CAP_SETFCAP capabilities，而普通用戶不具有這個 capabilities，因此必須使用 root 用戶。

查看 ping 進程的 capabilities：

$ builddir/ping/ping wwwww.baidu.com > /dev/null&
[1] 9823

$ grep Cap /proc/9823/status
CapInh:	0000000000000000
CapPrm:	0000000000002000
CapEff:	0000000000000000
CapBnd:	0000003fffffffff
CapAmb:	0000000000000000

$ $ capsh --decode=0000000000002000
0x0000000000002000=cap_net_raw
複製代碼

只有 Permitted 集合中包含了 CAP_NET_RAW capabilities，Effective 集合中並不包含，按常理 ping 是沒法正常工做的。這是爲啥呢？

其實 ping 在執行過程當中會將 Permitted 集合中的 CAP_NET_RAW capabilities 加入 Effective 集合中，打開 Socket 以後再將該 capabilities 從 Effective 集合中移除，因此 grep 是看不到的。其中這就是我在第一篇文章提到的 ping 文件具備 capabilities 感知能力。能夠經過 stace 跟蹤系統調用來驗證：

$ sudo strace builddir/ping/ping -c 1 wwwww.baidu.com
...
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=1<<CAP_NET_ADMIN|1<<CAP_NET_RAW, inheritable=0}) = 0 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_NET_RAW, permitted=1<<CAP_NET_ADMIN|1<<CAP_NET_RAW, inheritable=0}) = 0 socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission denied) socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) = 3 socket(AF_INET6, SOCK_DGRAM, IPPROTO_ICMPV6) = -1 EACCES (Permission denied) socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6) = 4 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0 capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=1<<CAP_NET_RAW, permitted=1<<CAP_NET_ADMIN|1<<CAP_NET_RAW, inheritable=0}) = 0 capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=1<<CAP_NET_ADMIN|1<<CAP_NET_RAW, inheritable=0}) = 0 ... 複製代碼

第三行表示 CAP_NET_RAW capabilities 被添加到了 Effective 集合中，下一行試圖建立一個 IPV4 ping socket，但建立失敗，這是由 ping_group_range 內核配置參數致使的。而後再次嘗試建立 IPV4 ping socket，此次建立成功了。IPv6 重複上面的步驟。最後將 CAP_NET_RAW capabilities 從 Effective 集合中移除。

若是 ping 二進制文件不具有 capabilities 感知能力，即沒有調用 capset 和 capget 的權限，咱們就必需要開啓 Effective 標誌位（F(Effective)），這樣就會將該 capabilities 自動添加到進程的 Effective 集合中：

$ setcap 'cap_net_raw+ep' builddir/ping/ping
複製代碼

不明白爲何的，再好好理解下這個公式：P'(effective) = F(effective) ? P'(permitted) : P'(ambient)。

3. 特殊規則

本文不會涉及從 root 用戶切換到普通用戶時 capabilities 的變化，這裏面的變更比較複雜，我也搞不清楚。我只知道 capsh --print 輸出中的 Securebits 控制着從普通用戶切換到 UID 0 或者從 UID 0 切換到普通用戶時如何繼承 capabilities。詳細的解釋能夠參考 man capabilities。

4. 構建半特權環境

前文中只用到了 Permitted 和 Effective 集合，下面再來聊聊 Ambient 和 Inheritable 集合。這兩個集合的意義就在於能夠幫助咱們在進程樹或 namespace 的範圍內建立一個容許任意進程使用某些 capabilities 的環境。

例如，咱們能夠在 Ambient 集合中加入 CAP_NET_BIND_SERVICE capabilities 來建立一個能夠綁定到 80 端口的 "webserver" 環境，不須要額外的 capabilities，也不須要以 root 用戶身份運行。webserver 能夠經過解釋器或輔助腳本啓動，而且不須要給可執行文件設置 capabilities。若是不明白爲何，再看十分鐘這兩個公式：

P'(ambient) = (file is privileged) ? 0 : P(ambient) P'(effective) = F(effective) ? P'(permitted) : P'(ambient)

若是理解了，再往下動手實踐。我用 C 寫了一個簡單的程序 set_ambient，核心功能是使用 cap-ng library 將 CAP_NET_BIND_SERVICE capabilities 添加到新進程的 Ambient 集合中。編譯完成後，須要給二進制文件添加該 capabilities，若是它本身沒有這個 capabilities，是沒法將其添加到新進程中的：

$ sudo setcap cap_net_bind_service+p set_ambient
$ getcap ./set_ambient
./set_ambient = cap_net_bind_service+p
複製代碼

經過 set_ambient 來啓動一個 bash 環境：

$ ./set_ambient /bin/bash
Starting process with CAP_NET_BIND_SERVICE in ambient
$ grep Cap /proc/$BASHPID/status
CapInh: 0000000000000400
CapPrm: 0000000000000400
CapEff: 0000000000000400
CapBnd: 0000003fffffffff
CapAmb: 0000000000000400
$ capsh --decode=0000000000000400
0x0000000000000400=cap_net_bind_service
$ exit
複製代碼

能夠看到 CAP_NET_BIND_SERVICE capabilities 被添加到 bash 環境的 Ambient 集合中，同時也會添加到 Permitted 和 Inheritable 集合中，不明白爲何的繼續看文章開頭的公式。。。

接着運行一個 Go Web 服務，並綁定到 80 端口，既不給它相應的 capabilities，也不以 root 身份運行：

$ $ ./server
2019/09/09 13:42:06 listen tcp :80: bind: permission denied
複製代碼

運行失敗，由於它沒有綁定到小於 1024 的端口的權限。下面利用 set_ambient 建立一個 「webserver」 環境再運行試試：

$ ./set_ambient /bin/bash
Starting process with CAP_NET_BIND_SERVICE in ambient
$ ./server &
[1] 2360
$ curl localhost:80
Successfully serving on port 80
$ kill 2360
$ exit
複製代碼

此次運行成功了！你也能夠直接執行 ./set_ambient ./server，但使用 shell 的好處是：具備 Ambient 集合中 capabilities 的 bash 環境變成了一個半特權環境，在這個環境中不只能夠運行 Web 服務，也能夠運行相關腳本和程序，而這些腳本和程序又能夠正常啓動 webserver。

這個方法對 Python 頗有效，若是不但願給 Python 可執行文件賦予更多的 capabilities，可使用上面的方法來實現這個目的：

$ python3 -m http.server 80
Traceback (most recent call last):
...
PermissionError: [Errno 13] Permission denied
$ ./set_ambient /usr/bin/python3 -m http.server 80
Starting process with CAP_NET_BIND_SERVICE in ambient
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
複製代碼

最後講一下 Inheritable 與 Ambient 集合的區別，若是想使用 Inheritable 達到上述目的，須要將 CAP_NET_BIND_SERVICE capabilities 添加到 Go web 服務可執行文件的 Inheritable 集合中，同時還須要開啓 Effective 標誌位。

看起來頗有道理，但有一個問題：若是可執行文件的有效用戶是普通用戶，且沒有 Inheritable 集合，即 F(inheritable) = 0，那麼 P(inheritable) 將會被忽略（P(inheritable) & F(inheritable)）。因爲絕大多數可執行文件都是這種狀況，所以 Inheritable 集合的可用性受到了限制。

5. 容器與 capabilities

若是你理解了上一節的內容，應該能夠猜到 capabilities 和容器是相輔相成的，至少在必定程度上是這樣。

本節內容將在容器中實踐 capabilities。我已經建立了一個測試鏡像，並安裝了 capsh 和上文所述的程序，代碼在 GitHub 倉庫中。若是不加任何參數直接運行容器，結果以下：

$ docker run -it amouat/caps
root@cfeb81ec0fab:/# capsh --print
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) uid=0(root) gid=0(root) groups= root@cfeb81ec0fab:/# grep Cap /proc/$BASHPID/status CapInh: 00000000a80425fb CapPrm: 00000000a80425fb CapEff: 00000000a80425fb CapBnd: 00000000a80425fb CapAmb: 0000000000000000 複製代碼

和宿主機仍是有些區別的，容器中的 root 用戶並無包含全部的 capabilities，好比 SYS_TIME。若是你能夠在容器中修改系統時間，那麼宿主機和其餘容器中的系統時間都會被改變。

另外須要注意的是，容器中的 Ambient 集合是空的，目前在 Docker 和 Kubernetes 中還沒法配置 Ambient 集合，過在底層的 runc 運行時中是能夠配置的。具體參考 Kubernetes 項目的 issue。

若是使用指定的用戶運行容器，會獲得全新的結果：

$ docker run -it --user=nobody amouat/caps

$ grep Cap /proc/$BASHPID/status
CapInh: 00000000a80425fb
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 00000000a80425fb
CapAmb: 0000000000000000
複製代碼

Permitted 和 Effective 集合被清空了，這跟上文提到的特殊規則有關，從 root 用戶切換到普通用戶， Permitted 和 Effective 集合中的 capabilities 都會被清空。能夠經過將 capabilities 添加到可執行文件的 Inheritable 集合中，同時開啓 Effective 標誌位來使其正常工做。amouat/caps 已經包含了一個具有此條件的可執行文件，能夠用來測試一下：

$ docker run --user nobody amouat/caps getcap /inh_server
/inh_server = cap_net_bind_service+ei

$ docker run -d -p 8000:80 --user nobody amouat/caps /inh_server
d8f13e6990c5802e2beb6e435dd74bcae7959b94c1293349d33d9fe6c053c0fe

$ curl localhost:8000
Successfully serving on port 80
複製代碼

要想在容器中利用 capabilities 實現一個能夠正常工做的非 root 環境，須要使用上文所述的 set_ambient 程序。

$ docker run -p 8000:80 --user nobody amouat/caps /server
2019/09/09 19:14:13 listen tcp :80: bind: permission denied

$ docker run -d -p 8000:80 --user nobody amouat/caps /set_ambient /server
de09fe34a623c3bf40c2eea7229696acfa8d192c19adfa4065a380a583372907
$ curl localhost:8000
Successfully serving on port 80
複製代碼

在容器中限制 capabilities 最簡單最多見的方法是 --cap-drop 和 --cap-add 參數，這些參數只會影響全部用戶的 Bounding 集合，包括 root 用戶。安全的作法是移除全部的 capabilities，只添加須要的 capabilities，例如：

$ docker run --cap-drop all --cap-add NET_BIND_SERVICE -it amouat/caps capsh --print
Current: = cap_net_bind_service+eip
Bounding set =cap_net_bind_service
Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) uid=0(root) gid=0(root) groups= 複製代碼

而後就能夠以 root 身份或普通用戶身份運行容器，例如：

$ docker run --cap-drop all --cap-add NET_BIND_SERVICE \
-d -p 8000:80 --user nobody amouat/caps /set_ambient /server
9c176555ea86add95839d02b6c2c5ae7d8a3fd79e36f484852b8f8641104aac1

$ curl localhost:8000
Successfully serving on port 80

$ docker top 9c17
UID ... CMD
nobody ... /server
複製代碼

如今容器中的進程只有單一的 NET_BIND_SERVICE capabilities，而且是以非 root 用戶身份運行的。即便容器的進程被黑客攻擊，攻擊者只會擁有有限的文件系統權限，沒法施展拳腳。

Docker 中還有一個選項能夠防止容器中的用戶得到新的 capabilities，它能夠有效阻止攻擊者提高權限來避免受到攻擊，同時也阻止了再容器中執行 set_ambient 程序。例如：

$ docker run -p 8000:80 --security-opt=no-new-privileges:true \
--user nobody amouat/caps /set_ambient /server
Cannot set cap: Operation not permitted
複製代碼

詳細解釋可參考 no_new_privs。

對於容器玩家，個人最終建議是：移除全部非必要的 capabilities，並以非 root 身份運行。 使用 Ambient 集合與可執行文件的 capabilities 進行邏輯運算能夠獲得一個相對安全的容器環境，大部分狀況下應該不須要使用 set_ambient 這樣的輔助程序。

Linux capabilities 與容器領域有着緊密的聯繫，我很期待看到 Ambient capabilities 被普遍應用到容器領域，以支持以非 root 身份運行的半特權容器。