基于管道的 TCB扩展模型

2010-03-20 07:18廖建华沈昌祥
北京工业大学学报 2010年6期
关键词:下层访问控制协商

廖建华,赵 勇,沈昌祥

(1.北京大学信息科学技术学院,北京 100871;2.北京工业大学计算机学院,北京 100124;3.中国科学院软件研究所信息安全国家重点实验室,北京 100049)

基于管道的 TCB扩展模型

廖建华1,3,赵 勇2,沈昌祥2

(1.北京大学信息科学技术学院,北京 100871;2.北京工业大学计算机学院,北京 100124;3.中国科学院软件研究所信息安全国家重点实验室,北京 100049)

为解决当前系统环境中应用安全与系统安全互相独立而存在的问题,提出了安全管道和TCB扩展的概念,给出了安全管道的形式化描述,并抽象出一种基于安全管道的 TCB扩展模型,说明如何利用 TCB扩展构建安全机制间的信息交互机制,以实现不同安全机制之间的统一.通过对 TCB扩展模型的安全性分析,进一步说明了模型的科学性和现实可行性.

TCB扩展;安全管道;应用安全机制;系统安全机制

当前,信息系统安全主要由应用安全和操作系统安全[1-3]组成.从概念上讲,这些安全机制都属于TCB的一部分,但是如果没有从系统整体安全的出发点考虑,各安全机制之间缺乏协调一致性,则容易导致如下问题:其一,操作系统安全机制运行于系统层,具有安全性强、不易被旁路的优点,而应用系统安全机制面向应用,具有应用的语义,能实施细粒度的访问控制.但是如果两者互相独立,则不仅不能充分发挥各自的优势,还有存在安全威胁的可能.应用安全做的再完善,如果没有操作系统安全的支撑,也存在被“抄底”的危险;其二,应用安全和操作系统安全都拥有各自独立的安全策略,多种安全机制共存且缺乏协调机制的结果必然导致其间的相互干扰和冲突,甚至影响信息系统的正常运行.应用系统安全与操作系统安全相互独立,用户对资源的访问请求在安全机制之间传递过程中存在应用语义缺失的问题.

为了解决上述问题,本文提出一种基于安全管道的 TCB扩展模型.采用积极防御全面防护的思想[4],以应用系统的安全防护为目标,构建与应用安全需求一致的系统 TCB,TCB由底层往上逐层扩展.通过安全管道将各层安全机制连接成一个有机的整体,避免 TCB内部安全机制的重叠以及减少其间的相互冲突,最终形成满足安全需求的系统 TCB.

1 相关工作

应用层安全机制与操作系统安全机制一致性问题的相关研究可以从考察当前广泛使用的 Windows系列操作系统入手,安全子系统是 Windows系列操作系统安全的基础[5-8],除了包括操作系统基本的安全机制之外,也为应用系统提供一些安全服务接口,如 Windows Filtering Platform(WFP).在 Windows 7中,可以通过这套 WFPAPI集将Windows防火墙功能嵌入到所开发的应用系统中.但是这并没有很好解决应用和系统安全的一致性问题,因为没有对应用进程的认证,也没有为应用提供操作系统级的访问控制支撑,所以应用和系统安全机制还是相对独立,其间的冲突依然存在.

SELinux[9]是当前安全操作系统的代表.在 SELinux中,每个对象(程序、文件、进程等)都拥有一个Security Context(安全上下文),也就是对象的安全标签,上面记录着这个对象所具有的安全权限,并可以通过制定安全策略来定义这些对象所具有的权限.SELinux运行在操作系统层,通过配置安全策略可以实现对应用系统的控制和保护,在一定程度上实现对应用安全的支撑.但是由于没有相应的机制将应用相关的语义传递给 SElinux,因此无法实现细粒度的安全支撑.

文章在此提出一种基于管道的 TCB扩展模型,以实现安全机制间的协调.

2 基于管道的 TCB扩展模型

2.1 模型设计思路

分析当前大多数重要应用系统,其安全机制即系统 TCB主要由操作系统访问控制和应用系统访问控制组成(如图 1所示).TCB扩展模型要实现不同安全机制间的协调一致,包括访问请求信息的传递和策略同步等,因此需要引入一种不同安全机制实体间的专有信息交互机制,用于实现 TCB的扩展,模型主要关注 TCB扩展以及扩展的原则.

2.2 模型安全目标

TCB扩展模型是为了构建安全实体间的安全管道,具体安全目标如下:

