揭开 SE Linux 的秘密：第 1 部分-CSDN博客

本文链接：https://blog.csdn.net/johnathan/article/details/86008

揭开 SE Linux 的秘密：第 1 部分
SE Linux 代码的首次深入探讨

Larry Loeb (larryloeb@prodigy.net)
作者，Secure Electronic Transactions
2001 年 3 月

最近，美国国家安全局不同寻常地向开放源码社区发布了一个安全性增强型版本的 Linux --包括代码和所有部分。这篇 dW 专有的文章首次对这一意想不到的开发进行了探讨 -- 它意味着什么，将有什么样的影响 -- 并深入研究了 SE Linux 的体系结构。

引起轰动
它的出现完全是始料不及的，一点先兆也没有。“新的”国家安全局向开放源码社区公布了安全性增强型版本的 Linux 2.2 内核（称为 SE Linux）。不仅如此，他们还提供了有关模拟 SE Linux 是否真正安全所使用的研究方法的背景简报文章。

如果您近来没有对密码术领域进行研究，那么我可以向您保证，NSA 的这一行动就好比是教皇从罗马的阳台上走下来，和人们在一起干活，分享大块的面包和一些鱼，然后邀请每个人到他的住处去看足球比赛，再喝点啤酒。有些事是无论谁都永远无法想像的，但 NSA 确实交出了源代码及其背后安全性机制的细节。一直到目前为止，NSA 在过去 50 年中就是典型冷战偏执狂需要的具体体现（“如果您知道我们所知道的，您就会同意我们的说法”）。看它象一些长发斯坦福学生那样将代码贡献出来足以让人控制不住地打个冷战。

但他们似乎就想达到这样的效果。分发 .tgz 文件不包含神秘的“特洛伊木马”，不会读取您硬盘上的数据后将所有数据发送回米德要塞。没有任何办法可以藏起代码中所有人都可以对其发表评论或进行分析的活门。NSA 确实需要一个安全的 OS 来实施他们很擅长的巫毒，他们似乎真的有计划在内部使用 SE Linux。据报道，通过合并一个称为 NetTop 的商业产品，NSA 将使用运行 SE Linux 的一台计算机来替代一些在物理上分隔的计算机（这意味着操作安全性的“空隙”方法 -- 将物理上分隔的系统区分成不同的安全性级别）（请参阅参考资料）。

他们在想什么？
SE Linux 作者对于他们需要做些什么来改进安全性有很现实的领会。当在 SE Linux 邮件组中问及 SE Linux 小组是否在引导当前 Linux 磁盘加密的安全性审计时，Peter Loscocco（SE Linux 的作者之一和 NSA 目前的 SE Linux 项目领导人）回答说：

“不。该项目的目标非常明确。我们是要将灵活而必要的访问控制体系结构合并到 Linux 中。我们不尝试找出／改正错误或分析安全性组件（例如 crypto FS）来改进他们的设计。这并不是说这些活动没有用处或者需要从整体上改进 Linux 的安全性。它只不过不是我们所要做的。Linux 的安全性将通过增加如 SE Linux 中的安全性特性来得到改进。”

“从该项目的角度来说，我们对于密码术的兴趣实际上是研究可以与 MAC 策略集成的选择密码术机制的方法，应用相同的策略灵活性原则并将实施与策略决定分隔开。一句话说，我们希望看到灵活的密码使用策略，如同系统安全性策略一样实施。我们希望能够做出 crypto 机制选择决定，甚至包括根据安全性上下文来决定是否需要 crypto。”

“我认为这些想法应该同时在文件系统和网络实现中来研究。当然，在定义完善的 crypto API 后定义的密码术使这一想法更加可行。为文件密码术执行这一操作仍然是我们希望在以后进行的尝试，但目前没有计划[这样做]。不过，我们确实有计划在联网的这一领域中依赖于我们以前的工作。我们会将 IKE 和 IPSEC 与现有的 MAC 策略进行集成。因为这一工作实际上已经开始了，我们将有更多可以谈论的。”

“此外，我们项目的目标不是改进或保证现有的密码术。我们所感兴趣的是提供必要的系统支持来使用系统在某种程度上依赖于必要的访问控制策略而支持的任何密码术。密码术的细节应该与该支持无关，或者只要有可能就与该支持无关。”

