可信增强的Flask访问控制框架的总体应用设计和实施方法

借鉴可信计算思想，从可信增强的角度出发，提出了一个可信增强的访问控制框架，并给出了该框架的具体实施流程。该框架在普通Flask的基础上引入了身份认证和可信监控机制，解决了传统访问控制中存在的“内部威胁”问题，它是在访问控制中引入可信计算的一个尝试，具有一定的指导意义。

目前，大部分终端平台信息安全系统主要是由防火墙、入侵监测和病毒防范等组成，但仅靠“堵漏洞、作高墙、防外攻”无法从根本上解决终端平台的安全问题。纵观安全操作系统近40年的发展历史可以发现，安全操作系统得到了长足的发展，并在访问控制框架和安全模型方面均取得了丰硕的成果。但是，传统的访问控制并不能解决“内部威胁”问题。造成内部威胁的原因主要是“脆弱性或漏洞攻击”。“脆弱性或漏洞攻击”是指内部授权主体可以绕过检测和访问控制机制，利用自身的权限和已知的系统脆弱性及漏洞，通过完全合法的操作发动内部攻击。从技术上讲，这种内部威胁的根源在于传统的访问控制理论存在的缺陷。传统的访问控制理论是基于“关口控制”理论实施的，即它不会让不符合条件的主体对客体进行请求的操作，但是主体一旦取得相应的操作权限，它在允许操作范围内的活动行为就可以畅通无阻。究其原因，主体对客体的访问和行为是根据授权和身份识别来决定的，授权一旦确定，就不会再考虑主体的表现，也不会再考虑主体行为的可信性，直到另外一次授权开始。另外，传统的访问控制也不能保证客体内容的真实性和完整性。

因此，寻求一种通用的方法对授权操作的行为进行监管，控制授权后的信息流失，保证合法主体的行为得到应有的控制和监督，才能使这类主体的行为规范可信，预防和控制内部威胁的发生。目前，随着新的安全技术的兴起，可信计算也成为人们关注的热点。从可信计算的概念及其特征可以发现，通过引入可信计算解决上述安全问题是可行的。

1 可信计算思想

为了提高计算机的安全防护能力，由Intel、惠普、微软、IBM等业界大公司牵头，于1999年成立了可信计算平台联盟TCPA（后于2003年改组为TCG），并提出了“可信计算”的概念。可信计算旨在从硬件体系结构和系统完整性角度来提高终端计算平台的安全性，解决终端平台安全性问题。它认为如果终端计算平台从一个初始的“可信根”出发，在终端平台计算环境的每一次转换时，这种可信状态都可以通过传递的方式保持下去而不被破坏，则该终端平台就始终是可信的。在可信环境下不存在不被信任的实体，因而可以很好地保证平台本身及上层应用的安全。

信任链的传递是体现可信的重要手段，它是可信计算平台的核心机制。系统加电后，在可信硬件平台的控制下，BIOS会将信任传递给主引导分区，主引导分区将信任传递给操作系统装载器，操作系统装载器将信任传递给操作系统内核模块，也就是说可信链的传递是分层进行的。当低级别的节点验证到高一级的节点是可信时，低级别节点才会把可信计算平台的运行控制权转交给高一级节点。可信计算平台正是基于这种信任链传递的机制将可信扩展到了应用程序部分。平台可信的验证通过哈希运算进行，在验证过程中，各程序的杂凑值将会被存储在平台配置寄存器PCR（Platform. Configuration registers）中，而且在关机之前这部分PCR的值不会被重置，只能被扩展。当远程或本地程序（请求者）需要验证当前系统是否处于预定义的可信状态时，这些PCR的值就会被读取。请求者对这些可执行体或数据进行杂凑运算，并且与PCR中的预期值进行比较。如果相同，则可以判定该系统运行的程序是预先规定的可信程序或者是可信数据。

2 可信增强的Flask访问控制框架的设计与分析

2.1 Flask访问控制框架

Flask是目前业界关注度最高的访问控制框架之一，它是由美国国家安全局联合犹他州大学和安全计算公司，以安全策略灵活性为目标设计开发的多访问控制策略支持框架。Flask严格分离了策略实施逻辑和策略决策逻辑。Flask由对象管理器和安全服务器两部分组成，对象管理器负责策略实施逻辑的执行，安全服务器负责策略决策逻辑的制定。Flask描述了对象管理器和安全服务器的交互，以及对它们内部组成部分的要求。Flask还借助一个访问向量缓存（AVC）模块来实现对动态策略和性能要求的支持。

如图1所示，在Flask访问控制框架下，主体要对客体进行操作。首先要将访问请求发送到对象管理器，对象管理器收集主客体的安全标签，对访问请求进行判断;对象管理器首先检查存放在AVC中的访问向量，如果存在此访问向量，则直接返回在AVC中的访问向量，否则，向安全服务器提出查询请求。在安全服务器中根据主客体的SID及相应的类，针对相关的安全策略对请求进行计算，然后返回相应的访问向量决策，同时把此访问向量存放在AVC中。如果策略允许主体在客体上执行预期的操作，则该请求就会被允许，否则，该请求就会被拒绝。