1)保证安全实体的可信.可信是安全的保证,因此,TCB扩展首先要做到的就是验证上层安全机制实体的可信.

2)协调安全机制间的接口.原始的访问请求信息需要以安全管道的格式交互,因此安全机制间需要一致的接口,接口的格式需要根据实际需求由上下层安全机制通过 TCB扩展协议协商确定.

3)安全机制间的安全交互.通过安全管道传递的访问请求信息涉及到对一些重要敏感信息的访问,因此保证访问请求信息的机密性和完整性显得尤为重要.

2.3 模型描述

2.3.1 TCB扩展模型的组成元素

定义 1 基本变量

S表示主体类型的集合,Su∈S、Sl∈S分别表示上下层安全机制相关的主体集合;O表示客体类型的集合,Ou∈O、Ol∈O分别表示上下层安全机制相关的客体集合;P表示安全策略类型的集合,Pu∈P、Pl∈P分别表示上下层安全机制相关的策略集合;A={r,w,rw,e}表示访问行为集合,分别表示只读、只写、读写和执行;R=S×O×A表示访问请求类型的集合,Ru=(Su×Ou×A)∈ R、Rl=(Sl×Ol×A)∈ R分别表示上下层访问请求集合;D={yes,no,error}表示判断结果;C表示访问控制类型的集合,Cu∈C、Cl∈C分别表示上下层访问控制机制集合.fac∈Cu:Ru×Pu→D×Rl为访问控制函数,表示对访问请求的判断并生成下层安全机制的请求.

定义 2 安全机制定义

M=C×P表示安全机制类型的集合,是访问控制和安全策略的总和,mu=(Cu,Pu)∈M表示上层安全机制,ml=(Cl,Pl)∈M表示下层安全机制.{m1=(C1,P1),m2=(C2,P2),…,mn=(Cn,Pn)}⊆M表示系统各层安全机制.

2.3.2 安全管道定义

安全管道是指为实现安全目标而构建的 TCB内部安全实体间的专有信息交互机制.下面分别从安全管道的交互内容、输入/输出接口、传输方式等方面进行定义.

定义 3 安全机制间交互的内容

图1 应用安全体系Fig.1 Architecture of application security

为了实现安全机制间的一致性,安全管道还需要传递与访问请求相关的附加信息,用 E表示,可以将应用相关的主体信息作为附加信息通过安全管道传递到下层安全机制.I表示安全机制间交互的信息,Iu→l=R×E表示上层到下层的访问请求,Il→u=D表示下层返回的访问决策信息.

定义 4 安全管道接口

分别用 Hin和 Hout表示输入输出接口,则有 Hio=Hin×Hout表示安全管道接口,用 Ich表示在安全管道中传递的信息.可得 Hout:I→Ich表示输出接口对信息的封装,Hin:Ich→I表示输入接口对信息进行解封装,则有:∀i∈I⇒(∃hin∈ Hin∧∃hout∈Hout∧i=hout(hin(i)))表示通过管道输入接口进入安全管道的信息能原封不动地从安全管道的输出接口输出,以此保证传输信息的一致性.

定义 5 安全管道的安全传输机制

安全管道需要保证传输信息的完整性和机密性,用 Hsec表示信息保护机制,在此采用密码机制对信息进行安全保护,在传递前对信息进行加密处理,到达对端再解密,用 Ienc表示加密后的信息,Henc:Ich→Ienc表示对信息加密处理,Hdec:Ienc→Ich表示对信息解密处理,则有 Hsec=Henc×Hdec,管道传输信息的安全可以通过如下公式保证:

定义 6 安全管道协商机制

定义 3~5构成的安全管道的基本属性需要通过协商机制协商确定.用 N表示协商机制.Ninfo:Mu×Ml→I表示依据上下层安全机制协商需要通过管道传递的内容;Nio:Mu×Ml×I→Hio表示接口协商;Nsec:Mu×Ml×I×Hio→Hsec表示协商管道信息安全传输机制.且有 N=Ninfo×Nio×Nsec.

定义 7 安全管道

定义 3~6的内容共同构成了安全管道的基本要素,现在给出安全管道的形式化定义,即 H=I×Hio×Hsec×N.hl↔u∈H表示安全机制 ml、mu之间的安全管道.

2.3.3 安全管道的性质上节给出了安全管道的形式化定义,现在结合安全管道所具有的属性,分析安全管道所具有的性质.性质 1 传递丰富的访问请求信息.由定义 3可知,I=R×D×E表示安全管道除了可传递原始的访问请求信息 R×D外,还可以根据安全的需要传递附加信息 E.