SE Linux 安全性体系结构：概述
那么，SE Linux 是如何工作的呢？首先，别指望一开始就是分布式的。作者已经声明 SE Linux 是包括在标准中的一个成果，而不要认为它的成果是成为那个标准。作者希望在 Linux 内核中具有必要的访问控制，这就是支持 SE Linux 的思想。许多实现问题在它可以用在现实世界中之前都需要加以解决（或代码编写）。幸运的是，Linux 历史上就有一些供应商为了费用做这些事，我现在希望某一天能看到 RedHat 的 SE Linux。

整个安全性体系结构称为 Flask，在犹他大学和 Secure Computing Corp. 的协助下由 NSA 设计。在 Flask 体系结构中，安全性策略的逻辑和通用接口一起封装在与操作系统独立的组件中，通用接口是用于获得安全性策略决策的。这个单独的组件称为安全性服务器，即使它只是个内核子系统而已。该服务器的 SE Linux 实现定义了一种混合的安全性策略，由类型实施 (TE)、基于角色的访问控制 (RBAC) 和可选的多级别安全性 (MLS) 组成，所以广泛用于军事安全性中。该策略由另一个称为 checkpolicy 的程序编译，它由安全性服务器在引导时读取。文件被标为 /ss_policy。这意味着安全性策略在每次系统引导时都会有所不同。策略甚至可以通过使用 security_load_policy 接口在系统操作期间更改（只要将策略配置成允许这样的更改）。

Flask 有两个用于安全性标签的与策略无关的数据类型 -- 安全性上下文和安全性标识。安全性上下文是表示安全性标签的变长字符串。安全性标识 (SID) 是由安全性服务器映射到安全性上下文的一个整数。SID 作为实际上下文的简单句柄服务于系统。它只能由安全性服务器解释。Flask 通过称为对象管理器的构造来执行实际的系统绑定。它们不透明地处理 SID 和安全性上下文，不涉及安全性上下文的属性。任何格式上的更改都不应该需要对对象管理器进行更改。

图 1

来源：The Flask Security Architecture: System Support for Diverse Security Policies，Ray Spencer (Secure Computing Corporation), Stephen Smalley, Peter Loscocco (National Security Agency)、Mike Hibler、David Andersen 和 Jay Lepreau（犹他大学）合著。（请参阅参考资料）。

安全性服务器只为包含用户、角色、类型和可选 MLS 范围合法组合的安全性上下文提供 SID。“合法性”是由安全性策略配置（将在本文的稍后部分介绍）所确定的。

一般来说，对象管理器查询安全性服务器以根据标签对（主体的和客体的）和对象的类获得访问决定。类是标识对象是哪一种类（例如，常规文件、目录、进程、UNIX 域套接字，还是 TCP 套接字）的整数。向量中的许可权通常由对象可以支持的服务和实施的安全性策略来定义。访问向量许可权基于类加以解释，因为不同种类的对象有不同的服务。例如，访问向量中使用的许可权位表示文件的 'unlink' 许可权，它也用于表示套接字的 'connect' 许可权。向量可以高速缓存在访问向量高速缓存 (AVC) 中，也可以和对象一起存储，这样，对象管理器就不必被那些已执行的决策的请求淹没。

对象管理器还必须为将标签分配给它们的对象定义一种机制。在服务流中指定管理器如何使用安全性决定的控制策略还必须由管理器定义和实现。在策略更改的情况下，对象管理器必须定义将调用的处理例程。在任何情况下，对象管理器都必须将对象的安全性上下文作为不透明的字符串处理。通过这种方式，不应该有合并到对象管理器中的特定于策略的逻辑。

图 2

来源：The Flask Security Architecture: System Support for Diverse Security Policies，Ray Spencer (Secure Computing Corporation), Stephen Smalley, Peter Loscocco (National Security Agency)、Mike Hibler、David Andersen 和 Jay Lepreau（犹他大学）合著。（请参阅参考资料）。

在安全性策略中进行运行时更改是有可能的。如果发生这种情况，安全性服务器通过取消不再授权的 SID 并复位 AVC 来更新 SID 映射。

图 3

来源：The Flask Security Architecture: System Support for Diverse Security Policies，Ray Spencer (Secure Computing Corporation), Stephen Smalley, Peter Loscocco (National Security Agency)、Mike Hibler、David Andersen 和 Jay Lepreau（犹他大学）合著。（请参阅参考资料）。