2.2 可信增强的Flask访问控制框架设计

尽管Flask安全框架在一定程度上解决了系统的安全问题，但其解决的是不让非法主体对系统资源进行恶意的访问控制，而无法解决合法主体的可信性问题，即前言中描述的“内部威胁”问题。另一方面，Flask也无法保证系统中客体内容的完整性和真实性问题。结合可信计算，本文提出了一种可信增强的Flask 访问控制框架，它在普通Flask框架的基础上加入了身份认证和可信监控机制，如图2所示。

访问控制中，用户身份认证是非常重要的。在用户对系统资源进行访问控制之前，首先要经过身份认证模块识别用户的身份，访问控制模块才能根据用户的身份和安全策略库决定用户是否能够访问某个资源。

可信监控机制用于保障安全策略的正确实施，它在安全服务器内实现。其主要工作有：（1）对主体行为进行监控，即在进行访问控制之前，确保主体的行为是可信的，不会给系统造成破坏；（2）对客体进行验证，即根据客体的当前状态验证主体的身份和客体自身的完整性，确保客体内容的真实性；（3）监控访问行为，即监控所有与安全相关的访问企图，确保访问企图不被篡改，访问机制不被绕过。图3是可信监控机制的示意图。

可信监控机制可分为可信验证、可信存储和可信报告三部分，其中可信验证必须存在，可信存储和可信报告可选。为了实施可信验证，首先要对进行可信验证的实体进行可信度量，可信度量由度量实体（或者是度量事件）启动，通过对度量实体进行SHA1运算得到一个杂凑值，度量实体会将这个杂凑值存储在内核里的一个有序度量列表中，同时将可信度量值报告给存储在可信硬件里的平台配置寄存器（PCR），以扩展度量列表。可信验证结合度量列表中存储的度量值，对主客体进行一致性验证，检查其是否被篡改或破坏，以确保主客体的可信性和完整性。验证过程依赖于度量列表中存储的基准度量值与当前状态的可信度量值的比较。若当前状态的可信度量值符合基准度量值，则认为该实体（或事件）是可信的［4］。

在加入了身份认证和可信监控之后，访问控制的工作流程如下：

（1） 在身份鉴别的控制下，用户登录，启动访问控制模块；

（2） 主体向对象管理器发送访问请求，要求对相应的客体进行请求操作；

（3） 对象管理器将访问请求发送给安全服务器。请求包括主客体标识以及请求类型等；

（4） 安全服务器接收到访问请求之后，启动可信监控机制；

（5） 可信监控机制根据主体的当前访问行为，判断主体的可信性及主体的这次访问行为是否为不良行为。如果主体可信并且这次访问行为完全合法，可信监控机制则会转向对客体的验证，否则，拒绝这次访问；

（6） 可信监控机制根据访问请求，验证客体的真实性和完整性，如果验证出客体的真实性和完整性未遭到破坏，可信监控机制则会将访问控制权转向安全服务器的安全决策逻辑的制定，否则，拒绝这次访问；

（7） 安全服务器根据当前的访问控制策略库进行访问决策的判定，如果这次访问行为满足访问控制策略，则允许主体的这次访问行为，否则，拒绝本次访问；

（8） 安全服务器将判定结果返回给对象管理器，对象管理器依据决策结果实施主体对客体的访问控制；

（9） 可信监控机制实施主体对客体操作的监控，如果出现违规行为，则撤销此次访问。

2.3可信增强的Flask访问控制框架分析

本文通过对普通Flask访问控制框架加入身份认证和可信监控机制，实现了一个可信增强的访问控制框架，通过实施这个可信增强的访问控制框架，可以实现对操作系统终端平台的机密性、一致性保障，并且具有较好的可用性。下面就这几个方面做简要说明。

（1） 一致性：通过在框架中实施可信监控机制对相应主体和客体（包括文件、目录、进程、套接字等）进行一致性验证。对主、客体的验证首先要检查主、客体是否存在预期摘要值，如果不存在，则为其生成预期摘要值（首次执行）；否则计算主、客体的当前摘要值，并且与保存的预期摘要值进行比较；如果不一致，则拒绝本次访问请求［5］。这样做可以保证系统资源的一致性，进而保证整个系统的一致性。

（2） 机密性：通过在框架中实施强制访问控制对登录用户、系统主体以及敏感信息进行处理，有权限的合法可信用户以及合法可信主体才可访问相应级别的敏感信息，从而解决了前言中阐述的“内部威胁”问题。对于某些由于意外情况而赋予的访问许可，通过实施强制访问控制，其实施范围也会限定在有限的区域，并且当再次执行访问控制决策时，也会由于一致性验证不成功而拒绝访问，从而保证了整个系统的机密性。

