在我的文章“SUSE 10 中的安全特性”（LJ，2006年4月刊）中，我描述了 Novell AppArmor，它是强制访问控制 (MAC) 的部分实现，现在是 SUSE Linux 的一部分。 自那篇文章撰写以来，Novell 已根据 GPL 发布了 AppArmor 的源代码。 在不久的将来，AppArmor 完全有可能被移植到其他支持 Linux 安全模块的 Linux 发行版。

这是个好消息。 我认为，AppArmor 代表了在使 MAC 技术成为系统管理员可行选项方面迈出的重要一步，这些系统管理员希望获得强大的安全控制，但没有时间和耐心来配置和维护像 SELinux 这样复杂的“可信操作系统”。

本月，我将介绍强制访问控制的概念，描述 Novell AppArmor 和 NSA SELinux 之间的区别，并向您展示如何在您的 SUSE 系统上开始使用 AppArmor。

描述强制访问控制最简单的方法是将其与自主访问控制 (DAC) 进行对比。 大多数通用操作系统都使用 DAC 安全模型，其中给定系统资源（文件、目录等）的所有者可以对该资源设置他们想要的任何访问权限。 一般而言，严格的安全控制是可选的。

相比之下，具有 MAC 的计算机具有全局安全策略，系统中所有用户都必须遵守该策略。 在 MAC 系统上创建文件的用户通常不得对该文件设置弱于系统安全策略所规定的控制措施的访问控制。

大多数 DAC 实现都存在几个主要问题，其中 Windows 和 Linux（SELinux 除外）都明确包括在内。 首先也是最明显的是，与任何涉及人类的情况一样，使任何类型的工作成为可选几乎可以确保这项工作不会经常完成。 即使在 DAC 系统中，一致地使用仔细的安全设置也需要付出努力。

DAC 的另一个问题是，基于 DAC 的操作系统往往具有“赢家通吃”的安全模型，其中在该系统上完成任何重要事情的唯一方法是通过超级用户帐户（Linux/UNIX 中的 root，Windows 中的 Administrator）。 完全破坏使用这种安全模型的系统通常只是劫持该系统上以 root/Administrator 权限运行的某些进程的问题。

但是，在基于 MAC 的系统上，超级用户帐户唯一的作用是维护全局安全策略。 日常系统管理是使用缺乏更改全局安全策略权限的帐户执行的。 因此，通过攻击任何一个进程来破坏整个系统是不可能的。（但是，仍然可能攻击超级用户帐户；例如，通过从其物理控制台将系统引导到单用户模式。）

如果强制访问控制优于 DAC，为什么它们不普及呢？ 不幸的是，尽管多年来 MAC 方案已在各种平台上可用，但它们传统上比基于 DAC 的操作系统更复杂，难以配置和维护。 创建有效的全局安全策略需要详细了解系统上每个应用程序的精确（预期）行为。 此外，给定系统上的安全控制越严格，该系统对用户来说就越不方便使用。

AppArmor 不是 Linux 的第一个强制访问控制方案，也不是最全面的。 可以说，它与 SELinux（美国国家安全局的项目）共享 DNA。（共享的 DNA 是 Linux 安全模块，它为 MAC 提供内核支持。）

SELinux 是内核模块和用户空间配置工具的捆绑包，它实现了三种不同类型的 MAC

在 SELinux 中，所有三种类型的访问控制（TE、RBAC 和 MLS）都应用于整个操作系统。 这要求主要系统应用程序尽可能地了解 SELinux，并且还需要知识渊博的系统管理员进行大量设置（即，仔细研究过 SELinux 的人）。 一方面，SELinux 确实非常全面。 另一方面，配置它是一项相当大的任务。

Novell AppArmor 的目标更为适度：以非常精细但有针对性的方式限制选定应用程序的行为。 AppArmor 专注于应用程序（以角色和数据分类为代价），它基于以下假设构建：大多数系统上最大的攻击媒介是应用程序漏洞。 如果应用程序的行为受到限制，那么任何成功利用该应用程序中某些漏洞的攻击者的行为也将受到限制。

例如，假设您正在运行一个 Web 应用程序，该应用程序以用户 nobody 身份运行，并使用用户输入来更新本地文本文件。 在典型的系统上，如果攻击者破坏了该 Web 应用程序，例如，通过发送意外输入，攻击者可能会成功获得具有 nobody 权限的远程 shell。 但是，如果该 Web 应用程序受到 AppArmor 的保护，那么攻击者所能做的就是更改该单个文本文件。 攻击者不可能生成远程 shell（意外操作）或读取或写入任何其他文件。

