求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
揭开 SE Linux 的秘密
 

作者:Secure Electronic Transactions,发布于2013-3-26

 

简介: 最近,美国国家安全局不同寻常地向开放源码社区发布了一个安全性增强型版本的 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 部分将是决定性的。

幼虫、沙砾和代码

让我们看一下 SE Linux 分发版中的一些 C 代码,检验安全性增强的实现细节。

让我们从头开始。在分发版目录 include/linux/flask/flask types.h. 中有包含基本 Flask 类型和常量的头文件,现摘录如下:

/*The security context type
* is defined as a variable-length string that can be
* interpreted by any application or user.
*/
typedef char* security_context_t;
/*
* A security identifier (SID) is a fixed-size value
* that is mapped by the security server to a
* particular security context.
*/
typedef __u32 security_id_t;
#define SECSID_NULL 0x00000000 /* unspecified SID */
#define SECSID_WILD 0xFFFFFFFF /* wildcard SID */
/*
* Each object class is identified by a fixed-size value.
.
*/
typedef __u16 security_class_t;
#define SECCLASS_NULL 0x0000 /* no class */
/*
* A persistent security identifier (PSID) is a fixed-size
* value that is assigned by the file system component
* to each security context associated with an object
* in the file system.
*/
typedef __u32 psid_t;
struct psidtab;
/*
* An access vector (AV) is a collection of related permissions
* for a pair of SIDs.
*/
typedef __u32 access_vector_t;

在 kernel/flask/access_vectors ,我们发现这些结构进一步定义了安全性服务器 AV:

class security
{
compute_av
notify_perm
transition_sid
member_sid
sid_to_context
context_to_sid
load_policy
get_sids
register_avc
change_sid
}

与过程相关的对象有一个类似于这样的 AV:

class process
{
execute
fork
transition
sigchld
sigkill
sigstop
signal
ptrace
getsched
setsched
getsession
getpgid
setpgid
getcap
setcap
entrypoint
}

文件对象 AV 是如下结构:

class filesystem
{
mount
remount
unmount
getattr
relabelfrom
relabelto
transition
associate
}
class dir
inherits file
{
add_name
remove_name
reparent
search
rmdir
mounton
mountassociate
}

由于我们进入了 AV 声明,让我们看一下在安全性服务器中进行 AV 计算的代码。记住,如果未击中缓存,那么核心调用 AVC,AVC 调用安全性服务器。

该代码片段 来自己提供最小实现,该实现提供单一 SID 并授予所有权限。这不是很安全。在该段代码中,计算 AV 并产生一个 SID。请注意, ssid 是源 SID, tsid 是目标 SID。由于我进行了一些注释,破坏了原有的良好格式。

这就是现状。它可能是最简单的,而且不是很有用。想要了解添加了 RBAC、TE 和 MLS 的 security_compute_av 有些什么,请查看 kernel/security/services.c 中的代码。

安全性调用

在 SE Linux 中安全性调用是如何工作的?对于那一点,请参阅 代码样本 ,在其发行版中概述了 call_security.c 。包括代码片段和注释。为简短起见,我忽略了在主菜单选项之前出现的正确性检查函数。

该代码样本是类似的代码片段,但它来自于上篇文章(请参阅 参考资料 )提到的 checkpolicy 程序。它显示了其它安全性函数调用的代码,并且完全不需加以说明。checkpolicy 程序包含安全性服务器代码的完整副本,只要执行这个副本,使其允许:(1) 测试/调试用户空间中的代码,(2) 在引导之前检查策略,(3) 把策略编译成其二进制表示。

这个 简单示例 说明了只可以使用这些调用的方式之一。内核访问向量高速缓存调用 kernel/include/linux/flask/avc.h 中的内联函数 avc_has_perm_ref_audit 中的 security_compute_av 。然后,可以通过对象管理器调用 kernel/fs/namei.c 中的 do_link 函数中的 avc_has_perm_ref_audit 。这提供了内核如何调用 AVC 以及 AVC 如何调用安全性服务器(如果有高速缓存失配)的示例。

应用程序如何调用 security_compute_av 的示例在 utils/vixie-cron-3.0.1/database.c 的 process_crontab 函数中。这显示了应用程序如何调用安全性服务器。作者已声明他们计划提供一个应用程序 AVC 库,以便于应用程序也可以缓存安全性策略以及使用与核心风格一致的接口。这将极大地简化编程工作,我们只能希望这会尽快出现。

结束语

安全性增强型 Linux 的前途非常光明,因为它看起来能满足安全 OS 的需要。当然,要达到实际可用的形式还有很多事要做,但是开放源码社团可能会处理这件事。

本文检查了一些代码的内幕,从而显示了它们的工作机制。请记住,这只是从分发的完整代码中抽取的一部分代码片段。应该经常查阅分发站点(请参阅 参考资料),以确保您拿到的是最新版本。

致谢

本文已由那些很有资历的同仁们进行了技术审阅,他们不想让我在这公共的场合提到他们。也好,他们知道他们是谁。谢谢。

参考资料

您可以参阅本文在 developerWorks 全球站点上的 英文原文.

  • 通过合并一个称为 NetTop 的商业产品, 据称 NSA 将替换一些物理上分隔的计算机。
  • 在国家安全局的网站上有 新的基于 2.4.2 的 SE Linux 发行版。
  • SE Linux 的文档包括内核安全性机制的设计和实现,以及安全性策略配置的详细信息。
  • 从 NSA 站点下载 源代码。
  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  • 过合并一个称为 NetTop 的商业产品, 据报道 NSA 将替换一些物理上分隔的计算机。
  • 请参阅 Stephen Smalley 的论文 Flask: Flux Advanced Security Kernel,本文中图 1-4 的来源。
  • 获得有关安全性增强型 Linux 的 Nation Security Agency's perspective。
  • SE Linux 的文档包括内核安全性机制的设计和实现,以及安全性策略配置的详细信息。
 
相关文章

中台产品面面观
如何在互联网产品中建立中台?
什么是产品生命周期管理?
产品设计之前,如何分析业务需求和用户痛点?
 
相关文档

产品经理是怎样炼成的
APP产品规划方法
产品经理培训文档
产品生命周期管理PLM
 
相关课程

产品经理与产品管理
卓越产品经理训练营
产品需求分析与管理
基于用户体验的产品设计
 
分享到
 
 


基于模型的整车电子电气架构设计
嵌入式设备上的 Linux 系统开发
Linux 的并发可管理工作队列
ARM嵌入式系统的问题总结分析
嵌入式系统设计与实例开发
WinCE6.0的EBOOT概要
更多...   


UML +RoseRealtime+嵌入式
C++嵌入式系统开发
嵌入式白盒测试
手机软件测试
嵌入式软件测试
嵌入式操作系统VxWorks


中国航空 嵌入式C高质量编程
使用EA和UML进行嵌入式系统分析设计
基于SysML和EA的嵌入式系统建模
上海汽车 嵌入式软件架构设计
北京 嵌入式C高质量编程
北京 高质高效嵌入式开发
Nagra linux内核与设备驱动原理
更多...