自 2001 年年中以来，我一直在从事 NSA 安全增强 Linux [参见本期第 20 页] 的工作，包括为其在 Debian 上的打包和总体开发。在向 Linux 用户介绍该项目时，我发现人们对 SE Linux 的作用存在很多困惑；从阅读文档或参加演示文稿中很难完全理解 SE Linux。此外，许多在安全方面有经验的人都想获得一些实践经验，但没有时间安装 SE Linux 进行实验。我认为，教人们了解 SE Linux 的一个好方法是设置一台公共访问的机器供任何人使用。

在常规配置中演示 SE Linux 并不是特别令人兴奋，因为它为非 root 用户限制的唯一明显操作是 ps ax 和 dmesg。在默认配置中，ps ax显示未授权用户仅在同一用户域中的其他进程，并且dmesg被阻止。这与 OpenWall 施加的限制类似，本身并不是什么新鲜事物。我决定仅使用 SE Linux 进行安全保护，向世界授予 root 访问权限，以便用户可以确切地了解它的功能。

2002 年 6 月 6 日至 9 日，在德国卡尔斯鲁厄的 LinuxTag 大会上，我在 Debian 展位上运行了一台 SE Linux 演示机。这是第一台 SE Linux 实验机。当时，默认策略的限制性不如现在。它允许常规用户（user_t 域）具有 setuid 和 DAC_OVERRIDE 功能。对于常规 SE Linux 配置，这很好。SE Linux 在决定是否授予访问权限时不使用 uid，DAC_OVERRIDE 允许覆盖 UNIX 访问控制，但不允许覆盖任何 SE 控制。授予这些功能的原因是为了允许从 user_t 域运行 setuid 程序，而无需为此类程序使用 SE Linux 域。因此，尽管这些功能对于典型用户来说是令人满意的，但它们不适用于拥有一个应该被禁止访问同一域中其他 uid 的 root 用户的特殊情况。我从 user_t 中删除了这些功能，将 root 帐户限制为 user_r 角色，并准备就绪。

在最近的版本中，默认策略已更改为不向 user_t 授予 setuid 或 DAC_OVERRIDE 功能。因此，我的实验机与真实服务器之间最重要的安全策略差异是，在实验机上，未授权用户被允许读取内核消息日志 (dmesg) 和安全策略源，以帮助理解 SE Linux。

我的 SE Linux 挑战是基于一台有意配置为不如真实服务器安全的机器，通过授予日志文件访问权限、授予对安全策略的读取访问权限以及允许未授权用户 root 访问权限。尽管存在这些因素，但在破解安全性方面几乎没有成功。

在 LinuxTag 的第一天，报告了 /boot 文件的潜在问题。一位用户认为他可以从 LILO 映射文件中确定 LILO 密码。我立即更改了策略以限制对 /boot 的访问，以防止此类问题。当然，如果您可以物理访问一台机器，通常可以通过某种方式破解安全性，但我们希望使其尽可能困难。

在活动期间，我开始支持多用户角色。最初的原因之一是我的同事将实验机用于更严肃的目的。他丢失了所有文件，因为它们是由 root:user_r:user_t 安全上下文创建的，uid root 与测试安全性的用户相同。标准测试 每个人 都以 root 身份运行，即rm -rf /，这删除了他的所有文件。系统本身没有受到损害，因为 /bin、/etc 和其他系统目录中的文件无法被 user_t 取消链接或写入。在我给我的朋友一个具有 user1_t 域的帐户后，user_t 域中的 root 用户无法访问他的文件。

2002 年 6 月 17 日，我在 Cobalt Qube 上设置了一台 SE 实验机，供互联网上的所有人使用。第一台机器断断续续地在线运行到 7 月 11 日。实验机的正常运行时间并不理想，因为它们需要持续监控。如果它被破解并且我没有及时响应，这样一台机器有可能对每个人（包括我、我的 ISP 和使用它的人）构成风险。因此，每当我休假或忙于工作时，我都必须将其下线。

该机器有自己的 iptables 设置，以防止不需要的网络访问离开本地机器。它也放置在防火墙后面，防火墙对数据传输施加了类似的限制。此设置阻止任何用户从内部探测我的防火墙，除非他们首先破解了实验机的安全性。我最初允许大多数出站网络连接（SMTP 除外），但很快将其更改为仅允许出站连接到 Web 代理。SSH 隧道可用于其他网络访问。此外，我拒绝了 X 转发，这样如果用户错误地在其客户端上启用它，他们的机器就不会受到实验机上其他用户的攻击。

