在我的上一篇文章中，我们开始探讨安全增强型 Linux (SELinux) 背后的概念、术语和理论。本月，我们将结束我们的概述，并以描述红帽企业 Linux、Fedora 和 CentOS 中 SELinux 的实现作为结尾。

尽管我很想直接深入探讨新内容，但 SELinux 是我在本专栏中探讨过的最复杂的主题之一，因此有必要进行一些回顾。然而，与其简单地总结上个月的专栏，不如提供一份 SELinux 术语列表

正如我上次提到的，类型强制是 SELinux 中实现的三种安全模型中最重要的。事实上，在红帽企业 Linux (RHEL) 目标策略中（我将在本文后面详细介绍），类型强制是 唯一 使用的 SELinux 安全模型。

与类型强制同等重要的是，它是一个非常面向流程的模型。它最适用于“沙箱化”或隔离守护进程。但是，实际的人类用户呢？他们可能在系统上执行各种任务，因此可能需要遍历多个域？

SELinux 的基于角色的访问控制 (RBAC) 模型关注用户可以在其被授权承担的角色之间转换的方式，并由此扩展到这些角色具有权限的域之间进行转换的方式。实际上，当从一个域内运行的进程派生到另一个域中的进程时，就会发生这种转换。

例如，假设用户 Mick 被授权以 Parent 角色操作，该角色又与 Supper 和 Bedtime 域关联。为了让 Mick 从 Supper 转换到 Bedtime（例如，在 Bedtime 域中启动 shell 会话，并访问授权给该域但不授权给 Supper 域的文件和进程），RBAC 规则必须明确允许 Parent 角色从 Supper 转换到 Bedtime。这是 除了，而不是代替，需要在这两个域的安全上下文中定义 Parent。

SELinux 中的第三个安全模型是多级安全 (MLS)。 MLS 又基于 Bell-LaPadula 数据标签模型。Bell-LaPadula 模型和 MLS 的指导原则都是“不向上读，不向下写”。也就是说，被授权读取一种分类级别数据的进程（用户）不得读取更高（更敏感）分类级别的数据，也不得将给定分类级别的数据写入任何可能被仅被授权查看较低（不太敏感）分类级别数据的进程（用户）访问的地方。

为了使此模型工作，系统上的每个主体都必须与安全许可关联——也就是说，该主体可能访问的数据的最大敏感度。每个文件（对象）也必须标记有分类级别，该分类级别指定主体要访问它必须具有的最低许可。自 Linux 内核 2.6.12 以来，SELinux 中支持的 MLS 范围字段在主体和对象的安全上下文中提供了此信息。

传统的四个数据安全分类级别按敏感度降序排列为：绝密、机密、秘密和非机密。但是，在 MLS 中，可以在安全策略中定义更多这样的分层分类级别。此外，每个分层分类级别都可以与非分层隔间关联，您可以使用这些隔间来实施“需要知道”策略，在该策略中，被授权在给定分类级别的主体可能仅被授予访问与该分类级别内的特定隔间关联的对象。

例如，假设进程 hamburgerd 具有 Secret 的总体主体许可，以及在 Secret 分类级别内的特定许可（ingredients 和 handshakes 隔间）；这样的许可可能表示为 { Secret / ingredients, handshakes }。如果文件 high_sign 具有 { Secret / handshakes } 的对象许可，则允许 hamburgerd 读取它。

请注意，“非分层”是指同一分类级别内的隔间彼此是同级的。如果我定义了两个隔间，apples 和 oranges，在 Classified 分类级别下，则这两个隔间都不被认为比另一个更敏感。但是，与 Secret 或 Top Secret 分类级别关联的任何隔间都将被认为比 { Confidential / apples } 或 { Confidential / oranges } 更敏感。

我提到了 SELinux 的三种安全模型（TE、RBAC 和 MLS）。在红帽企业 Linux 5 中，实际上还有第四种：多类别安全 (MCS)。

您可能会想到，分层分类级别和非分层隔间的组合使 MLS 非常适合大型官僚机构，例如军事组织和情报机构，但对于更通用的目的来说过于复杂。因此，红帽在 RHEL 5 的 SELinux 实现中实施了一种替代的文件分类模型：多类别安全 (MCS)。

MCS 使用 SELinux 的 MLS 范围字段，本质上是通过忽略分类级别字段（将分类级别 0 分配给所有主体和对象）而仅确认隔间字段。通过这种方式，数据标签的功能被简化为更类似于 Linux DAC 组功能。换句话说，MCS 类似于 MLS，但缺乏分层分类级别的额外复杂性。

