SELinux（Security-Enhanced Linux）

http://blog.csdn.net/myarrow/article/details/9839377

Security-Enhanced Linux（SELinux）的历史

一个小历史将有助于帮助您理解 Security-Enhanced Linux（SELinux）——而且它本身也是段有趣的历史。 美国国家安全局（National Security Agency，NSA）长时间以来就关注大部分操作系统中受限的安全能力。 毕竟，他们的工作之一就是要确保美国国防部使用的计算机在面临没完没了的攻击时保持安全。NSA 发现 大部分操作系统的安全机制，包括 Windows 和大部分 UNIX 和 Linux 系统，只实现了“选择性访问控制 （discretionary access control）”（DAC）机制。DAC 机制只是根据运行程序的用户的身份和文件等对象 的所有者来决定程序可以做什么。NSA 认为这是一个严重的问题，因为 DAC 本身对脆弱的或恶意的程序来说 是一个不合格的防护者。取而代之的，NSA 长期以来一直希望操作系统同样能支持“强制访问控制（mandatory access control）”（MAC）机制。

MAC 机制使得系统管理员可以定义整个系统的安全策略，这个策略可以基于其他因素，像是用户的 角色、程序的可信性及预期使用、程序将要使用的数据的类型等等，来限制程序可以做哪些事情。 一个小例子，有了 MAC 后用户不能轻易地将“保密的（Secret）”数据转化为“不保密的（Unclassified）”的数据。 不过，MAC 实际上可以做的比那要多得多。

NSA 已经与操作系统提供商合作了多年，但是很多占有最大市场的提供商对于将 MAC 集成进来 没有兴趣。即使是那些集成了 MAC 的提供商也通常是将其做为“单独的产品”，而不是常规产品。 一部分原因只是因为旧式的 MAC 不够灵活。

于是 NSA 的研究力量尽力去使 MAC 更灵活并且并容易被包含在操作系统中。他们使用 Mach 操作系统开发了 他们的思想的原型，后来发起的工作扩展了“Fluke”研究操作系统。不过，难以让人们信服这些思想可以适用于 “真实的”操作系统 ，因为所有这些工作都基于微型的“玩具级的”研究项目。极少可以在原型之外进行尝试以查看 这些思想在真实的应用程序中工作得如何。NSA 不能说服具有所有权的提供商来添加这些思想，而且 NSA 也没有 权利去修改私有的操作系统。这不是个新问题；多年前 DARPA 试图强制它的操作系统研究人员使用私有的操作系统 Windows，但遇到了很多问题（参见下面的 参考资料）。

于是，NSA 偶然发现了一个回想起来似乎显而易见的想法：使用一个 不是 玩具的开放源代码操作系统，并 实现他们的安全思想，以显示（1）它可以工作，（2）它具体如何工作（通过为所有人提供源代码）。他们选择了主导 市场的开放源代码内核（Linux）并在其中实现了他们的思想，即“security-enhanced Linux”（SELinux）。毫无意外， 使用真正的系统（Linux）让 NSA 研究人员可以处理他们在玩具中无法处理的问题。例如，在大部分基于 Linux 的系统中， 几乎所有都是动态链接的，所以他们不得不做一些关于程序如何执行的深入分析（查阅他们关于“entrypoint”和 “execute”权限的文档以获得更多资料）。这是一个更为成功的方法；正在使用 SELinux 的人比使用先前的原型的人多得多。

SELinux 如何工作

那么，SELinux 如何工作呢？SELinux 的方法实际上非常普通。每一个重要的内核对象，比如每个文件系统对象和每个进程， 都有一个关联到它们的“安全上下文（security context）”。安全上下文可以基于军事安全层级（如不保密的、保密的和 高度保密的）、基于用户角色、基于应用程序（这样，一个 Web 服务器可以拥有它自己的安全上下文），或者基于很多其他内容。 当它执行另一个程序时，进程的安全上下文可以改变。甚至，取决于调用它的程序，一个给定的程序可以在不同的安全上下文中运行，即使是同一个用户启动了所有程序。

然后系统管理员就可以创建一个指定哪些特权授与哪个安全上下文的“安全策略（security policy）”。当发生系统调用时，SELinux 去 检查是否所有需要的特权都已经授与了——如果没有，它就拒绝那个请求。

例如，要创建一个文件，当前进程的安全上下文必须对父目录的安全上下文的“搜索（search）”和“add_name”特权，而且 它需要有对于（要创建的）文件的安全上下文的“创建（create）”特权。同样，那个文件的安全上下文必须有特权与文件 系统“关联（associated）”（所以，举例来说，“高度保密”的文件不能写到一个“不保密”的磁盘）。还有用于套接字、 网络接口、主机和端口的网络访问控制。如果安全策略为那些全部授与了权限，那么请求就会被 SELinux 所允许。否则， 就会被禁止。如果按部就班地去做所有这些检查将会较慢，不过有很多优化方案（基于多年的研究）使其变得很迅速。

这一检查完全独立于类 UNIX 系统中的通常的权限位；在 SELinux 系统中，您必须 既 有标准的类 UNIX 权限， 又 有 SELinux 权限才能去做一些事情。不过，SELinux 检查可以做很多对传统的类 UNIX 权限来说难以完成的 事情。使用 SELinux，您可以方便地创建一个只能运行特定程序并且只能在特定的上下文中写文件的 Web 服务器。更 有趣的是，如果一个攻击者攻入了 Web 服务器并成为 root，攻击者不会获得整个系统的控制权——如果有一个好的安全策略的话。

那就有了困难：为了使 SELinux 有效，您需要有一个好的安全策略来由 SELinux 执行。大部分用户将需要一个他们容易修改 的实用的初始策略。几年前我开始体验 SELinux；那时，初始策略还不成熟，有很多问题。例如，在那些以前的日子中我发现 早期的样例策略不允许系统更新硬件时钟（最后我提交了一个补丁以解决这一问题）。设计好的初始安全策略类似对产品分类， NSA 希望由商业界来做，而且看起来是要这样做。Red Hat、一些 Debian 开发者、Gentoo 以及其他人正在使用基本的 SELinux 框架，并且正在创建初始安全策略，这样用户可以马上开始使用它。的确，Red Hat 计划为所有用户在他们的 Fedora 内核中 都启用 SELinux，并提供简单的工具来使得非专业用户可以通过选择一些常见选项来修改他们的安全策略。Gentoo 有一个可引导 的 SELinux LiveCD。这些团体将使得最小化程序特权变得更简单，而不需要大量代码。

在这里我们又回到了原处。SELinux 只有当程序执行时才允许发生安全传输，它控制进程的权限（不是一个进程的一部分）。 所以，为了充分发挥 SELinux 的潜力，您需要将您的应用程序分解为独立的进程和程序，只有一些小的有特权的组件—— 这恰恰如同如何在没有 SELinux 的情况开发安全的程序。像 SELinux 这样的工具让您可以更好地控制授与的权限，并这样创建一个 更强有力的防御，但是，您仍需要将您的程序拆分为更小的组件，以使得那些控制能发挥最大的效用。