涉及开发实现 Security-Enhanced Linux®（即 SELinux，是一种实现强制访问控制的系统）的项目最初是由美国安全局 (NSA) 发起。Secure Computing Corporation (SCC) 和 MITRE 直接参与了开发，许多实验室也加入其中。该系统最初是作为一款通用访问软件，发布于 2000 年 12 月（源代码采用 GPL 许可发布）。NSA 发布了一个特殊简化版作为纪念版本（参见 参考资料）。此后的十年中，SELinux 的基本架构作参与了多个半研究/半军事项目，进行了开发、分析和测试（参见 项目盛宴：DTMach、DTOS、Fluke、Flusk 和 Flask）。
项目盛宴：DTMach、DTOS、Fluke、Flusk 和 Flask
在 1992–1993 年，来自 NSA 和 SCC 的研究人员致力于研究 Distributed Trusted Mach (DTMach) 操作系统，该系统结合了来自 TMach 和 LOCK 项目的研究成果。DTMach 捆绑了一种通用的类型强制、一个灵活的访问控制机制和一个 Mach 微内核。DTMach 项目随后作为 Distributed Trusted Operating System (DTOS) 项目的一部分开发。DTOS 项目结束后，NSA、SCC 和犹他大学共同将 DTOS 安全系统集成到 Fluke 研究操作系统。新的项目称为 Flux。与此同时，安全系统的初始架构得到了增强，从而能够更好地支持动态安全策略。新增强的架构称为 Flask。NSA 的下一步是对 Linux OS 使用该安全系统架构，并以 Security-Enhanced Linux 的名称向公众发布（参见 参考资料）。
新的强制访问控制系统所基于的流程是查看操作系统对象和主体的安全标签，并包含许多最新的访问控制技术。其中一种技术就是类型强制 (type enforcement)。该系统最初放在一个专门设计的可信任 “A1” 级系统（称为 LOCK）中进行了测试（参见LOCK），然后在研究操作系统 Flask 的安全子系统中进行了进一步开发。在基于 SELinux 角色的访问控制以及 Multi-Level 或 Multi-Category 具体实现中支持使用该类型强制。
类型强制是一种访问控制技术，它允许根据当前的安全上下文或域向主体（用户、软件流程和工作流）授权以访问对象（文件、I/O 端口和其他）。
在 SELinux 中，安全上下文存储在扩展的文件系统属性中，并通过 Linux Security Module (LSM) 进行管理。类型强制用于实现强制访问控制，对基于角色的访问控制 (RBAC) 进行了补充，是实现 Multi-Level Security (MLS) 和 Multi-Category Security (MCS) 的第一步。
SCC 的 LOCK (Logical Co-processing Kernel) 项目其目标是开发一个可信任的计算机系统，提供多级别安全性。这意味着根据可信任的计算系统评估标准（Trusted Computing System Evaluation Criteria，也称为 “Orange Book”），系统必须满足 “A1” 级别的需求。
项目成功结束后，将在军事指挥中心建立数十个系统。类型强制是 LOCK 技术的主要架构特性，确保有效地实现访问控制机制。
目前，与安全和访问控制（包括类型增强）有关的基础 LOCK 技术主要在以下系统中开发：
- Sidewinder Internet Firewall 产品线
- SELinux
有关 LOCK 项目的更详细信息，请参阅 参考资料。
在发布 SELinux 时，它是作为 2.2 和 2.4 内核更新发布的。然而，当出现了是否把 SELinux 包含到正式版内核中这一问题时，Linus Torvalds 要求修改项目，从而将 Linux 安全子系统实现为一个模块，为后续的维护或增强提供便利。因此，开发人员创建了 Linux Security Modules 子系统，通过一个接口为安全子系统提供内核功能。该解决方案允许 Linux 用户和开发人员从大量强制访问控制系统中进行选择：AppArmor、TOMOYO Linux、SMACK 和 SELinux。
Linux Security Modules (LSM) 是一种 Linux 内核子系统，旨在将内核以模块形式集成到各种安全模块中。在 2001 年的 Linux Kernel 峰会上，NSA 代表建议在 Linux 内核版本 2.5 中包含强制控制访问系统 Security-Enhanced Linux。然而，Linus Torvalds 拒绝了这一提议，因为 SELinux 并不是惟一一个用于增强 Linux 安全性的安全系统。除此之外，并不是所有的开发人员都认为 SELinux 是最佳解决方案。SELinux 并没有直接包含在内核中，相反，创建了 Linux Security Modules 系统，允许安全子系统作为模块使用，这意味着可以比较方便地连接新的模块。
LSM 子系统的开发工作持续了大约三年时间，并从版本 2.6 开始，就被包含到 Linux 内核中。目前具备正式官方支持的安全模块包括 SELinux、Apparmor、Smack 和 TOMOYO Linux。
关于 LSM 架构的详细描述请参见文章 “Linux Security Modules: General Security Support for the Linux Kernel”（参见 参考资源），该文章在 2002 年的 USENIX Security 会议上发表。
SELinux 根据标签控制与强制访问控制系统建立关联。 这意味着由 SELinux 保护的操作系统中的每个对象或主体都需要一个称为 security context 的特殊标签。这些标签最初存储为数字，放在 ext2 文件系统节点中的未使用字段中。每个数字标签在 SELinux 中被映射到一个可读的基于文本的安全上下文标签中。这种方法不具备可扩展性，并且基于特定的 ext2 文件系统的特性，这被认为是整个解决方案的一个明显的瑕疵。
在开发的下一个阶段，SELinux 被实现为一个可以载入到 Linux 内核版本 2.4 的模块。该模块可以处理存储在单独文件中的标签，这意味着 SELinux 的实现对所使用的文件系统没有任何限制。然而，去掉某个架构缺陷可能会引起另一个缺陷。对包含安全上下文标签的文件进行频繁访问将导致生产力显著下降。
Linux 内核 2.6 版本的发布彻底解决了这个问题，它充分支持 Linux Security Modules 和 ext3 文件系统的扩展属性。为了能够对系统的对象和主体存储安全上下文标签，SELinux 转变为使用扩展的属性。不幸的是，这种创新对文件系统的使用提出了限制。SELinux 只能在支持扩展属性的文件系统中使用。然而，这个问题随时间而得到解决，目前几乎所有通用的文件系统都充分支持扩展属性，这意味着它们都能够使用 SELinux。
一段时间后，SELinux 被集成到 Linux 内核并开始进行发布，第一次作为内核 2.6.0-test3（2003 年 8 月 8 日发布）的子系统进行测试。作为发布的一部分，针对内核 2.2 和 2.4 发布了一个内核路径，用于强制访问控制系统，同时在内核 2.4 中引入了对 Linux Security Modules 的支持，从而导致了面向 LSM 的 SELinux 版本的开发。
SELinux 很快成为受保护 Linux 系统的事实标准，以及 Red Hat Enterprise Linux 最流行的企业发布版之一（从 Red Hat Enterprise Linux 4 开始）。此后，SELinux 开始在广泛部署的 Debian 和 Fedora 上得到应用，并获得 Ubuntu 发行版的支持，后者非常受用户欢迎（自 LTS 版本 8.04 Hardy Heron 开始）。很久之后，Novell（当时正在开发 AppArmor 并计划将其包含在 Linux 内核中）开始在其 OpenSUSE 和 SUSE Linux Enterprise 发行版中支持 SELinux。
最终，Security-Enhanced Linux 获得了所有流行版本的开发人员的支持。在当前的 Linux 内核版本 2.6 中，SELinux 使用 Linux Security Modules 执行操作。此外，许多 SELinux 元素被合并到实际内核中。
强制访问控制系统使用的冗长路径一直由美国国家安全局监管。将 SELinux 集成到 Linux 内核的基本工作也获得了 Red Hat 的支持。NSA 网站上给出了对 SELinux 开发贡献最大的开发人员的完整列表（参见 参考资源）。
如前所述，SELinux 系统从研究操作系统 Flask 那里继承了安全子系统架构。Flask 的主要特性是它使用了 “最小特权” 的概念向用户或应用程序授权，并且该权限仅够用于执行所请求的操作。该概念使用类型强制实现（参见 类型强制），这都归功于 SELinux 中的强制访问能够作为域类型模型的一部分操作。在该模型中，每个流程主体在一个特定的安全上下文（域）中启动（即它有一个特定的访问级别），而所有操作系统的资源对象（文件、目录、套接字和其他）都有一个特定的类型（保密级别）与之相关联。
由于采用了类型增强，SELinux 的访问控制选项极大地扩展了 UNIX® 类型系统中使用的基本自主 (discretionary) 访问控制模型中的选项。例如，SELinux 可用于严格限制网络服务器能够访问的网络端口号。它还允许创建单独的文件并将数据保存到文件中，但是无法删除这些文件，等等。这种操作系统对象分级有助于对系统和用户流程进行限制，这是通过使用明确分配给特定资源的访问权限实现的。如果 SELinux 控制的任何一个服务受到破坏，那么入侵者将无法越过沙盒（由规则集限制），即使入侵者具有超级用户的权限。
规则列表也是一种安全策略，它定义允许某些域访问某些类型的权限。该安全策略将在系统启动时应用，包含一组文本文件，这些文本文件将在系统启动时载入到 Linux 内核的内存中。
这些规则采用可读的形式，甚至可以被普通用户理解。例如，在如下所示的 http 服务器域规则中，给出了允许读取包含网络配置文件的权限：
allow httpd_t net_conf_t:file { read getattr lock ioctl }; |
SELinux 从 Flask 安全子系统中继承了使用标签定义操作系统对象和主体的安全上下文的结构和规则，以及 “域类型” 模型。要确保实现整体保护，必须对系统中的每个对象和主体定义安全上下文。标签采用以下形式：
<user>:<role>:<type> |
例如，分布式安全上下文的标签采用下面的形式：system_u:object_r:httpd_exec_t。在 SELinux 中，用户 system_u 通常为系统的 daemon 的默认名称。角色 object_r 被分配给普通文件或设备等系统对象。httpd_exec_t 类型应用到正在执行的 httpd file 文件，地址为 /usr/sbin/httpd。user、role 和 type 元素将在下一篇文章中详细讨论。
图 1. 使用 SELinux 的强制访问控制系统概述
SELinux 包含五个基本组成：
- 用于处理文件系统的辅助模块
- 用于集成 Linux Security Modules 事件钩的模块
- 一个用于组织访问控制的基本机制
- Policy Enforcement Server，一个系统安全性策略数据库
- Access Vector Cache (AVC)，一种辅助机制，用于提高生产力
SELinux 的操作可以分为下面几个步骤：
- 操作系统主体（流程）尝试访问特定对象（文件、流程、套接字）上的某个操作，这在 Linux 标准自主安全系统（DAC）中是允许的。这将向对象发起一个请求流。
- 每个要求对对象执行操作的请求都由 Linux Security Modules 截获并传递给 SELinux Abstraction & Hook Logic 子系统，同时还包括主体和对象的安全上下文，SELinux Abstraction & Hook Logic 子系统负责与 LSM 交互。
- 从 SELinux Abstraction and Hook Logic 子系统接收到的信息将转发给基本的 Policy Enforcement Server 模块，后者负责确定是否允许主体访问该对象。
- 要接收是否允许或禁止该操作的决定，策略实施服务器将与 Access Vector Cache 子系统通信，后者通常会缓存要使用的规则。
- 如果 AVC 没有包含相关策略的缓存规则，对所需的安全策略的请求将再次转发给安全策略数据库。
- 在找到安全策略后，该策略将被传递给接收决策的策略服务器。
- 如果所请求的操作符合找到的策略，那么将允许执行该操作。反之，将禁止执行该操作，并且所有决策制定信息将被写入到 SELinux 日志文件中。
除了判断是否允许或禁止某些操作外，Policy Enforcement Server 模块还负责执行一些辅助任务，例如安全标签管理（分配和移除）。
和所有优秀的系统一样，SELinux 实现了操作简便性，确保通过完整的强制访问控制系统实现可靠的操作、低资源需求和良好的生产力。
本文是 “Secure Linux” 系列的其中一篇文章，揭开了对 Security-Enhanced Linux 的讨论，该系统是 GNU/Linux 操作系统中使用的最著名、功能最强大的强制访问控制系统。
SELinux 是一种名副其实的可靠安全保护系统。SELinux 的创建者和开发者（美国国家安全局）对这一点功不可没。然而，除了 NSA 作出的贡献外，SELinux 还基于 IT 系统安全领域中多年的科学成果。这些成果具有深厚的理论知识，并且已在许多专门化的军事系统中证明它们具有非常高的使用效率。
然而，在企业网络或家用 PC 中使用 SELinux 并不简单。SELinux 与基于标签的强制访问控制系统有关，这意味着每个操作系统对象和主体都必须分配一个标签（一个安全性上下文）。最终，对于整个系统，一个良好的 SELinux 安全策略平均包含超过 100,000 条规则！因此，按照目前的形式创建、优化和维护 SELinux 策略将耗费极大的精力和大量时间。为现有或计划中的计算机系统从头创建这样一条安全策略只在很少的情况下被证明是有必要的，例如，所存储和处理的数据要求服务器提供极高的可靠性和保护。该系统的批评者认为从 IT 安全角度来讲，SELinux 过于复杂，以至于无法理解。例如，如果某个入侵者能够绕过系统防卫，那么借口可能是管理员没有正确设置 SELinux。
在为任何特定程序设计访问规则时，管理员可能会遇到违反 SELinux 限制的操作。例如，Linux 中的一些应用程序可能会从超级用户权限部分切换到普通用户权限，反之亦然；这就是说，他们试图应用 “最低权限” 的原则，超级用户的权限事实上只有在绝对必要时使用。然而，在 SELinux 安全模型中很难描述这一行为。
然而，过程仍在继续，并且开发人员对所有这些问题进行了研究和解决。创建了一些完整的规则集，可以应用于典型情况下的服务器和家用 PC 中：系统管理员只需要选择一种现成的安全策略并重启已激活 SELinux 的计算机。
SELinux 本身也在不断改进，包括通过创建和开发安全策略，以及与开发人员交互、修改现有程序。
“安全 Linux” 系列的其他文章将详细介绍如何在实践中使用 SELinux，在这个过程中必须创建和优化规则，控制 SELinux 的行为，并解决一些可能出现的问题。
学习
- 在 Flask: Flux Advanced Security Kernel 中以及通过本文提到的其他项目了解有关 Flask 的更多信息。
- 访问 The Flux Research Group，了解 Flux Research Group 组的其他开发。
- 查看 LOCK - A trusted computing system，获得有关 LOCK 项目的详细信息。
- 阅读 Linux Security Modules: General Security Support for the Linux Kernel，了解 LSM 架构的详细信息。
- 访问 SourceForge.net 上的 Security-Enhanced Linux 项目 官方页面。
- 查看 Security-Enhanced Linux，这是有关 SELinux 的维基百科页面。
- 阅读美国国家安全局网站上的 Security-Enhanced Linux - NSA/CSS。本文介绍了该组织的一项最佳开发，即 Security-Enhanced Linux。
- 细读 NSA 特刊 National Security Agency Shares Security Enhancements to LINUX，提供关于向公众开放 SELinux 源代码以及技术的内容。
- 通过个人和公司列表访问 SELinux 的贡献者，他们是 SELinux 开发和发布的主要贡献者。
- Security-Enhanced_Linux：阅读 RedHat Enterprise Linux 6 中有关安装和使用 SELinux 的指南。
- 通过 Fedora 发行项目的文档进一步了解 Managing Confined Services。使用 SELinux 保护各种服务器服务（MySQL、Apache 和 Squid 等等）。
- developerWorks 中国网站开源技术专区 提供了有关开源工具和使用开源技术的丰富信息。
- developerWorks 中国网站 Web 开发专区 专门提供各种基于 Web 的解决方案的文章。
- 查看 developerWorks 演示中心，那里提供了从初学者的产品安装和配置演示，到面向有经验开发人员的高级功能。
- 在 developerWorks Linux 专区 寻找为 Linux 开发人员（包括 Linux 新手入门）准备的更多参考资料，查阅我们 最受欢迎的文章和教程。
- 在 developerWorks 上查阅所有 Linux 技巧 和 Linux 教程。
- 随时关注 developerWorks 技术活动和网络广播。
获得产品和技术
- 以最适合您的方式 IBM 产品评估试用版软件：下载产品试用版、在线试用产品、在云环境中使用产品，或在 IBM SOA 人员沙箱 中学习如何高效地实现面向服务架构。
讨论
- 加入 developerWorks 中文社区，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。
- 加入 IBM 软件下载与技术交流群组，参与在线交流。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