文件是对象类的特殊实例。新文件继承其父目录中那些文件的相同类型。有一个与文件相关的永久整数 SID (PSID)，该整数随后映射成分区表中的安全性标签。这个表（将对象／PSID 和 PSID／安全性标签映射区分开）在安装文件系统时加载到内存中。当新的安全性标签应用到文件时，它在内存（和磁盘上）进行更新。如果它是远程安装的，即使已经由文件系统重新命名了，它也可以让基于 inode 的 PSID/对象映射表跟踪文件。

图 4

来源：The Flask Security Architecture: System Support for Diverse Security Policies，Ray Spencer (Secure Computing Corporation), Stephen Smalley, Peter Loscocco (National Security Agency)、Mike Hibler、David Andersen 和 Jay Lepreau（犹他大学）合著。（请参阅参考资料）。

Flask 为文件描述创建标签并控制它。创建进程的 SID 出现在打开文件的标签中，它与文件本身的标签不同。即使进程具有访问文件的许可权，它所继承的打开文件描述也可能是非代表性的文件本身当前状态。这样一个进程必须使用文件标签（及其相关许可权）来访问文件。Flask 还控制受文件或目录服务影响的每个对象。除了检查对文件父目录的访问权以外，对于各种操作，都有与个别文件本身相关的许可权。

在 Flask 中，套接字用作通信代理，并因可记帐性而具有创建过程的缺省名称。安全性策略可以通过许可权来为流型套接字连接区分客户机和服务器（在这里，它们是 connectto 和 acceptfrom）。它还可以将端口号和路径名的使用限制在特定进程中。

消息与发送套接字标签以及区分消息标签相关。缺省情况下，这也是发送套接字标签。SE Linux 当前无法通过网络发送这些消息标签。

安全性策略配置
Flask 模糊了在 TE 安全性方案中传统的类型／域区别。在 Flask 中，域也就是类型，但是与进程相关的类型。相同的类型可以同时与进程和对象相关。每个进程都有与之相关的域，每个对象与一种类型链接，该类型可能是域，也可能不是域。

安全性策略配置定义 Type Enforcement 和类型的域。配置将指定由域以及域交互对类型允许的访问。它还可以指定当执行某个特定类型时在域之间的自动转换。这意味着特定进程可以自动放在它们自己的域中。似乎自动域转换主要用于在系统初始化期间将系统守护程序放入它们自己的域中，以及在执行特定程序时更改特权。它的一个例子就是为可信程序添加许可权，例如更改角色的 newrole。也可以通过除去对潜在危险程序（例如 Netscape）的许可权来限制由泄密的 Web 浏览器所导致的伤害。

角色也在配置中定义。每个进程都有一个与之相关的角色：系统进程以 system_r 角色运行，而用户可以是 user_r 或 sysadim_r。配置还枚举了可以由角色输入的域。让我们假设用户执行一个程序"foobar"。让我们假设用户执行一个程序"foobar"。通过执行它，用户转移到 user_foobar_t 域。该域可能只包含一小部分与该用户初始登录相关的 user_t 域中的许可权。

安全性策略配置目标包括控制对数据的原始访问、保护内核和系统软件的完整性、防止有特权的进程执行危险的代码，以及限制由有特权的进程缺陷所导致的伤害。另一个重要目标是保护管理员角色（和域）不在没有认证的情况下进入。这是通过要求 "login" 程序（具有相关授权进程）处理到管理员角色和域的转换来在 SE Linux 中实现的 -- 只能希望实际做到。

实际配置进程是通过宏来处理的。m4 宏处理器扩展了这些宏。

这个代码清单就显示了 SE Linux 是如何使用宏语言来定义 rlogin_t 域规则的。

就是这样。那些没有明确允许的就是被禁止的。没有灰色区域。非常极端。如果您仔细想想，这就是您对安全性系统所期盼的。

不过，要记住在 policy/domains/every.te 中有一系列规则，除特定于域的规则外还适用于每个域。也有可能不使用这样的“全局”规则以提供最少特权，以及仅为每个单独域添加那些必需的角色。

在本系列的第 2 部分，我们将看一些更原始的 SE Linux 代码。我们将讨论如何计算 security_av，以及某些其它 SE Linux 安全性特性是如何调用的。如果到这一步，第 2 部分将是决定性的。

参考资料