当实验机在线运行不到一天时，一位用户报告说可以读取 /etc/shadow。该目录被声明为超出 LinuxTag 演示的范围，但我应该在将机器上线之前修复它。我将 shadow 文件更改为 shadow_t 类型，这需要更改 spasswd 包装程序及其 SE 策略。

添加对 shadow_t 的完全支持很困难，因为在许多情况下，同一个程序会通过重新创建 /etc/passwd 和 /etc/shadow 来更改它们，从而使它们具有 etc_t 的默认上下文。我可以修改这些程序以使用 open_secure(2) 系统调用来指定文件创建时的安全上下文。但是，我决定不这样做，因为它会涉及对安全关键应用程序的大量工作，从而带来错误可能会削弱安全性的风险。相反，我编写了包装器代码来运行这些程序，并在程序退出后将 /etc/passwd 设置回 etc_t。我还使 shadow_t 成为这些程序在 /etc 中创建文件时的默认类型。尽管如此，即使 /etc/shadow 具有 etc_t 类型，它也阻止了未经授权的 root 用户写入它。对于 user_t 域中的 root 用户，它是只读的。

第二天，有人发现 /dev/nvram 没有得到充分保护。每个人都可以写入它，因此任何用户都可以通过扰乱 BIOS 设置使机器无法启动。他们有可能使 Qube BIOS 向内核传递不同的参数，以削弱下次启动时的安全性。Cobalt BIOS 执行的功能类似于 LILO 等引导加载程序在其他机器上执行的功能。我立即更改了策略以修复该故障。重要的是要注意，不同的平台（无论是不同的 CPU 架构还是不同的硬件）可能需要对安全策略进行类似的细微更改，以匹配 /dev 中不同的设备节点。在当前策略下，这几乎不会导致不安全，因为默认情况下会拒绝大多数与设备节点相关的操作。

有些人担心我没有适当地授予授权，并希望得到保证，他们没有做任何非法的事情，因此我更改了 /etc/motd 以声明该机器上线是为了进行安全测试。我解释说，可以接受以任何方式破坏安全性，包括可能导致机器无法使用的方法，只要我被告知使用的方法。我还声明，它不得用于发起对其他机器的攻击，尽管我试图通过防火墙规则使其不可能实现。最后，我要求任何人不要尝试拒绝服务 (DoS) 攻击，因为它们很无聊，而且这不是练习的目的。

从 6 月 20 日起，实验机的运行相当平静。2003 年 2 月，我在 OSDEM 的 Debian 展位上上线了一台实验机，并宣布这是一场夺旗竞赛。这引起了出乎意料的兴趣；有时有多达 30 人观看一个人试图破解安全性。一位用户成功获得了简单的旗帜，在以 root 身份登录后访问了指定非 root 帐户中的文件。他通过设置 EDITOR 环境变量并运行crontab -e来实现。crontab 程序以比常规程序更多的 SE 权限运行编辑器，并允许更大的访问权限。即使该漏洞在典型的服务器配置中不起作用，因为即使您运行 SE Linux，您也不会向不受信任的用户授予 root 访问权限，但我更改了 crontab 程序的策略以防止这样做。即使这样，crontab 攻击仍然仅限于单个用户角色。因此，任何位于不同域中的帐户（例如我用于运行实验机的帐户）都无法触及。

我遇到的一个持续存在的问题是资源使用率。许多用户认为他们通过填满文件系统或耗尽机器的其他资源来取得了一些成就。关于 DoS 攻击的消息似乎没有引起太多注意。

我遇到的另一个有趣的问题是试图说服用户他们实际上是 root 用户。我安装了 GCC，许多用户编译了他们自己的 ps 和其他实用程序的版本，他们认为他们不是真正的 root 用户，这都是修改后的实用程序的伎俩。一位用户甚至编写了汇编代码来调用 getuid() 系统调用，以确定我是否修改了 libc6。尽管该用户确实是 root 用户，但修改 libc6 以假装有人以 root 身份登录但实际上没有登录将是一个有趣的练习。我鼓励读者自己尝试一下。

当然，并非所有用户都如此难以说服。我将密码提供给一位正在寻找机器安装 rootkit 的“黑帽”人士。他试图安装他的 rootkit，但发现所有相关目录（/bin、/sbin 和 /etc）及其包含的文件都是不可写的。他请求帮助安装，但我无法帮助他。