（3） 可用性：身份认证是保证用户身份合法性及唯一性的方法，而访问控制的有效性也需要建立在合法主体的基础之上。该框架在普通Flask框架的基础上增加了身份认证和可信监控，既解决了用户身份的合法性又解决了访问控制实施的可信性，它在保证机密性、一致性的基础上，对用户透明，不需用户干预，具有良好的可用性，并且能与操作系统良好兼容。

3 框架实现

本文以通用硬件平台和Linux-2.6.19内核为基础实现了此可信增强访问控制框架。由于所用通用平台，不具备TCG定义的可信根，因此原型中采用在其他项目中开发的具备密码功能和存储机制的可信支撑模块作为可信根。限于篇幅，本节只重点阐述这个可信增强的访问控制框架在内核的实施流程。

3.1 内核修改

可信验证机制是在位于内核空间的安全服务器内实施的，其主要在以下几方面对内核进行了修改：

（1） 添加了measure系统调用。真实的可信验证是在内核中执行的，因此在内核中添加了新的系统调用measure，其主要任务是识别系统（用户或内核级）上的检测点，即与执行相关的内容载入的地方，并且在这些位置上插入measure系统调用（或在内核里直接调用检测代码）。

（2） 添加了一个checkfile文件。checkfile文件用于存放检测值列表，包括BIOS、操作系统装载器、内核以及应用程序的检测基准值。在初始化可信验证之前，内核首先要载入检测值列表文件checkfile，若实际的启动或者运行过程与预期的不同，则checkfile的验证将会失败。不允许对 checkfile文件进行修改，否则攻击者将会隐蔽完整性相关的行为。checkfile文件使用可信硬件保护。

（3） 在内核代码中实现访问控制的关键点上插入监控函数monitor。monitor函数用于监控某些关键的访问控制实施，对于在访问控制中出现的某些意外攻击，monitor函数返回一个错误信息，并通知相应主体访问被篡改，需要撤销此次访问操作。

3.2框架实施

框架的实施过程包括框架的初始化和内核实施两个阶段。前一过程是策略实施的基础，包括用户身份认证以及可信环境的建立。用户身份认证通过TCG规范中的双向认证来实施，克服了传统认证方式的缺陷，使得操作系统与用户可以相互认证，从而确保用户身份信息正确映射到安全策略中；建立可信环境的目的在于将可信链传递到应用层以确保系统加电直至可信增强内核装载完毕各个环节的可信。内核实施包括策略初始化、主客体的完整性度量及验证以及安全策略的验证实施。策略初始化是将安全策略配置文件解密并导入内核空间；主客体的完整性度量及验证是对实施访问控制操作的主客体进行杂凑运算，与主客体的度量基准值进行比较，以确保主体行为的可信性和客体数据的完整性和真实性。其具体过程将在下面具体描述；策略实施是对通过了完整性验证的访问控制依据安全策略库实施安全策略裁决的过程。整个实施过程中前一环节为下一环节服务，逐层建立了系统的可信计算基（TCB），从而保证了框架实施的可信性。主客体的完整性度量是最为关键的步骤，下面将重点介绍。

为了实现对访问操作涉及的主客体的完整性度量及验证，本文在Linux内核中加入了一个checkfile文件专门存放度量基准值，其格式如下：

……

fedb1cff009e115f7f5f7b4533667a787798832d（hd0，1）/xen3.0.2.gz

0b397acac72a31aedc5f63c5f597c462e0815ed5 ftp

59e6215c821e78ef20d75bd6b63dd5a8b2af00ee/bin/hostname

……

当主体发起对客体的访问请求时，对象管理器将访问请求提交给安全服务器。安全服务器首先调用measure对相应的主客体进行可信检测与验证，也即启动框架中的可信验证机制checkfile_func（）函数来调用calculate_sha1（）函数，以对相应的主客体进行完整性度量，并且检查相应的主客体是否存在于checkfile中。如果不存在，则将已计算出的杂凑值扩展到checkfile中，以作为下次判断的依据；如果存在，则调用 strcmp（）函数将所得的杂凑值与基准值进行比较。若不匹配就显示警告信息，告诉用户此次访问操作的主体或客体的完整性已经被破坏，访问被拒绝；若匹配，则调用update_checkfile（）函数将所计算出的度量值扩展到checkfile文件中，并且在measure系统调用返回前，扩展相应的PCR寄存器，同时将访问请求移交给安全策略服务器，由策略服务器检查是否满足安全策略。若不满足，则拒绝本次访问；若满足则由对象管理器实施访问决策。在实施访问控制的过程中调用monitor监控函数对访问操作进行监控。图4是上述实施过程的流程图。

本文借鉴可信计算思想，从可信增强的角度出发，提出了一个可信增强的访问控制框架，并给出了该框架的具体实施流程。文章重点阐述了框架的总体设计和实施，旨在体现框架的可信增强思想。相比普通的访问控制，它可以确保主体行为的可信性、客体内容的完整性和真实性，以及访问控制行为的正确性。本文提出的这个可信增强的框架是对可信计算在访问控制中应用的一个尝试，在下一步工作中，将主要针对框架中存在的一些安全隐患和具体实施细节加以改进。

责任编辑：gt