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

• Linux Capabilities 入門教程：概念篇
• Linux Capabilities 入門教程：基礎(chǔ)實(shí)戰(zhàn)篇
• Linux Capabilities 入門教程：進(jìn)階實(shí)戰(zhàn)篇

Linux capabilities 非常晦澀難懂，為此我專門寫(xiě)了兩篇文章來(lái)解釋其基本原理和設(shè)置方法。本文將會(huì)繼續(xù)研究 Linux capabilities 更高級(jí)的應(yīng)用案例，并結(jié)合 Docker 和 Kubernetes 來(lái)加深理解。

1. 快速回顧

如果你看過(guò)該系列教程的第一篇，那你應(yīng)該大致了解下面的計(jì)算公式：

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]

想不起來(lái)也沒(méi)關(guān)系，請(qǐng)回去再閱讀消化一遍，然后再來(lái)看本文，不然你會(huì)跟不上我的思路。

你還需要復(fù)習(xí)第二篇文章中的內(nèi)容，了解如何通過(guò)基本的工具來(lái)設(shè)置 capabilities。如果一切準(zhǔn)備就緒，下面我們就開(kāi)始了。

在 Ubuntu 18.04 上，以普通用戶的身份運(yùn)行 capsh 將會(huì)得到如下結(jié)果：

$ 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'b0secure-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)

可以看到普通用戶當(dāng)前所在的 shell 進(jìn)程沒(méi)有任何 capabilities（即 Effective 集合為空），Bounding 集合包含了所有 capabilities。

這個(gè)命令輸出的信息比較有限，完整的信息可以查看 /proc 文件系統(tǒng)，比如當(dāng)前 shell 進(jìn)程就可以查看 /proc/$$/status。

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

輸出中的 16 進(jìn)制掩碼表示對(duì)應(yīng)集合中的 capabilities，可以使用 capsh 對(duì)其進(jìn)行解碼：

$ 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 命令輸出的結(jié)果一樣。

如果是 root 用戶，得到的結(jié)果和普通用戶是不一樣的：

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

所有的 capabilities 都包含在了 Permitted、Effective 和 Bounding 集合中，所以 root 用戶可以執(zhí)行任何內(nèi)核調(diào)用。

2. 為可執(zhí)行文件分配 capabilities

我在上一篇文章中提到過(guò)，通過(guò)適當(dāng)?shù)呐渲?#xff0c;進(jìn)程可以獲取可執(zhí)行文件的 Bounding 集合中的 capabilities。下面通過(guò)一個(gè)例子來(lái)加深理解。

以 ping 這個(gè)命令為例，它的二進(jìn)制文件被設(shè)置了 SUID，所以可以以 root 身份運(yùn)行：

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

更安全的機(jī)制是使用 capabilities，不過(guò) Ubuntu 上面的 ping 沒(méi)有這么做。沒(méi)關(guān)系，我們可以通過(guò) ping 的源碼來(lái)自己編譯，首先克隆源代碼：

$ git clone https://github.com/iputils/iputils

安裝編譯所需的依賴：

$ sudo apt install -y ninja-build meson libcap-dev gettext

開(kāi)始編譯：

$ cd iputils $ ./configure $ make

新編譯的 ping 文件并沒(méi)有設(shè)置 SUID：

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

也沒(méi)有任何的 capabilities：

$ getcap builddir/ping/ping

所以無(wú)法正常工作：

$ builddir/ping/ping www.baidu.com builddir/ping/ping: socket: Operation not permitted

我們可以手動(dòng)設(shè)置 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

這里再活學(xué)活用一下，為什么普通用戶無(wú)法執(zhí)行 setcap 呢？因?yàn)閳?zhí)行 setcap 的用戶需要在 Permitted 集合中包含 CAP_SETFCAP capabilities，而普通用戶不具備這個(gè) capabilities，所以必須使用 root 用戶。

查看 ping 進(jìn)程的 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 是無(wú)法正常工作的。這是為啥呢？

其實(shí) ping 在執(zhí)行過(guò)程中會(huì)將 Permitted 集合中的 CAP_NET_RAW capabilities 加入 Effective 集合中，打開(kāi) Socket 之后再將該 capabilities 從 Effective 集合中移除，所以 grep 是看不到的。其中這就是我在第一篇文章提到的 ping 文件具有 capabilities 感知能力。可以通過(guò) stace 跟蹤系統(tǒng)調(diào)用來(lái)驗(yàn)證：