全面？ 绝不。 对于未受 AppArmor 保护的应用程序，通常（有限的）用户/组权限仍然适用，不提供有关数据分类的控制，并且通常，系统上只有一部分应用程序具有 AppArmor 配置文件。

在大多数情况下，root 仍然是 root，如果您以草率或冒险的方式使用 root 访问权限，AppArmor 通常不会保护您免受自己的侵害。 但是，如果受 AppArmor 保护的应用程序以 root 身份运行，并且以某种方式被破坏，那么该应用程序的访问权限将被限制，即使具有 root 权限，因为这些权限被 AppArmor 策略（在内核级别强制执行，这要归功于 Linux 安全模块）所取代。

因此，AppArmor 只是强制访问控制的部分实现。 但是，在联网系统中，应用程序安全性可以说是最重要的问题领域，而这正是 AppArmor 关注的重点。 更重要的是，AppArmor 通过易于使用的图形用户界面提供应用程序安全性，该界面与 YaST 完全集成。（现在也在为 SELinux 开发 GUI 工具，但是这些工具的使用有多么容易还有待商榷。）

尽管如此，我并没有建议 AppArmor 可以与 SELinux 互换使用。 例如，如果您在多用户环境（其中用户拥有 shell 或数据库帐户）中运行 Linux，并且涉及高度敏感的数据，那么 SELinux 中全面的访问控制层确实是无可替代的。

尽管 AppArmor 的开源许可证有望导致其移植到其他 Linux 发行版，但就目前而言，AppArmor 仅适用于 SUSE Linux 和 SUSE Linux Enterprise。 因此，本文的其余部分必然是针对 SUSE 的。 我在这里只触及了表面。 有关如何配置和使用 AppArmor 的详细信息，请参阅使用 Yast 的 AppArmor 管理指南，如果您已安装 SUSE 的 subdomain-docs 软件包，其路径为 /usr/share/doc/packages/subdomain-docs/ug_apparmor.pdf。

注意：在被 Novell 收购之前，AppArmor 以前称为 Immunix SubDomain。 许多 AppArmor 的文件名和软件包名称仍然包含单词 subdomain。

AppArmor 有自己的 YaST 模块，名为 Novell AppArmor（图 1）。 正如您所看到的，此模块中的大多数小程序都处理创建和管理 AppArmor 配置文件。 受 AppArmor 保护（限制）的每个应用程序都必须有自己的 AppArmor 配置文件。 配置文件可以手动创建，也可以使用添加配置文件和更新配置文件向导或使用手动添加配置文件小程序创建。

图 1. YaST 的 Novell AppArmor 模块

AppArmor 控制面板用于启用和禁用 AppArmor，以及启用、配置和禁用 AppArmor 安全事件通知。 重要提示：每次手动启用 AppArmor 时，都必须重新启动每个受 AppArmor 保护的应用程序（只需重新启动是最安全的选择）。 应用程序必须在 AppArmor 已经在运行的情况下启动，才能受益于其保护。 显然，如果在启动时启用 AppArmor，则无需担心这一点。

有两种类型的应用程序尤其重要需要保护：以 setuid root 运行的程序（即，以 root 权限运行）和网络应用程序。 AppArmor 预配置了各种 setuid-root 程序和网络应用程序的配置文件，包括 Apache、ping、Firefox、Opera、Evolution、sshd、ld、Postfix、Squid 和 Ethereal。

find / -user root -perm -4000 -print

图 2 显示了 ping 默认配置文件。 正如您所看到的，它由引用其他配置文件内容的 #include 语句、对 POSIX 功能（setuid、kill、sys_boot 等）的访问控制和文件访问控制组成。

图 2. ping 的 AppArmor 配置文件

Web 服务器配置文件实际上可能包含第四个元素 - hat 定义。 图 3 显示了 httpd2 (Apache 2) 的部分配置文件。 配置文件顶部以 [+] 开头的条目是 hat。 hat 只是一个嵌入式配置文件，一个子配置文件，如果您愿意的话。 只有了解 hat 的应用程序的配置文件才能拥有 hat，即使这样，您也必须安装 SUSE 的 libimmunix 和 mod-change-hat 软件包才能使 hat 工作。

