构建安全系统的安全模型方案

安全模型是对安全策略所表达的安全需求的简单、抽象和无歧义的描述，它为安全策略和安全策略实现机制的关联提供了一个框架。安全模型描述了对某个安全策略需要用哪种机制来满足，而模型的实现则描述了如何把特定的机制应用于系统中，从而实现某一特定安全策略所需的安全保护。

J.P.Anderson指出要开发安全系统首先必须建立系统的安全模型。安全模型给出了安全系统的形式化定义，并且正确地综合系统的各类因素。这些因素包括系统的使用方式、使用环境类型、授权的定义、共享的客体（系统资源）、共享的类型和受控共享思想等。构成安全系统的形式化抽象描述，使得系统可以被证明是完整的、反映真实环境的和逻辑上能够实现程序的受控执行的。

安全模型的目的在于明确地表达上述需求，为设计开发安全系统提供方案。

安全模型有以下几个特点：

●它是精确的、无歧义的。

●它是简易和抽象的，容易理解。

●它是一般性的，只涉及安全性质，而不过度地牵涉系统的功能或其实现。

●它是安全策略的明显表现。

安全模型一般分为两种：形式化的安全模型和非形式化的安全模型。非形式化的安全模型仅模拟系统的安全功能；形式化的安全模型则使用数学模型，精确地描述安全性及其在系统中使用的情况。

图4-2 安全模型与安全操作系统开发过程

如图4-2所示，对于高安全级别的操作系统，尤其是对那些以安全内核为基础的操作系统，需要用形式化的开发路径来实现。这时安全模型就要求是运用形式化的数学符号来精确表达。形式化的安全模型是设计开发高级别安全系统的前提。如果是用非形式化的开发路径，修改一个现有的操作系统以改进它的安全性能，则只能达到中等的安全级别，即使如此，编写一个用自然语言描述的非形式化的安全模型也是很值得的，因为安全模型可以保证当设计和安全模型一致时，实现的系统是安全的。

为满足简易性，模型仅仅只需模拟系统中与安全相关的功能，同时可以省略系统中其他的与安全无关的功能，这也是系统安全模型和形式化功能规范之间的差别，相比较而言，形式化功能规范包括了过多的与安全策略无关的系统功能特征。

1.形式化安全模型设计

完成安全系统的建模后，再进行安全内核的设计和实现。

形式化安全策略模型设计要求人们不仅要建立深刻的模型设计理论，而且要发掘出具有坚实理论基础的实现方法。为了模型的形式化，必须遵循形式设计的过程及表达方式。

Bell把安全策略划分为4个层次，而Lapadula则把模型设计分为5个层次，前者说明策略在系统设计的不同阶段的不同表现形式，强调策略发展的逻辑过程；后者说明模型在系统设计的不同阶段的不同功能要求，强调模型对象的逻辑联系。因为模型对象必须通过执行策略才能形成一个有机的模型整体，而且随着模型在不同层次的发展，模型对象执行策略的表现形式必将不同，因此二者是相辅相成的。但它们也仅仅是指明了模型与策略设计的逻辑过程，并不关心这些逻辑过程的实现，因为主要意图在于对现有工作进行分类总结。面对一个具体的设计，实现显然是重要的。美国国防部的彩虹序列中的“对理解可信系统中安全模型的指导”（A Guide To Understanding Security Modeling in Trusted System），提出了指导实现的一般性步骤，这些步骤明显受Lapadula对模型设计的5个层次的划分的影响。下面分析这些步骤与模型层次的关系：

1）确定对外部接口的要求（Identify Reguirements on the External Interface）。这一步主要明确系统主要的安全需求，并把它们与其他问题隔离开。这些需求将足以支持已知的高层策略对象—可信对象，因此这一步可以说主要是给出系统安全的确切定义，提出支持可信对象的各种条件及描述安全需求的各种机制和方法，构造一个外部模型。

2）确定内部要求（Identify Internal Requirements）。为了支持已确定的外部需求，系统必须对系统的控制对象进行限制，这些限制往往就形成了模型的安全性定义。这一步实质上就是把安全需求与系统的抽象进行结合，提出合理的模型变量，构造一个内部模型。

3）为策略的执行设计操作规则（Design Rules of Operation for Policy Enforcement）。系统实体为获得安全限制必须遵循一定的操作规则，也就是说把安全策略规则化，以确保系统在有效完成系统任务的同时，系统始终处于安全状态中。这里有一个非常值得注意的问题，就是Mclean在1987年提出的完备性问题：一个安全状态可以经由一个安全操作进入下一个安全状态，也可能经由一个不安全操作进入下一个安全状态，也就是说，安全操作只是确保系统的状态始终处于安全状态的充分条件，如果系统设计得不完备，从一个安全状态进入下一个安全状态时完全可以规避安全操作，这一步对应了Lapadula层次划分的操作规则层次。