$ 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 集合中，下一行試圖創(chuàng)建一個(gè) IPV4 ping socket，但創(chuàng)建失敗，這是由 ping_group_range 內(nèi)核配置參數(shù)導(dǎo)致的。然后再次嘗試創(chuàng)建 IPV4 ping socket，這次創(chuàng)建成功了。IPv6 重復(fù)上面的步驟。最后將 CAP_NET_RAW capabilities 從 Effective 集合中移除。

如果 ping 二進(jìn)制文件不具備 capabilities 感知能力，即沒(méi)有調(diào)用 capset 和 capget 的權(quán)限，我們就必須要開(kāi)啟 Effective 標(biāo)志位（F(Effective)），這樣就會(huì)將該 capabilities 自動(dòng)添加到進(jìn)程的 Effective 集合中：

$ setcap 'cap_net_raw+ep' builddir/ping/ping

不明白為什么的，再好好理解下這個(gè)公式：P'(effective) = F(effective) ? P'(permitted) : P'(ambient)。

3. 特殊規(guī)則

本文不會(huì)涉及從 root 用戶切換到普通用戶時(shí) capabilities 的變化，這里面的變動(dòng)比較復(fù)雜，我也搞不清楚。我只知道 capsh --print 輸出中的 Securebits 控制著從普通用戶切換到 UID 0 或者從 UID 0 切換到普通用戶時(shí)如何繼承 capabilities。詳細(xì)的解釋可以參考 man capabilities。

4. 構(gòu)建半特權(quán)環(huán)境

前文中只用到了 Permitted 和 Effective 集合，下面再來(lái)聊聊 Ambient 和 Inheritable 集合。這兩個(gè)集合的意義就在于可以幫助我們?cè)谶M(jìn)程樹(shù)或 namespace 的范圍內(nèi)創(chuàng)建一個(gè)允許任意進(jìn)程使用某些 capabilities 的環(huán)境。

例如，我們可以在 Ambient 集合中加入 CAP_NET_BIND_SERVICE capabilities 來(lái)創(chuàng)建一個(gè)可以綁定到 80 端口的 “webserver” 環(huán)境，不需要額外的 capabilities，也不需要以 root 用戶身份運(yùn)行。webserver 可以通過(guò)解釋器或輔助腳本啟動(dòng)，并且不需要給可執(zhí)行文件設(shè)置 capabilities。如果不明白為什么，再看十分鐘這兩個(gè)公式：

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

如果理解了，再往下動(dòng)手實(shí)踐。我用 C 寫(xiě)了一個(gè)簡(jiǎn)單的程序 set_ambient，核心功能是使用 cap-ng library 將 CAP_NET_BIND_SERVICE capabilities 添加到新進(jìn)程的 Ambient 集合中。編譯完成后，需要給二進(jìn)制文件添加該 capabilities，如果它自己沒(méi)有這個(gè) capabilities，是無(wú)法將其添加到新進(jìn)程中的：

$ sudo setcap cap_net_bind_service+p set_ambient $ getcap ./set_ambient ./set_ambient = cap_net_bind_service+p

通過(guò) set_ambient 來(lái)啟動(dòng)一個(gè) bash 環(huán)境：

$ ./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 環(huán)境的 Ambient 集合中，同時(shí)也會(huì)添加到 Permitted 和 Inheritable 集合中，不明白為什么的繼續(xù)看文章開(kāi)頭的公式。。。

接著運(yùn)行一個(gè) Go Web 服務(wù)，并綁定到 80 端口，既不給它相應(yīng)的 capabilities，也不以 root 身份運(yùn)行：

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

運(yùn)行失敗，因?yàn)樗鼪](méi)有綁定到小于 1024 的端口的權(quán)限。下面利用 set_ambient 創(chuàng)建一個(gè) “webserver” 環(huán)境再運(yùn)行試試：

$ ./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

這次運(yùn)行成功了！你也可以直接執(zhí)行 ./set_ambient ./server，但使用 shell 的好處是：具有 Ambient 集合中 capabilities 的 bash 環(huán)境變成了一個(gè)半特權(quán)環(huán)境，在這個(gè)環(huán)境中不僅可以運(yùn)行 Web 服務(wù)，也可以運(yùn)行相關(guān)腳本和程序，而這些腳本和程序又可以正常啟動(dòng) webserver。

這個(gè)方法對(duì) Python 很有效，如果不希望給 Python 可執(zhí)行文件賦予更多的 capabilities，可以使用上面的方法來(lái)實(shí)現(xiàn)這個(gè)目的：

