强制访问控制技术

SELinux（Security Enhanced Linux）

强制访问控制技术是对自主访问控制（discretionary access control：DAC）信任模型改进。在自主访问控制中，用户不全是可信的，而资源的所有者指定信任哪些用户（从而这些用户可以访问资源）。自主访问控制的缺陷在于其不能区别人类用户和计算机程序，或者说，在自主访问控制的信任模型中，用户对计算机程序充分信任，即认为程序是无缺陷的、无恶意的。这显然与现实不相符合。

类型强制（Type Enforcement：TE）

在SELinux，进程是访问控制的主体，联合某一安全上下文。客体是系统所有安全对象，包括进程（比如A进程向B进程发送信号时，B进程就作为客体）。SELinux的核心是类型强制（Type Enforcement：TE）。系统根据主体的类型（type），客体的类型（type）与规则作出访问控制的决策。

进程的类型在进程创建时确定且基本不变（一个例外是当进程有dyntransition权限时，可以在执行时改变其类型，这是个不安全的特性，故只允许进入对应许可集为原类型的子集的类型）。SELinux对系统中的所有需要保护对象的访问方式加以罗列，定义为对象类（object class）。之后依据主客类型，许可主体对客体的部分访问权限（即客体所属对象类的所有方法的某个子集）。SELinux实行白名单方式的访问控制，规则中未许可的访问将被拒绝。如图5：

基于角色的访问控制

SELinux中，基于角色的访问控制构筑在类型强制（TE）之上。一个SELinux对象安全上下文如下：

用户:角色:类型

在该上下文中，一个用户可能拥有多个角色，而每个角色则与多个类型相关联。

一个用户的进程（主体）的最初始的安全上下文在登录时获得。用户登录时确定用户的角色（从该用户拥有的多个角色中择一）。在登录后，运行新程序的进程的类型由如下决定：

• 可执行文件的类型

• 父进程的类型

• 规则库中，相关类型转换规则。如

type_transition user_t passwd_exec_t process passwd_t;

图6展示了通过类型转换来确定新进程的类型的全过程。

Bell-La Padula模型的实现

对BLP模型的支持是通过可选的MSL（multilevel security）机制实现的。为了支持MSL，SELinux对对象的安全上下文进行扩充：

用户:角色:类型:安全级范围（低安全级-高安全级）

其中，一个安全级有两个部分组成：敏感级（即密级）和附在本敏感级上的（0个以上）分类。敏感级之间是层次的，而分类则不是。因此，安全级范围的两端要求：

• 高安全级中的敏感级 > 低安全级中的敏感级

• 高安全级中的所属分类集合 包含 低安全级中的所属分类集合

例如，为了防止高密级的数据流向低密级的数据（保证机密性：向下读，向上写）：

mlsconstrain file write ( L1 domby L2 );

mlsconstrain file { read getattr execute } ( L1 dom L2 );

在第一条规则中，L1指主体的（安全级范围中的）低安全级，L2指客体（安全级范围中的）低安全级。这样，写某个文件必须保证，主体的安全级不得高于客体的安全级。

在第二条规则中，L1与L2分别代表主客体（安全级范围中的）的低安全级。这样，读取某个文件必须保证，主体的安全级不得低于客体安全级。

SELinux的访问控制过程

在启用SELinux的Linux发行版中，访问控制的过程如下：

• 进行DAC检查

• 进行TE检查

• 进行MLS检查

访问控制是每次访问时进行的。例如DAC仅在打开文件时进行访问控制，而SELinux则在每次对文件进行读（或其他操作）进行。这样作的好处是使得对许可规则的改变可以迅速反映出来。

SELinux的结构

图7，反映了SELinux在Linux内核中通过LSM（Linux Security Module）的一个实现。其有如下特点：

• 对内核对象提供访问控制

• 通过访问向量缓冲（Access Vector Cache：AVC），来减小访问控制带来的性能开销

• 通过伪文件系统SELinux（就像许多Linux的伪文件系统一样）来导出管理接口
  
  

图8，通过在用户空间部署SELinux¹，来提供对用户对象的访问控制。策略管理服务器（policy management server：PMS）管理和操作所有系统策略。

PMS本身是个用户空间的对象管理器，负责创建代表策略资源的对象类，并对这些策略资源实施细粒度的访问控制。通过PMS，可以允许用户管理工具不用改变TE许可规则，增加用户和赋予角色。更大的好处，可以仅授权数据库服务器改变与之相关的对象类（object class）和TE规则。

PMS把系统策略分离为内核与用户两部分，分别把他们载入内核安全服务器与用户空间安全服务器（userspace security server：USSS）。由于PMS是一个运行中的服务器，可以扩展其接口来允许远程的网络访问，从而支持分布式策略管理。PMS与USSS允许运行时刻注册对象类（object class）。

总结

SELinux的限制：

• 复杂性：用户需要定义类型（Type）和（极为繁多的）规则。SELinux全面涵盖了各式各样的安全威胁，这也是它复杂的一个原因。为了降低其复杂性，SELinux的策略可模块化，并适时载入。

