级别： 初级 汪伦伟 (xc_wangwei@163.com), 国防科技大学博士
2005 年 2 月 01 日 访问控制框架可以很好地满足安全操作系统发展对多安全策略的需求，但是多个安全策略之间可能存在冲突，如何有效组织多个安全策略形成最终的安全决定，则是访问控制框架需要考虑的比较重要的问题。本文对当前主要的访问控制框架进行分析，针对其存在的问题：没有主从和优先顺序以及有主从顺序，但对策略模块的要求太高，提出了一种新的多策略组合方法：基于控制标记的多策略组合方法，它根据控制标记的不同对应安全策略的主从和优先关系。本文在给出多策略组合算法后，并将其在基于Linux的GFAC访问控制框架上得以实现。
1. 引言
安全操作系统的研究最初从1967年Adept-50项目启动时的奠基时期[1]开始，安全操作系统的基本思想、理论、技术和方法逐步建立。到TCSEC标准[2]颁布开始的食谱时期，研究如何使用安全评价标准来设计安全操作系统，在此阶段出现了从C2---A1各等级的系统，但存在的问题是系统与变化的应用需求相脱节。
随着90年代初Internet影响的扩大，分布式应用的迅速普及，单一安全策略与安全策略多种多样的现实世界之间拉开了很大的差距。美国国防部推出通用安全体系结构(Denfence Goal Security Architecture, DGSA)，其显著特点之一是对多级安全策略支持的要求，安全操作系统的研究进入多策略时期。
从单一策略支持到多种策略支持，安全操作系统迈出了向实际应用环境接近的可喜一步。然而，R.Spencer等指出[17]，从支持多种安全策略到运行策略灵活性，还有相当一段距离。策略灵活性是动态策略时期的重要特征，1999年，Flask[5]系统的诞生是动态策略时期的帷幕徐徐打开的标志。
当前的动态策略时期，安全操作系统支持多种安全策略的动态变化，实现安全策略的多样性，为安全策略提供灵活性支持，没有一个策略模型可以满足每种环境的安全需要，系统必须支持多个安全策略模型，如RSBAC（Rule Sets based Access Control）[3,4]、SELinux（Security Enhance Linux）[5,6,7,8]就支持多个安全策略模型。而如何有效地在系统中组织多个安全策略是安全操作系统研究的难题。
访问控制框架可以很好地支持多安全策略，如图1：ISO通用访问控制框架[16]。访问控制框架基本的实体主要由主体、客体、访问实施组件（Access Control Enforcement Function，AEF）和访问控制决定组件（Access Control Decision Function，ADF）组成。主体向访问实施组件发出对客体的访问请求，访问实施组件AEF向访问控制决定组件ADF询问判定请求。访问决定组件根据多种访问决定信息（Access Decision Information, ADI）如主体的ADI、访问请求ADI和客体ADI以及访问控制策略规则等形成最后的判定结果，向访问实施组件返回，则由访问实施组件实施访问控制判定。
访问控制框架将安全策略决定和其实施相隔离，不管安全策略判定是如何形成的，也不管它们如何随时间的推移而发生变化，都确保访问控制框架子系统总是有一致的安全策略判定视图，从而在安全策略方面提供灵活性。但是多个安全策略规则之间可能存在冲突，如何有效组织多个安全策略形成最终的安全决定，则是访问控制框架需要考虑的一个重要的问题。
Linux系统中提出的LSM框架（Linux Security Module）[9,10,11]和FreeBSD系统[12,13,14,15]中提出的MAC框架都支持多个安全策略，但是组织多个安全策略形成策略判定的方法不相同。下面我们通过对几种访问控制框架中多安全策略的如何组合形成安全决定的问题进行分析与比较，针对其存在的问题，提出一种新的多策略组合问题的解决方法：基于控制标记的多策略组合方法，从而可以很好地满足实际环境的需要，并在基于Linux的GFAC框架上加以实现。
本文先对有关的访问控制框架中安全策略的组合情况进行介绍，并进行了分析；针对其存在的问题，提出基于控制标记的多策略组合方法的基本思想；然后，将基于控制标记的多策略组合方法的基本思想在基于Linux的GFAC框架上加以实现，并描述其实现算法。之后对该多策略组合方法进行分析；最后对本论文进行总结。
2. 相关研究工作
动态安全策略时期，安全操作系统支持多种安全策略的动态变化。Flask体系结构实现了动态安全策略，支持策略灵活性。Flask安全体系结构描述两类子系统之间的相互作用以及各类子系统中的组件应满足的要求，两类子系统中，一类是对象管理器，实施安全策略的判定结果，另一类是安全服务器，作出安全策略的判定，是图1：ISO通用访问控制框架的具体实现。
Flask原型系统的安全服务器实现了由四个子策略组成的安全策略，这几个子策略是多级安全（MLS）策略、类型实施（TE）策略、基于标识的访问控制（IBAC）策略和基于角色的访问控制（RBAC）策略。安全服务器提供的访问判定必须满足每个子策略的要求。
GFAC（Generalized Framework for Access Control）研究项目由Marshall Abrams领导，于九十年代前期完成。它提供了一个用于表达和支持多安全政策的框架，其主要目标是：
- 使得描述、形式化和分析各种访问控制政策更容易
- 使得用户可以从系统开发者提供的多个安全政策支持模块中，选择几个进行配置，得到需要的安全政策。并且可以确信安全政策得到了正确的实施。
- 对于所支持的每个安全政策，都能证明满足了政策的原始定义。
RSBAC系统是以Linux操作系统为基础的基于GFAC框架的安全操作系统，多种不同的安全策略模块作为ADF已经在系统中实现，除了传统的BLP模型，还包括安全信息修改策略（Security Information Modification, SIM）和功能控制策略（Functional Control, FC）、文件标记策略（File Flags, FF）、角色兼容性策略（Role Compatibility, RC）、授权执行策略（Authorization enforcement, AUTH）和访问控制列表（ACL）等。访问请求必须满足全部安全策略才授予许可权。
LSM是在主流Linux内核上开发的一种访问控制框架，其设计目标要求不同的访问控制模块可以在相同的Linux内核上实现，如果使用不同的安全模型，只需要以可装载内核模块的形式加载不同的安全模块。当前大量已经存在的增强的访问控制模块都可以在Linux中通过LSM得以实现，包括POSIX.1e capabilities、SELinux和DTE等。
LSM框架是一个灵活的、可扩展的安全框架，支持多个MAC策略。首先向系统注册的安全模块为主要模块，LSM框架提供简单的机制将其它的安全模块与主要安全模块进行堆栈而对多安全策略模块组合的支持。关于如何堆栈的实际细节将由系统主要安全模块决定。在主要模块之后注册的安全模块为辅助安全模块，需要向主要安全模块注册，由主要安全模块决定是否可以注册，如果它不希望支持堆栈，就可以总是返回一个错误。
TrustedBSD项目组开发的MAC框架支持多个MAC策略，是一个灵活的、可扩展的安全框架，MAC框架可以在编译或运行时对内核的访问控制模型进行扩展。新的系统安全策略可以作为内核模块实现，被链接到内核。
MAC框架采用安全策略链表的形式支持多安全策略。多个安全策略在注册时插入链表，在进行访问控制决定等操作时，依次遍历已注册的各个安全策略，执行各个安全策略对应的访问判定操作。访问控制判定的结果将由多个策略模块的判定结合相综合，只有所有策略都允许才可以进行访问。多策略模块可以包括BIBA完整性策略，MLS安全策略，基于规则的TE访问控制策略，以及可以支持在TrustedBSD MAC框架上的分层的NSA FLASK框架。
3. 访问控制框架中基于控制标记的多策略组合方法
3.1 基本思想
前面我们已经介绍几种访问控制框架中多安全策略的组合问题分别是如何解决的，总的来说，主要是两类。一类是多安全策略之间是并列关系，没有主从、优先顺序，访问控制决定需要满足所有的多安全策略，如Flask、GFAC和TrustedBSD中的MAC框架；另一类是多安全策略之间有主从关系，安全策略的组合问题由最先向系统注册也即主安全模块决定，它可以允许或禁止多安全策略模块的堆栈，如果允许，则需要处理模块堆栈的相关处理，如LSM。
对于前一种情况，多安全策略并列关系，这是多安全策略组合最简单也是最常用的方式，但是应用环境多样性和多变性，不同的系统运行环境对安全策略的需求不同，需要多种安全策略之间存在一种主从、优先顺序。对于第二种情况，安全策略之间的确存在优先顺序，但是其将安全策略的组合问题交给主安全策略模块，增加了主安全模块的设计及实现难度。在当前的LSM实现中，因为相互之间存在的冲突并没有很好地解决，多安全策略的堆栈中辅助安全模块主要是那些不影响主安全模块中内核数据结构安全域的安全模块，如能力等。
为了满足现实系统运行环境对多种策略有主从、优先级的需求，同时不增加安全策略模块的设计难度，我们提出一种新的多策略组合方法：基于控制标记的多策略组合方法。当安全管理员加载安全策略模块时，根据现实系统的需要，提供一个策略模块优先级控制标记control_flag，根据控制标记的不同组织访问控制策略模块，并形成相应的访问控制决定。策略模块的控制标记有：
- required：表示该策略模块在形成最终的访问决定是必须要的。如果带有该控制标记的策略模块不允许访问请求，则继续执行所有其它安全策略模块，当全部执行完所有的安全策略模块，则返回第一个不允许访问的错误值。如果返回成功，则所有带required标记的策略模块必须报告为成功。
- requisite：除了失败会终止执行所有策略模块并向请求者返回失败结果外，其它如上所述。
- optional：顾名思义，不要求使用该策略模块，即使这特殊的模块返回失败，还是可能允许访问的。策略模块框架忽略其失败，并继续处理下面的策略模块。
- sufficient：如果该模块获得成功时，堆栈中的所有其它模块被忽略，对请求者返回成功结果。特别是，如果该模块成功时，无论与后来模块相关的控制标识是什么，都不执行后面的模块。如果该模块失败，则类似于optional控制标记，也不会造成整个策略组合失败，除非系统中只有这一个模块。
表1说明了一个例子配置情况，在此使用MLS、BIBA和LOMAC策略模块。Required控制标记表明MLS访问控制策略对于形成最终的访问控制决定是必要的，对于BIBA访问控制策略作为一种可选择的策略，LOMAC策略模块也是必要的。只有在满足MLS和LOMAC策略模块之后才可以获得访问权限。
表一：
| 顺序 | 模块类型 | 控制标记 | | 1 | MLS | required | | 2 | BIBA | optional | | 3 | LOMAC | required |
3.2 基于控制标记的多策略组合方法在基于Linux的GFAC上的实现
针对基于控制标记的多策略组合思想，我们选择在基于Linux的GFAC框架上实现。RSBAC是一个基于GFAC实现的安全操作系统，它支持多个安全策略，包括MAC、FF、RC、CAP（能力）等。如何在Linux上构建RSBAC系统，可以参考网站：http://www.rsbac.org。
针对具体的某个访问请求，RSBAC系统定义了4个ADF的判定返回值：
enum rsbac_adf_req_ret_t {NOT_GRANTED,GRANTED, DO_NOT_CARE, UNDEFINED };
RSBAC还定义了系统支持的多个安全策略：
enum rsbac_switch_target_t {MAC,FC, FF,RC,AUTH,CAP, SW_NONE};
系统定义一个存放不同策略情况下的访问判定结果的数组：
enum rsbac_adf_req_ret_t mod_result[SW_NONE]
当有某个访问请求时，系统调用对应的访问判定函数，如在MAC访问控制策略下，调用rsbac_adf_request_mac（）函数，将判定结果值存储于mod_result[MAC]中，然后将当前结果值与以前的result进行计算，以判定在包括MAC策略下的访问判定，代码包括：
mod_result[MAC] = rsbac_adf_request_mac(request,
caller_pid,
target,
tid,
attr,
attr_val,
owner);
result = adf_and_plus(result, mod_result[MAC]);
|
rsbac_adf_request_mac()函数中的参数，包括是访问请求，主体、客体的标识和属性等，这些都是MAC访问控制策略在形成访问判定时所必需的参数，result是在复合策略情况下的访问判定。
adf_and_plus()函数是计算两个判定结果的复合结果，判定情况如下：
从表中可以看出，只有当判定结果是GRANTED或DO_NOT_CARE时，才会允许该访问请求。
在RSBAC系统的基础上，为了实现基于控制标记的多策略组合方法，本文新定义不同策略对应的控制标记：
enum rsbac_control_flag_t { REQUIRED, REQUISITE, OPTIONAL,SUFFICIENT};
然后将不同策略与控制标记对应起来：
enum rsbac_control_flag_t mod_control_flag[SW_NONE]
通过赋值，可以将不同策略对应某个不同的控制标记，从而说明不同策略的重要性及在形成访问判定时的优先级。
mod_result[]数组还是存放在不同策略下形成的判定结果，主要是修改adf_and_plus()函数以体现基于控制标记的多策略组合方法的思想。
在进行访问控制判定时，首先需要查找访问控制策略配置情况，根据控制标记按顺序调用已注册的策略模块对应的访问控制函数，返回访问控制判定结果。访问控制判定算法如下：
(1) 初始化
定义返回判定结果的初始值result、访问控制策略数组的第一项：poliy[0]
(2) 按顺序遍历访问控制策略数组
针对当前指向的策略模块作出访问控制决定，然后根据控制标记形成总的判定结果
while(policy[i]是策略数组中未作出判定的策略)
执行当前策略对应的访问控制检查函数，返回结果mod_result[i];
针对result、mod_result[i]和mod_control_flags[i]三个值形成当前的result值
如果mod_control_flags[i]为required，则
如果mod_result[i]为允许，则当前result值不变；
如果mod_result[i]为禁止，则当前result为错误情况值；
如果mod_control_flags[i]为requisite，则
如果mod_result[i]为允许，则当前result值不变；
如果mod_result[i]为禁止，则当前result为错误情况值，马上返回错误结果；
如果mod_control_flags[i]为optional，则
如果mod_result[i]为允许，则当前result值不变；
如果mod_result[i]为禁止，则当前result为特殊情况值；
如果mod_control_flags[i]为sufficient，则
如果mod_result[i]为允许，则当前result为允许，马上返回结果
如果mod_result[i]为禁止，则当前result为特殊情况值，类似于optional控制标记；
i++;
(3) 返回判定结果result
具体在RSBAC中上述算法的实现对其源代码的影响很小，主要是对返回值进行比较判定。
3.3 分析
多安全策略模块如何有效组合以满足现实系统环境中不同的策略需求，这是比较重要且比较实际的问题。上述基于控制标记的多策略组合方法可以有效地解决系统在不同条件下对安全策略的不同需求；而且实现比较简单，对访问控制模块的影响也比较小。
基于控制标记的多策略组合方法，只是需要安全操作系统的管理员加载策略模块时作出相应的控制标记的选择，同时安全策略模块的加载顺序也是很重要的，需要特别注意，当然对于安全操作系统的管理员，加载哪些安全策略模块以及以什么样的顺序加载都是应该知道的。这其实并没有增加系统本身及管理的复杂性。
我们知道，如果所加载的多策略模块的控制标记都选择为required，则各个安全策略没有优先及侧重点，只有当所有的安全策略都满足时才允许访问控制请求。这是基于控制标记的多策略组合方法的一种特例，与当前的一些多策略组合方法一致。
4. 结论
安全操作系统的发展需要支持动态多安全策略，支持策略灵活性，访问控制框架可以很好地满足安全操作系统发展的需要。但是多个安全策略之间可能存在冲突，如何有效组织多个安全策略形成最终的安全决定，则是访问控制框架比较重要的问题。本文通过对当前主要的访问控制框架进行分析，我们知道多安全策略的组合问题解决方法主要是两类：一类是多安全策略之间是并列关系，没有主从、优先顺序，访问控制决定需要满足所有的多安全策略；另一类是多安全策略之间有主从关系，安全策略的组合问题由主安全策略决定。前一种不能很好地满足系统环境的多样化和多变化的需要，而后一种则增加了安全策略模块设计及实现的难点。本文提出的基于控制标记的多策略组合方法在基本上不增加系统及策略模块的复杂性的基础上，又可以实现多安全策略的主从、优先关系，可以很好地满足实际的需要。
参考文献
1. 石文昌 安全操作系统研究的发展《计算机科学》Vol.29 No.6（2002 年6 月）和Vol.29 No.7（2002 年7 月）
2. Department of Defense, Trusted Computer System Evaluation Criteria, DOD 5200.28-STD, December 1985.
3. RSBAC homepage http://www.rsbac.org
4. Amon Ott the Rule Set Based Access Control (RSBAC) Linux Kernel Security Extension paper for International Linux Kongress 2001
5. Ray Spencer, Stephen Smalley, Peter Loscocco, Mike Hibler, David Andersen, and Jay Lepreau, "The Flask Security Architecture: System Support for Diverse Security Policies", Proceedings of the Eighth USENIX Security Symposium, The USENIX Association, August 1999.
6. Security-Enhanced Linux . http://www.nsa.gov/selinux
7. Stephen Smalley and Timothy Fraser, "A Security Policy Configuration for the Security-Enhanced Linux", NAI Labs Technical Report, February 2001.
8. Peter Loscocco and Stephen Smalley, "Meeting Critical Security Objectives with Security-Enhanced Linux", Proceedings of the 2001 Ottawa Linux Symposium, July 2001.
9. WireX Communications. Linux Security Module. http://lsm.immunix.org/
10. Chris Wright and Crispin Cowan Stephen Smalley Linux Security Module Framework ：General Security support for Linux Kernel
11. Stephen Smalley, Timothy Fraser, and Chris Vance. Linux Security Modules: General Security Hooks for Linux. http://lsm.immunix.org/, September 2001.
12. FreeBSD Project . FreeBSD home page . http://www.FreeBSD.org/
13. Trustedbsd Project Trusted home page http://www.trustedbsd.org/
14. Robert N M Watson Introducing Supporting Infrastructure for Trusted Operating System Support in FreeBSD In BSD Conference, Monterey, CA, USA, October 2000
15. Robert N M Watson TrustedBSD： Adding Trusted Operating System Features to FreeBSD In proceedings of the USENIX Annual Technical Conference, June 2001
16. ISO 10181-3 Information technology-Open Systems Interconnectin---Security frameworks for open system: access control framework
17. Bell D E,Lapadula L J.Secure Computer System: Unified Exposition and MULTICS Interpretation. MTR-2997 Rev. 1, The MITRE Corporation, Bedford, MA, USA, Mar.1976
关于作者
对本文的评价
| 