现在您了解了 SELinux 的底层安全模型，并且至少熟悉了 SELinux 庞大术语体系的一部分，我们可以将注意力转向 SELinux 在主流领域的首次亮相：红帽的目标策略。

对于许多（如果不是大多数）系统管理员来说，不得不理解 SELinux 的各种安全模型和复杂术语，以及管理其可能累积包含数百甚至数千行文本的无数配置文件，使得处理 SELinux 成为一项非常没有吸引力的任务。为了解决这个问题，红帽设计了一种简化的 SELinux 策略，称为 targeted，它强调类型强制，大大简化了 RBAC，并完全省略了 MLS。

事实上，RHEL 的 targeted 策略甚至没有全局实施类型强制；它仅为 12 个特定的主体守护进程定义了域，将所有其他主体和对象放入默认域 unconfined_t 中，该域没有 SELinux 限制（除了这 12 个应用程序各自的域之外）。

RHEL 4 和 5 的 targeted 策略中具有 SELinux 域的守护进程包括

您可能会想，这难道不是相当于“未明确拒绝即允许”的全局策略吗？这难道不是与强制访问控制本应提供的“默认拒绝”立场完全相反吗？

并非如此。诚然，targeted 策略远未达到您将在美国国防部工作中使用的那种受信任的 SELinux 实现的水平。然而，它也并非等同于“默认允许”策略。常规 Linux DAC（文件系统）控制仍然适用。因此，如果您将 targeted 策略视为 在 正常文件系统权限、应用程序级控制、防火墙规则以及您在加固的 Linux 系统上拥有的其他事物 之上 而不是代替它们的额外控制集，您就可以看到，即使是有限的 SELinux 策略仍然可以发挥有意义的作用（此处无双关语）。

事实上，我会更进一步说，红帽的 targeted 策略是 SELinux 迄今为止在主流领域获得采用的最佳希望。红帽是迄今为止最流行的默认启用任何 SELinux 策略的 Linux 发行版；如果该策略被锁定得太紧，以至于任何自定义或大幅重新配置的应用程序都被禁止正常运行，大多数用户将直接禁用 SELinux。（事实上，当 Fedora Core 2 发布时，就发生了这种情况，它发布了一个“默认拒绝”的 SELinux 策略。）

通过启用仅应用于有限的、经过良好测试的应用程序集的 SELinux 策略，红帽最大限度地减少了很大一部分用户将 SELinux 与不便和生产力损失联系起来的可能性。此外，targeted 策略可以通过一个简单的 GUI 系统配置安全级别 (system-config-securitylevel) 进行管理，该 GUI 不需要用户了解任何关于 SELinux 的知识。

图 1. RHEL 4 的系统配置安全级别工具

targeted 策略随 RHEL 4 和 5、Fedora Core 3 及更高版本以及 CentOS 4 和 5 一起发布。

最初为 Fedora Core 2 开发的综合性“默认拒绝”策略 strict 仍然为 RHEL、Fedora 和 CentOS 维护，并且可以安装它来代替 targeted 策略。但是，strict 由于其复杂性，未在 RHEL 中获得官方（商业）支持。在大多数系统上，此策略需要大量手动调整，包括编辑 /etc/selinux 中的文件以及使用标准 SELinux 命令 chcon、checkpolicy、getenforce、newrole、run_init、setenforce 和 setfiles。

请注意，Tresys (www.tresys.com) 维护一套免费的、主要是基于 GUI 的 SELinux 工具，这些工具更易于使用，包括 SePCuT、SeUser、Apol 和 SeAudit。这些工具由 RHEL 的 setools RPM 包提供。另请注意，在非红帽派生的 Linux 发行版上，SELinux 策略通常位于 /etc/security/selinux 中。

要在 RHEL 4 上自定义和使用 strict 策略，请参阅 Russell Coker 的教程“红帽企业 Linux 4 上的 SELinux 简介”（请参阅资源）。您需要安装 selinux-policy-strict 包，该包在 Fedora 的 rawhide 存储库中可用（Fedora Core 5 或 6 中的 selinux-policy-strict 包也可能在 RHEL 4 中工作）。

当然，也可以从头开始开发和启用您自己的 SELinux 策略，但这远远超出了本文的范围。事实上，已经有关于此主题的整本书籍。有关 SELinux 策略创建和自定义的信息，请参阅资源。

至此，我希望您已经开始了 SELinux 的良好开端。祝您安全！