利用Capability的特征加强Linux系统安全(2)

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 allowed

　　如果我们需要删除某个能力，直接把能力名作为参数就可以，例如我们要删除加载/卸载内核模块的能力：

[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 xntpd

　　目前，由于文件系统的制约，还无法实现。

　　8.结论

　　在本文，我们讨论了Linux的能力，并说明了如何使用相关的工具加强系统的安全性。但是，能力还守制于文件系统的扩展，并不是非常完善。