使用capability加强container的安全

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系统调用成功，系统的内核就会建立一个文件描述符。然后，如果收到读或者写的请求，内核就使用这个文件描述符作为一个数据结构的索引，检索相关的操作是否允许。这是一种检查权限的有效方式，在执行open系统调用是，内核一次性建立必要的数据结构，然后的读写等操作检查只需要在数据结构中梭梭即可。对能力的操作包括：复制能力、进程间的迁移能力、修改一个能力以及撤消一个能力等。修改一个能力类似与把一个可以读写的文件描述符改为只读。目前，各种系统对能力的应用程度并不相同。 
　　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 allowe
　　如果我们需要删除某个能力，直接把能力名作为参数就可以，例如我们要删除加载/卸载内核模块的能力： 
[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 xntp
　　目前，由于文件系统的制约，还无法实现。 
8.结论
　　在本文，我们讨论了Linux的能力，并说明了如何使用相关的工具加强系统的安全性。但是，能力还守制于文件系统的扩展，并不是非常完善。

作者|分布式资源与管理小组

【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区），文章链接，文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：hwclouds.bbs@huawei.com进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。