性质 2 保证传输信息的安全.安全管道的 Hsec属性能保证传递信息的完整性和机密性,从逻辑上形成一个封闭的管道.

性质 3 访问请求传递的单向性.由定义 3 Iu→l=R×E,Il→u=D可知,访问请求信息只能由上层安全机制单向请求下层安全机制.

2.3.4 TCB扩展步骤

TCB扩展的目标是要构建安全机制之间符合安全需求的管道,因此,其扩展过程要充分结合安全管道的属性而展开.扩展步骤作为 TCB扩展模型的一部分需要进行更具体的描述.

TCB管道扩展可以分为 4个步骤.

步骤 1 可信认证 TCB扩展首先须保证安全机制的可信 可以通过完整性验证机制保证,定义认证函数为 fcert:M→{true,false}.

步骤 2 协商交互内容 函数 fnegoinfo∈Ninfo:Ml×Mu→I用于协商需要通过安全管道交互的内容,比如在下层安全机制缺少应用相关的主体信息的情况下,可通过管道传递相应的主体信息.

步骤 3 协商管道接口 管道信息以何种方式传递也是需要在管道构建之初协商确定的,函数 fnegoio∈Nio:I→Hio用以协商管道接口.

步骤 4 协商通信安全机制 由安全管道的定义可知,安全交互是安全管道的一个基本属性,函数fnegosec∈ Nsec:Ml×Mu→Hsec用以协商通信安全机制.

图2 TCB扩展步骤Fig.2 Steps of TCB extension

定义 8 TCB扩展

扩展函数 ftcbext:M×M→H表示通过 TCB扩展构建安全机制之间的安全管道,有

定义 9 系统 TCB

由定义 2可知,对于安全机制可分为 n层的系统,Ms={m1,m2,…,mn}⊆M,在此定义的 TCB是安全机制加上通过 TCB扩展而得到的安全管道构成,则有

2.3.5 TCB扩展规则

规则 1 安全机制可信规则 TCB扩展在构建安全管道之前,需要对上层安全机制进行可信验证,通过层层可信验证,能保证最终扩展形成的系统 TCB整体的安全可信.

规则 2 自下而上扩展规则 由于系统安全机制具有层次性的特点,因此,TCB扩展模型需遵从自下而上的扩展规则.

规则 3 主体一致性规则 由定义 1可知访问请求 R=S×O×A,通常情况下,客体和操作行为是与当前上下文相关的,底层访问控制机制能获取得到,但是主体信息通常会发生变化,应用层主体信息往往无法传递到操作系统安全机制层.因此,我们在TCB扩展时需遵守主体一致性规则,保证每层都能实施准确的访问控制.

以上描述的安全管道的定义、TCB扩展步骤和扩展规则共同构成了 TCB的扩展模型.

3 模型安全性分析

定理 1 经 TCB扩展模型扩展而得的系统 TCB是可信的.

证明:由定义 9可知,系统 TCB可以定义为:TCB={m1,h1↔2,m2,…,mn-1,hn-1↔n,mn},要证明系统TCB是可信的,需要证明系统 TCB内部各元素是可信的.

首先证明 TCB内安全机制是可信的,由模型的步骤 1可知,TCB内部的所有安全机制 Ms={m1,m2,…,mn}⊆M在扩展过程中都有 fcert(mi)=true,i∈{1,2,…,n}保证,因此,TCB内部安全机制是可信的.

现在证明 TCB内安全管道是可信的,由定义 8可知,hi↔i+1=ftcbext(mi,mi+1),i∈{1,2,…,n},再由上文证明的 Ms={m1,m2,…,mn}⊆M是可信的,且扩展函数是可信的,可得 hi↔i+1,i∈{1,2,…,n}是可信的.

因此,由以上 2点可得经扩展后得到的系统 TCB是可信的.定理 1得证.

定理 2 TCB扩展模型实现应用语义的全程传递.

证明:定理的证明转化为证明与应用相关的访问请求信息 r能无歧义地传递到系统 TCB各层.现假设系统 TCB从下往上可以分为 n层,即 Ms={m1,m2,…,mn},采用本文提出的扩展模型将此 n层安全机制扩展形成有机的系统 TCB,可认为最上层的访问请求是与应用相关的,具有应用的语义,则定理命题可表示为