4）确定什么是已经知道的（Determine What Is Already Known）。对于高安全等级操作系统的安全模型的设计必须是形式化的，而且是可形式验证的，因此必须选择适当的形式规范语言，开发相应的形式验证工具，看看是否有可直接使用或进行二次开发的形式验证工具，尽量优化设计开发过程。

5）论述一致性和正确性（Demonstrate Consistency and Correctness）。这一步可以说是模型的评论（Review）阶段，具体到操作系统的安全模型的设计，主要内容应该包括：安全需求的表达是否准确、合理；安全操作规则是否与安全需求协调一致；安全需求是否在模型中得到准确反映；模型的形式化与模型之间的对应性论证等。

6）论述关联性（Demonstrate Relevance）。这一步可以说是模型的实施阶段，它对应Lapadula层次划分的功能设计层次。许多著名的系统设计（如SCOMP、Multics、ASOS等）都把它称为模型在系统中的解释（Interpretation），也有人把它称为模型实现。论述关联性应分层次进行，首先是实现的模式，其次是实现的架构，接着是模型在架构里的解释，最后是实现的对应性（Correspondence）论证。

2.状态机模型原理

在现有技术条件下，安全模型大都是以状态机模型作为模拟系统状态的手段，通过对影响系统安全的各种变量和规则的描述和限制，确保系统处于安全状态。这里首先简述状态机模型的原理，然后介绍几种主要的安全模型。

状态机模型最初受到欢迎，是由于它们用模仿操作系统和硬件执行过程的方法描述了计算机系统，它将一个系统描述为一个抽象的数学状态机器。在这样的模型里，状态变量表示机器的状态，转换函数或者操作规则用以描述状态变量的变化过程，它是对系统应用通过请求系统调用从而影响操作系统状态的这一方式的抽象。这个抽象的操作系统具有正确描述状态可以怎样变化和不可以怎样变化的能力。

其实，将一个系统模拟为状态机的思想很早就出现了，但是状态机模型在软件开发方面并没有得到广泛的应用，问题就在于在现有软、硬件技术水平下，模拟一个操作系统的所有状态变量是非常困难的，也可以说是不可能的。由于安全模型并未涉及系统的所有状态变量和函数，它仅仅涉及数目有限的几个与安全相关的状态变量，这使得在用状态机来模拟一个系统的安全状态变化时，不至于出现如同在软件开发中不得不面临的、由于状态变量太多而引发的状态爆炸问题，所以状态机模型在系统安全模型中得到了较为广泛的应用，它可以比较自如地模拟和处理与安全相关的各种变量和函数。(www.xing528.com)

开发一个状态机模型包含确定模型的要素（变量、函数和规则等）和安全初始状态。一旦证明了初始状态和所有的函数都是安全的，精确的推导会表明此时不论调用这些函数中的哪一个，系统都将保持在安全状态。

开发一个状态机模型要求采用如下特定的步骤：

1）定义与安全相关的状态变量。状态变量表示了系统的主体和客体、它们的安全属性以及主体与客体之间的存取权限。

2）定义安全状态的条件。这个定义是一个不变式，它表达了在状态转换期间状态变量的数值所必须始终保持的关系。

3）定义状态转换函数。这些函数描述了状态变量可能发生的变化，有时也被称为操作规则，因为它们的意图是限制系统可能产生的类型，而非列举所有可能的变化。系统不能以函数不允许的方式修改状态变量。

4）检验函数是否维持了安全状态。为了确定模型与安全状态的定义是否一致，必须检验每项函数。如果系统在运行之前处于安全状态，那么系统在运行之后仍将保持在安全状态。

5）定义初始状态。选择每个状态变量的值，这些值模拟系统在最初的安全状态中是如何启动的。

6）依据安全状态的定义，证明初始状态安全。

3.主要安全模型介绍

本书介绍具有代表性的BLP模型、Biba模型和RBAC模型。此外，Clark-Wilson完整性安全模型、信息流模型、DTE安全模型和无干扰安全模型等不再赘述。

（1）BLP模型

BLP模型（Bell-Lapadula模型）是D.ElliottBell和LeonardJ.Lapadula于1973年提出的一种适用于军事安全策略的计算机操作系统安全模型，它是最早、最常用的计算机多级安全模型之一。

在BLP模型中，将主体定义为能够发起行为的实体，如进程；将客体定义为被动的主体行为承担者，如数据和文件等；将主体对客体的访问分为R（只读）、W（读写）、A（只写）、E（执行）及C（控制）等几种模式，其中C（控制）是指该主体用来授予或撤销另一主体对某一客体的访问权限的能力。BLP模型的安全策略包括两部分：自主安全策略和强制安全策略。自主安全策略使用一个访问矩阵表示，访问矩阵第i行第j列的元素M_ij表示主体S_i对客体Oj的所有允许的访问模式，主体只能按照在访问矩阵中被授予的对客体的访问权限对客体进行相应的访问。强制安全策略包括简单安全特性和*（星）特性，系统对所有的主体和客体都分配一个访问类属性，包括主体和客体的密级和范畴，系统通过比较主体与客体的访问类属性控制主体对客体的访问。

