摘要:传统UNIX系统的访问控制模型非常简单--普通用户对超级用户。在这种模型中,一个进程或者帐户要么只有很小的权限,要么具有全部的系统权限。显然,这样对系统的安全没有什么好处。从Linux-2.1内核开始,引入了能力(capability)的概念,实现了更细粒度的访问控制。 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系统调用成功,系统的诤司突峤 ⒁桓鑫募 枋龇 H缓螅 绻 盏蕉粱蛘咝吹那肭螅 诤司褪褂谜飧鑫募 枋龇 魑 桓鍪 萁峁沟乃饕 焖飨喙氐牟僮魇欠裨市怼U馐且恢旨觳槿ㄏ薜挠行Х绞剑 谥葱衞pen系统调用是,内核一次性建立必要的数据结构,然后的读写等操作检查只需要在数据结构中梭梭即可。对能力的操作包括:复制能力、进程间的迁移能力、修改一个能力以及撤消一个能力等。修改一个能力类似与把一个可以读写的文件描述符改为只读。目前,各种系统对能力的应用程度并不相同。 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文件中定义。其细节如下: 能力名 数字 描述 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 如果我们需要删除某个能力,直接把能力名作为参数就可以,例如我们要删除加载/卸载内核模块的能力: [root@nixe0n lcap-0.0.6]# ./lcap CAP_SYS_MODULE 6.能力边界集的安全问题 能力边界集为系统和管理员之间提供了一个便利的交互接口,但是它存在一些的脆弱性。Patrick Reynolds在提交到BugTraq的一个邮件里详细分析了这种脆弱性。对能力边界集的最大威胁就是能够被读/写的/dev/mem设备。在内核内存区中,/proc/sys/kernel/cap-bound直接影射到cap_bset变量中。如果/dev/mem可以写,攻击者就能够直接修改内存重置cap_bset变量。从而能够越过能力边界集打开所有的能力。使用以下命令就可以获得cap_bset变量的地址: $ grep cap_bset System.map 从结果可以看出,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权限启动 但是,并不是所有的程序员能够注意到这个问题,如果能够直接使用chmod和chattr命令限制程序的能力将给为方便。例如: [root@localhost /root]# chattr +CAP_BIND xntpd 目前,由于文件系统的制约,还无法实现。 8.结论 在本文,我们讨论了Linux的能力,并说明了如何使用相关的工具加强系统的安全性。但是,能力还守制于文件系统的扩展,并不是非常完善。 |