如果您想运行自己的安全测试机器，首先要做的是找到一个合适的场所来放置服务器。这说起来容易做起来难，因为这样一台机器会吸引大量的网络扫描和对网络的渗透尝试。大多数 ISP 的服务条款都禁止此类行为，您可能会面临断开连接的风险。

一旦您安排好托管，您必须设计一种好的方法来在出现问题时快速将机器下线。直接物理访问电源开关对于此目的来说很方便。通过互联网控制电源或硬件重置也是一个不错的选择。如果不行，您应该将测试机器安装在托管交换机的专用交换机端口上，或者作为更便宜的选择，安装在连接到运行 Netfilter 的 Linux 机器的交叉电缆上。这样，您可以快速禁用对整台机器的网络访问。

接下来要做的是选择合适的硬件。例如，iPAQ 并不适合此类机器，因为它有可能通过软件使其无法使用。商品桌面 PC 硬件是一个不错的选择。最坏的情况是更换主板，这既便宜又容易。另一个不错的选择是获得免费硬件，这样如果系统死机，您就不会损失任何钱。现在似乎有些不错的硬件最终会被扔进垃圾箱。

一旦您基本配置好机器，您必须设置合适的数据包过滤器，以防止它被用于攻击其他机器。这些过滤器的严格程度取决于您与 ISP 达成的协议。如果您没有关于此类访问的特定协议（如果您使用的是家庭宽带连接），则过滤器应该非常严格。如果您的合同明确允许运行服务器，您可以允许更大的访问权限，甚至可以托管网页。授予更多的网络访问权限允许执行更有趣的测试。用户经常抱怨测试机器没有授予足够的访问权限来允许进行足够广泛的测试。对于下一台实验机，我计划提供完整的网络访问权限，以便用户可以在机器上接收邮件、托管网页并执行他们请求的大多数其他操作。

防火墙应在测试机器和同一物理网络上的任何其他机器上进行设置。测试机器可以合理地配置 Netfilter 以静默丢弃或拒绝数据包，而不记录它们，尽管您可能希望记录它们以引起兴趣。路由器应配置为记录它丢弃的所有此类数据包，以便您知道是否有人绕过了测试机器上的过滤器或以任何其他方式破解了其安全性。如果您的 ISP 知道您关于安全测试服务器的计划，那么最小的防火墙应该可以工作。这将阻止 SMTP 连接、数据包上欺骗的源 IP 地址以及与 Web 邮件服务（如 Hotmail）的连接，包括阻止访问 Web 代理和配置任何本地 Web 代理以不允许测试机器访问 Web 邮件。

在同一 LAN 上拥有除测试机器和路由器之外的任何机器可能不是一个好主意，因为它可能允许测试机器被用于攻击其他机器。在同一物理网络上拥有多台安全测试机器可能很有趣，因为这将允许它们被用于互相攻击。如果您只有一台测试机器，则通过交叉以太网电缆或运行 PPP 的零调制解调器电缆将其连接到路由器可能是一个不错的选择。

一旦机器连接并且所有防火墙都已安排好，困难的工作就开始了。您必须确定如何限制授予的访问权限并适当地审核它。对于 SE Linux，只需更改 users 文件中的 root 条目即可user root roles { user_r };。另一种选择是从数据库中完全删除 root 条目，因为 user_u 的默认身份仅允许 user_r 角色，并且额外限制了阻止密码更改。要更改非特权帐户的密码，身份必须与用户名匹配。

然后必须重新编译策略数据库并将其加载到内核中以应用更改。在那之后，root 用户对系统没有重要的访问权限，因此请确保您首先授予其他帐户管理权限。

下次我设置测试机器时，我计划找一位有法律经验的人来审查使用条件，以确保他们以清晰且具有法律约束力的语言说明允许的内容。我将把密码放在一个包含使用条件的网页上并定期更改，以便人们在不阅读条件的情况下无法进入。太多人显然没有阅读条件，特别是关于通过 fork 炸弹进行本地 DoS 攻击和使用所有可用磁盘空间。

如果您运行 SE Linux 实验机，请告诉我，以便我可以在我的网页上宣传它。

我一直在使用 irc.debian.org 上的 IRC 频道 #selinux 来支持实验机并回答一般的 SE Linux 问题。我鼓励任何其他正在运行此类安全测试机器（无论是 SE Linux 还是其他系统）的人加入该频道进行讨论。

Sun 公司的 Cobalt 部门通过赠送 RaQ 服务器慷慨地支持了我的工作。LinuxTag 之后的所有 SE Linux 实验机都在 Cobalt 硬件上运行。