> 原文連結：[https://fuckcloudnative.io/posts/linux-capabilities-in-practice-2/](https://fuckcloudnative.io/posts/linux-capabilities-in-practice-2/) 該系列文章總共分為三篇： + [Linux Capabilities 入門教程：概念篇](https://fuckcloudnative.io/posts/linux-capabilities-why-they-exist-and-how-they-work/) + [Linux Capabilities 入門教程：基礎實戰篇](https://fuckcloudnative.io/posts/linux-capabilities-in-practice-1/) + [Linux Capabilities 入門教程：進階實戰篇](https://fuckcloudnative.io/posts/linux-capabilities-in-practice-2/) Linux capabilities 非常晦澀難懂，為此我專門寫了兩篇文章來解釋其[基本原理](https://fuckcloudnative.io/posts/linux-capabilities-why-they-exist-and-how-they-work/)和[設定方法](https://fuckcloudnative.io/posts/linux-capabilities-in-practice-1/)。本文將會繼續研究 Linux capabilities 更高階的應用案例，並結合 Docker 和 Kubernetes 來加深理解。 ## 1. 快速回顧 如果你看過該系列教程的[第一篇](https://fuckcloudnative.io/posts/linux-capabilities-why-they-exist-and-how-they-work/)，那你應該大致瞭解下面的計算公式： > 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` 將會得到如下結果： ```bash $ 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`。 ```bash $ grep Cap /proc/$$/status CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000003fffffffff CapAmb: 0000000000000000 ``` 輸出中的 `16` 進位制掩碼錶示對應集合中的 capabilities，可以使用 `capsh` 對其進行解碼： ```bash $ 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 使用者，得到的結果和普通使用者是不一樣的： ```bash $ grep Cap /proc/$$/status CapInh: 0000000000000000 CapPrm: 0000003fffffffff CapEff: 0000003fffffffff CapBnd: 0000003fffffffff CapAmb: 0000000000000000 ``` 所有的 capabilities 都包含在了 `Permitted`、`Effective` 和 `Bounding` 集合中，所以 root 使用者可以執行任何核心呼叫。 ## 2. 為可執行檔案分配 capabilities 我在[上一篇文章](https://fuckcloudnative.io/posts/linux-capabilities-why-they-exist-and-how-they-work/#span-idinline-toc3span-執行-execve-後-capabilities-的變化)中提到過，通過適當的配置，程序可以獲取可執行檔案的 `Bounding` 集合中的 capabilities。下面通過一個例子來加深理解。 以 `ping` 這個命令為例，它的二進位制檔案被設定了 `SUID`，所以可以以 root 身份執行： ```bash $ which ping /bin/ping $ ls -l /bin/ping -rwsr-xr-x 1 root root 64424 Mar 9 2017 /bin/ping ``` 更安全的機制是使用 capabilities，不過 `Ubuntu` 上面的 ping 沒有這麼做。沒關係，我們可以通過 ping 的原始碼來自己編譯，首先克隆原始碼： ```bash $ git clone https://github.com/iputils/iputils ``` 安裝編譯所需的依賴： ```bash $ sudo apt install -y ninja-build meson libcap-dev gettext ``` 開始編譯： ```bash $ cd iputils $ ./configure $ make ``` 新編譯的 ping 檔案並沒有設定 SUID： ```bash $ ls -l builddir/ping/ping -rwxrwxr-x 1 fox fox 168K Oct 19 15:26 builddir/ping/ping ``` 也沒有任何的 capabilities： ```bash $ getcap builddir/ping/ping ``` 所以無法正常工作： ```bash $ builddir/ping/ping www.baidu.com builddir/ping/ping: socket: Operation not permitted ``` 我們可以手動設定 capabilities： ```bash $ 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： ```bash $ 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` 是看不到的。其中這就是我在[第一篇文章](https://fuckcloudnative.io/posts/linux-capabilities-why-they-exist-and-how-they-work/#span-idinline-toc4span-簡單示例)提到的 ping 檔案具有 **capabilities 感知能力**。可以通過 `stace` 跟蹤系統呼叫來驗證： ```bash $ 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<

P'(ambient) = (file is privileged) ? 0 : P(ambient) > P'(effective) = F(effective) ? P'(permitted) : P'(ambient) 如果理解了，再往下動手實踐。我用 C 寫了一個簡單的程式 [set_ambient](https://github.com/ContainerSolutions/capabilities-blog/blob/master/set_ambient.c)，核心功能是使用 [cap-ng library](https://people.redhat.com/sgrubb/libcap-ng/index.html) 將 CAP_NET_BIND_SERVICE capabilities 新增到新程序的 `Ambient` 集合中。編譯完成後，需要給二進位制檔案新增該 capabilities，如果它自己沒有這個 capabilities，是無法將其新增到新程序中的： ```bash $ sudo setcap cap_net_bind_service+p set_ambient $ getcap ./set_ambient ./set_ambient = cap_net_bind_service+p ``` 通過 `set_ambient` 來啟動一個 bash 環境： ```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 服務](https://github.com/ContainerSolutions/capabilities-blog/blob/master/server.go)，並繫結到 80 埠，既不給它相應的 capabilities，也不以 root 身份執行： ```bash $ $ ./server 2019/09/09 13:42:06 listen tcp :80: bind: permission denied ``` 執行失敗，因為它沒有繫結到小於 1024 的埠的許可權。下面利用 `set_ambient` 建立一個 “webserver” 環境再執行試試： ```bash $ ./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，可以使用上面的方法來實現這個目的： ```bash $ 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 倉庫](https://github.com/ContainerSolutions/capabilities-blog)中。如果不加任何引數直接執行容器，結果如下： ```bash $ 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](https://github.com/kubernetes/kubernetes/issues/56374)。 如果使用指定的使用者執行容器，會得到全新的結果： ```bash $ 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 已經包含了一個具備此條件的可執行檔案，可以用來測試一下： ```bash $ 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` 程式。 ```bash $ 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，例如： ```bash $ 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 身份或普通使用者身份執行容器，例如： ```bash $ 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` 程式。例如： ```bash $ 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](https://fuckcloudnative.io/posts/linux-capabilities-in-practice-1/#no_new_privs)。 對於容器玩家，我的最終建議是：**移除所有非必要的 capabilities，並以非 root 身份執行。** 使用 `Ambient` 集合與可執行檔案的 capabilities 進行邏輯運算可以得到一個相對安全的容器環境，大部分情況下應該不需要使用 `set_ambient` 這樣的輔助程式。 Linux capabilities 與容器領域有著緊密的聯絡，我很期待看到 `Ambient` capabilities 被廣泛應用到容器領域，以支援以非 root 身份執行的半特權容器。 ---- Kubernetes 1.18.2 1.17.5 1.16.9 1.15.12離線安裝包釋出地址http://store.lameleg.com ，歡迎體驗。 使用了最新的sealos v3.3.6版本。 作了主機名解析配置優化，lvscare 掛載/lib/module解決開機啟動ipvs載入問題， 修復lvscare社群netlink與3.10核心不相容問題,sealos生成百年證書等特性。更多特性 https://github.com/fanux/sealos 。歡迎掃描下方的二維碼加入釘釘群 ，釘釘群已經整合sealos的機器人實時可以看到sealos的動態。