图 3. httpd2 的 AppArmor 配置文件

hat 最常见的用途是用于在不实际成为 httpd 守护程序一部分的情况下运行的 Web 应用程序。 图 4 显示了这样一个 hat 的内容，它对应于我的 Web 服务器上的留言簿应用程序。 图 4 中引用的 index.php 脚本主要需要对某些文件的读取访问权限，但它还需要读取和写入留言簿文件本身 (book.gb) 以及 Apache 的访问日志 (access_log)。

图 4. gb Hat 的内容

如果这看起来令人困惑，请不要担心。 很少需要手动创建配置文件（更不用说 hat 了）。 在许多系统上，您根本不需要创建新的配置文件 - 当事情没有按预期工作时，定期运行 AppArmor 更新配置文件向导可能就足够了。 此向导扫描 /var/log/messages 以查找 AppArmor 生成的错误消息，并允许您相应地更新相应的 AppArmor 配置文件（允许或继续不允许触发每个错误的事件）。 在适当/适用的情况下，更新配置文件向导甚至会创建新的 hat，同样假设您已安装 libimmunix 和 mod-change-hat 软件包。

如果您需要从头开始创建新的配置文件，有几种方法可以做到这一点，所有这些方法都在前面提到的使用 YaST 的管理指南以及 AppArmor 高级用户指南 (/usr/share/doc/packages/subdomain-docs/adv-ug-apparmor.pdf) 中详细解释。 然而，这是最简单的方法

基本上就是这样！ /usr/share/doc/packages/subdomain-docs 中的优秀文档不仅解释了上述过程，还解释了如何使用手动添加配置文件小程序，甚至如何使用您选择的文本编辑器从头开始创建配置文件。

在本月专栏结束之前，我想分享一些基于我过去几个月使用 AppArmor 的经验的观察结果。 首先，我必须强调拥有健康的本地日志记录工具的重要性。 正如您所看到的，AppArmor 在很大程度上依赖 /var/log/messages，不仅为您提供良好的审计跟踪，还为自己的向导提供关键的配置情报。 因此，如果您有自定义的系统日志记录器，请确保从 /var/log/messages 到您的子域消息最终位置至少有一个符号链接。

例如，在我的 chrooted syslog-ng 安装中，我的子域消息被写入 /var/syslog-ng/var/log/messages。 在 AppArmor 在此系统上正常工作之前，我必须从 /var/log/messages 到此位置创建一个符号链接。 我还必须编辑 /etc/logrotate.d/syslog，以便在“真实”消息文件过大或过旧时对其进行轮换； 否则，符号链接将被我的 logrotate cron 作业破坏。（显然，我应该在配置 syslog-ng 时更新 logrotate.d/syslog - 当我开始处理这个问题时，/var/syslog-ng/var/log/messages 已经增长到令人尴尬且难以处理的大小。）

此外，我应该指出，就像所有 YaST 模块一样，您不需要运行 X Window 系统即可运行 Novell AppArmor YaST 小程序。 您不应该在连接到互联网的服务器上运行 X，这既是因为它几乎从不需要，又因为 X 具有非常丰富的所谓本地权限提升漏洞的历史。 如果您担心非本地攻击者，那么忽略此类漏洞似乎很诱人，但“本地”通常是误称。 如果攻击者通过例如针对某些网络守护程序的缓冲区溢出攻击获得 shell 访问权限，他们通常可以利用所谓的本地权限提升漏洞将自己提升为 root。

因此，我希望您能原谅我在本文中使用 YaST 的 X 版本的精美屏幕截图 - 我向您保证，这些小程序的内容和功能在纯文本版本中是相同的。

最后，一个小提示 - 在反复运行更新配置文件向导以使我的留言簿 PHP 脚本工作的过程中，AppArmor 出于某种原因忘记了我处理过 /var/log/messages 中的两个特定事件，并反复提示我关于这两个事件。 当我手动删除 /var/log/messages 中的相应行时，问题就消失了，此后我没有遇到过这种特殊的异常情况。 这个问题可能与我奇怪的 syslog-ng 行为有关，而不是与 AppArmor 中的任何问题有关，但我提到它以防您遇到任何类似情况。 AppArmor 的日志消息始终包含字符串 SubDomain。