• 性能：复杂性带来性能上的开销，这在桌面或者服务器系统上也许并不重要，但是对于消费电子设备来说是不可接受的。因此需要进行相应的优化。在08年的嵌入式Linux会议（Embedded Linux Conference：ELC）上，Yuichi Nakamura宣称通过削减策略（保留适合嵌入式环境的策略——一个令人生畏的工作，但通过创建更简单的策略语言和策略编辑器，Nakamura做到了：4.6M大小的策略文件削减为60K）、移除多余许可检查、优化读写路径和转换缓冲静态分配为动态分配，使得在其SuperH平台上的性能提升了10倍，内存节省了250K²。

• 动态最小权限原则：SELinux的主体（进程）被赋予某一类型（Type）后，在其生命周期内基本不能再改变（一个例外是有dyntransition权限时，允许其改变为某些权限更小的类型上）。在基于工作流的模型中，在工作流的各个阶段，可以指定不同的最小权限，即理想下，贯穿于工作流各个阶段的进程应在执行中改变类型——动态最小权限。

• 粒度：SELinux的访问控制的粒度是对象，或者具体的说来，是在当前安全上下文下，决策是否允许对客体对象方法的访问。而对于某些复杂的方法——整合多个功能、参数之间相互依赖，组合形成不同的访问方式，SELinux便无法控制了。

对于复杂性，需要程序的开发者负责开发，实现对应程序运行时最小权限的策略（程序的开发者应该更加了解程序运行的最小权限是什么）。用户信任并接受相应策略，并在安装时刻随程序一起安装到系统中（相应策略应与系统已有策略一致）。这样用户就无须为策略的编写而担心。事实上，可以把对程序的强制访问控制策略看成是程序的正确性断言，通过信任断言的有效性（断言失败，程序便被终结而不会造成更大的破坏），来信任程序。故用户可以回到原来的DAC世界中。

对于动态最小权限原则，可以考虑缩小主体的粒度，比如为一个代码段。不同的代码段完成不同的工作阶段，一个进程则由多个不同类型（Type）代码段构成。实现起来需要考虑的一个问题是相应代码段的安全标签的存储问题：主流操作系统支持的外存的存储粒度是文件，而多个代码段则可能被存储到一个库文件中，这样各个代码段安全标签存储、代码段的界定值得考虑。也许需要SELinux引入新的信任（比如信任编译器/链接器）。

强制访问控制技术——SMACK

针对SELinux的复杂性带来的实际应用部署上的困难，SMACK³（The Simplified Mandatory Access Control Kernel）通过简单的方式，来解决SELinux所针对安全威胁的某个子集。

SMACK访问控制方式相当简单：

• 标签与标签名一致

• 标签之间没有隐含的关系

• 主客体有各自的标签

• 客体的标签源自创建其主体的标签

• 直接指明访问控制许可

比如：sub obj r，就许可了有标签sub的主体对标签为obj的客体有读权限。所有的许可（信任）关系必须被直接指明。

Bell-LaPadula模型的实现

需要指明所有级别的相互许可关系，比如有三个秘密度依此上升的安全级：unclass、 secret、 topsecret，实现向下读，需要以下规则：

• secret unclass rx（读、执行权限）

• topsecret secret rx

• topsecret unclass rx

强制访问控制：基于路径 vs 基于标签

在SUSE Linux，引入了名为AppArmor的基于路径的访问控制。基于路径的访问控制方式，相当灵活，例如：

/home/*/public_html/**.html r

许可了各个用户的public_html目录下.html文件的读操作。与之相比，在SELinux和SMACK中需要对上述每个文件打上相应标签。

对基于路径的访问控制最大的批评是这种方式很容易被绕过。比如可以建立一个指向目标文件，从而获得一条不同的路径，绕过对原路径的进行的访问控制。

基于路径的访问控制比较贴近管理逻辑（即高层），而访问控制机制只有在底层实现才能确保不被绕过，因此可以考虑在比如SELinux管理工具中基于路径，之后管理工具对相应文件贴上标签。这个过程中管理工具的行为类似一个编译器：把高层的逻辑翻译成底层的实现。

其他可以考虑的方式，是对文件系统的名空间给予保护，从而防止用户随便增加新的名指向被保护名（代表的文件），来确保基于路径的访问控制不被绕过。

总体来看，MAC更加倾向反应对程序的正确性的强制（断言），而非用户的意志。因此需要DAC（反应用户的意志来进行补充）。可以如下表达：MAC与程序紧密联系，而DAC则与用户联系密切些。因此，终端用户定制安全环境，应该更多地从DAC入手。

当用户的角色成为MAC确定最小权限的因素时（变量），MAC与DAC可能会存在逻辑上的联系，需要定义/导出公认的、一致的角色。

1这个项目在：http://sepolicy-server.sourceforge.net

2LWN.net Weekly Edition 2008.4.24 http://lwn.net/Articles/278492/

3SMACK已经融入了Linux内核2.6.25中