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 身份运行的半特权容器。