首先证明 r∈ Rn-1,由 TCB扩展模型规则 3,可知 r∈ In,由定义 4可知 In=In-1,则有 r∈ In-1⇒r∈Rn-1.同理,可证明 r∈ Rn-2,…,r∈ R1.

定理 2得证.

定义 10 问请求可信通路

所谓访问请求可信通路是指资源访问请求能无差别的由发起端传递到最终的请求执行端,包含访问请求信息的完整性和机密性 2层含义.

定理 3 TCB扩展模型能构建资源访问请求的可信通路.

证明:访问请求信息的安全威胁主要体现在安全机制间传递过程中,由定义 5可知

由此可得,安全管道的安全通信属性可以保证信息在管道传递过程中的安全.

定理 3得证.

以上给出了 TCB扩展模型的 3个安全定理,以 2.2节提出的 TCB扩展的安全目标作为依据进行对照分析可知,我们提出的扩展模型可以实现其预定的安全目标.

4 结束语

本文针对当前系统安全机制间互相独立、存在冲突等问题,提出通过 TCB扩展解决此类问题的一般方法,即基于安全管道的 TCB扩展模型.对扩展模型的论证分析说明了模型的科学性和现实可行性.本文给出的扩展模型只是说明TCB扩展的一般步骤,至于 TCB扩展模型所涉及到的用于构建安全管道的几个协议,需要更深入的研究.本文所针对的无论是应用层还是系统层的安全机制都可自主修改.对于安全机制无法修改的情况,如何实施 TCB的扩展也是下一步需要研究的内容.

[1]MOHAN C.Survey of recent operating systems research,designs and implementations[J].ACM SIGOPS Operating Systems Review,1978,12(1):53-89.

[2]KRISTAL T P,SCOTT A B.Efficient access control for distributed hierarchical file systems[C]∥Proceedings of the 22nd IEEE/13th NASA Goddard Conference on Mass Storage Systems and Technologies.Washington DC,USA:IEEE Computer Society,2005:253-260.

[3]卿斯汉,刘文清,温红子.操作系统安全[M].北京:清华大学出版社,2004:234-256.

[4]沈昌祥.构建积极防御综合防范的防护体系[J].信息安全与通信保密,2004,41(5):18-20.SHEN Chang-xiang.Build up protection system of active defense and comprehensive on-guard[J].China Information Security,2004,41(5):18-20.(in Chinese)

[5]PHILLIPS L.Windows Vista security:first impressions[J].Information Security Tech Report,2006,11(4):176-185.

[6]MICHAEL H,STEVE L.Inside the Windows security push[J].IEEE Security and Privacy,2003,1(1):57-61.

[7]NIK O.Overview of Windows NT security subsystem[J].Sys Admin,1998,7(7):8-16.

[8]BOB R.Inside Windows NT security[J].Windows/DOS Developer's Journal,1993,4(4):6-19.

[9]MICK B.Paranoid penguin:introduction to SE Linux[J].Linux Journal,2007,2007(154):1-15.

(责任编辑 张 蕾)

Channel-Based TCB Extension Model

LIAO Jian-hua1,3,ZHAO Yong2,SHEN Chang-xiang2
(1.School of Electronics Engineering and Computer Science,Peking University,Beijing 100871,China;2.College of Computer Science,Beijing University of Technology,Beijing 100124,China;3.State Key Laboratory of Information Security,Institute of Software,Chinese Academy of Sciences,Beijing 100049,China)

To solve the problems derived from isolation of application security mechanism and operation system security mechanism,firstly,the concept of security channel and TCB extension was p roposed,and then formal description of security channelwasgiven.By practices,a TCB extension modelwhich based on security channel was obtained.This model could be used to explain how to build security channel between different security mechanisms in order to achieve uniform and eliminate conflicts of those security mechanisms.Finally the theory and practicality of thismodel with security analysis and engineering implementation were proven.

TCB extension;security channel;application security mechanism;operation system security mechanism

TP 309

A

0254-0037(2010)05-0592-05

2009-12-10.

国家“八六三”计划资助项目(2009AA 01Z437);国家“九七三”计划资助项目(2007CB311100);信息安全国家重点实验室开放课题.

廖建华(1978—),男,江西宁都人,博士研究生.

猜你喜欢
下层访问控制协商
Multi-Agent协商中风险偏好的影响研究
一种跨策略域的林业资源访问控制模型设计
折叠积雪
发挥社会主义协商民主重要作用
云的访问控制研究
从“古运河的新故事”看提案办理协商
云计算访问控制技术研究综述
积雪
协商民主的生命力在于注重实效
有借有还