$ 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 集合的區(qū)別，如果想使用 Inheritable 達(dá)到上述目的，需要將 CAP_NET_BIND_SERVICE capabilities 添加到 Go web 服務(wù)可執(zhí)行文件的 Inheritable 集合中，同時(shí)還需要開(kāi)啟 Effective 標(biāo)志位。

看起來(lái)很有道理，但有一個(gè)問(wèn)題：如果可執(zhí)行文件的有效用戶是普通用戶，且沒(méi)有 Inheritable 集合，即 F(inheritable) = 0，那么 P(inheritable) 將會(huì)被忽略（P(inheritable) & F(inheritable)）。由于絕大多數(shù)可執(zhí)行文件都是這種情況，因此 Inheritable 集合的可用性受到了限制。

5. 容器與 capabilities

如果你理解了上一節(jié)的內(nèi)容，應(yīng)該可以猜到 capabilities 和容器是相輔相成的，至少在一定程度上是這樣。

本節(jié)內(nèi)容將在容器中實(shí)踐 capabilities。我已經(jīng)創(chuàng)建了一個(gè)測(cè)試鏡像，并安裝了 capsh 和上文所述的程序，代碼在 GitHub 倉(cāng)庫(kù)中。如果不加任何參數(shù)直接運(yùn)行容器，結(jié)果如下：

$ 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

和宿主機(jī)還是有些區(qū)別的，容器中的 root 用戶并沒(méi)有包含所有的 capabilities，比如 SYS_TIME。如果你可以在容器中修改系統(tǒng)時(shí)間，那么宿主機(jī)和其他容器中的系統(tǒng)時(shí)間都會(huì)被改變。

另外需要注意的是，容器中的 Ambient 集合是空的，目前在 Docker 和 Kubernetes 中還無(wú)法配置 Ambient 集合，過(guò)在底層的 runc 運(yùn)行時(shí)中是可以配置的。具體參考 Kubernetes 項(xiàng)目的 issue。

如果使用指定的用戶運(yùn)行容器，會(huì)得到全新的結(jié)果：

$ docker run -it --user=nobody amouat/caps$ grep Cap /proc/$BASHPID/status CapInh: 00000000a80425fb CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 00000000a80425fb CapAmb: 0000000000000000

Permitted 和 Effective 集合被清空了，這跟上文提到的特殊規(guī)則有關(guān)，從 root 用戶切換到普通用戶， Permitted 和 Effective 集合中的 capabilities 都會(huì)被清空。可以通過(guò)將 capabilities 添加到可執(zhí)行文件的 Inheritable 集合中，同時(shí)開(kāi)啟 Effective 標(biāo)志位來(lái)使其正常工作。amouat/caps 已經(jīng)包含了一個(gè)具備此條件的可執(zhí)行文件，可以用來(lái)測(cè)試一下：

$ 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 實(shí)現(xiàn)一個(gè)可以正常工作的非 root 環(huán)境，需要使用上文所述的 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 最簡(jiǎn)單最常見(jiàn)的方法是 --cap-drop 和 --cap-add 參數(shù)，這些參數(shù)只會(huì)影響所有用戶的 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 身份或普通用戶身份運(yùn)行容器，例如：

$ 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

現(xiàn)在容器中的進(jìn)程只有單一的 NET_BIND_SERVICE capabilities，并且是以非 root 用戶身份運(yùn)行的。即使容器的進(jìn)程被黑客攻擊，攻擊者只會(huì)擁有有限的文件系統(tǒng)權(quán)限，無(wú)法施展拳腳。

Docker 中還有一個(gè)選項(xiàng)可以防止容器中的用戶獲得新的 capabilities，它可以有效阻止攻擊者提升權(quán)限來(lái)避免受到攻擊，同時(shí)也阻止了再容器中執(zhí)行 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

詳細(xì)解釋可參考 no_new_privs。

對(duì)于容器玩家，我的最終建議是：移除所有非必要的 capabilities，并以非 root 身份運(yùn)行。 使用 Ambient 集合與可執(zhí)行文件的 capabilities 進(jìn)行邏輯運(yùn)算可以得到一個(gè)相對(duì)安全的容器環(huán)境，大部分情況下應(yīng)該不需要使用 set_ambient 這樣的輔助程序。

Linux capabilities 與容器領(lǐng)域有著緊密的聯(lián)系，我很期待看到 Ambient capabilities 被廣泛應(yīng)用到容器領(lǐng)域，以支持以非 root 身份運(yùn)行的半特權(quán)容器。

總結(jié)

以上是生活随笔為你收集整理的Linux Capabilities 入门教程--进阶实战篇的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。