BLP模型是一个状态机模型，它形式化地定义了系统、系统状态以及系统状态间的转换规则；定义了安全概念；制定了一组安全特性，以此对系统状态和状态转换规则进行限制和约束，使得对于一个系统而言，如果它的初始状态是安全的，并且所经过的一系列规则转换都保持安全，那么可以证明该系统的终止也是安全的。

随着计算机安全理论和技术的发展，BLP模型已不足以描述各种各样的安全需求。应用BLP模型的安全系统还应考虑以下问题：

●在BLP模型中，可信主体不受*特性约束，访问权限太大，不符合最小特权原则，应对可信主体的操作权限和应用范围进一步细化。

●BLP模型注重保密性控制，控制信息从低安全级传向高安全级，缺少完整性控制，不能控制“向上写”（Write Up）操作，而“向上写”操作存在着潜在的问题，它不能有效地限制隐蔽信道。

（2）Biba模型

BLP模型通过防止非授权信息的扩散保证系统的安全，但它不能防止非授权修改系统信息，于是Biba等人在1977年提出了第一个完整性安全模型——Biba模型，其主要使用类似BLP模型的规则来保护信息的完整性。Biba模型也是基于主体、客体以及它们的级别的概念的。模型中主体和客体的概念与BLP模型相同，对系统中的每个主体和客体均分配一个级别，称为完整级别。每个完整级别均由两部分组成：密级和范畴。其中，密级是如下分层元素集合中的一个元素：{极重要（Crucial）（C），非常重要（Very Important）（VI），重要（Important）（I）}。此集合是全序的，即C＞VI＞I。范畴的定义与BLP模型类似。

基于Biba模型的完整性存取控制方案认为，在一个系统中，完整性策略的主要目标是用以防止对系统数据的非授权修改，从而达到对整个系统数据完整性进行控制的目的，对于职责隔离目标，则是通过对存取类的恰当划分来实现的。Biba完整性模型努力去实现与Bell和Lapadula所定义的机密性分级数据安全相类似的完整性分级数据安全。Biba定义了一个与BLP模型完全相反的模型，在Biba模型中，声称数据项存在于不同的完整级上，文件的完整性级别标签确定其内容的完整性程度，并且系统应防止低完整级的数据“污染”高完整级的数据，特别是一旦一个程序读取了低完整级数据，系统就禁止其写高完整级的数据。

Biba模型的优势在于其简单性以及和BLP模型相结合的可能性。Biba模型的不足之处为：完整标签确定的困难性；在有效保护数据一致性方面不充分。Biba模型仅在Multics和VAX等少数几个系统中实现。因此，无论是依据Biba模型来有效实现系统完整性存取控制，或者把完整性和机密性相结合方面，Biba模型都难以满足实际系统真正的需求。

（3）RBAC模型

RBAC（基于角色的存取控制）模型提供了一种强制存取控制机制。在一个采用RBAC作为授权存取控制的系统中，根据公司或组织的业务特征或管理需求，一般要求在系统内设置若干个被称为“角色”的客体，用以支撑RBAC授权存取控制机制的实现。所谓角色，用普通业务系统中的术语来说，就是业务系统中的岗位、职位或者分工。例如，在一个公司内，财会主管、会计、出纳、核算员等每种岗位都可以设置多个职员具体从事该岗位的工作，因此它们都可以被视为角色。

在一个采用RBAC机制作为授权存取控制机制的系统中，由系统管理员负责管理系统的角色集合和存取权限集合，并将这些权限（不同类别和级别）通过相应的角色分别赋予承担不同工作职责的终端用户，而且还可以随时根据业务的要求或变化对角色的存取权限集和用户所拥有的角色集进行调整，这里也包括对可传递性的限制。

在RBAC系统中，要求明确区分权限（Authority）和职责（Responsibility）这两个概念。例如，在有限个保密级别的系统内，访问权限为0级的某个用户，就不能访问保密级别为0的所有资源，此时0级是该用户的权限，而不是他的职责。又如，一个用户或操作员可能有权访问资源的某个集合，但是不能涉及有关授权分配等工作；而一位主管安全的负责人可以修改访问权限，可以分配授权给各个操作员，但是不能同时具备访问/存取任何数据资源的权限，这就是他的职责。这些职责之间的不同是通过不同的角色来区分的。

RBAC的功能相当强大，适用于许多类型（从政府机构办公到商业应用）的用户需求。Netware、WindowsNT、Solaris和Selinux等操作系统中都采用了类似的RBAC技术作为存取控制手段。