第 5 章 可信操作系统的设计

本章要点 什么使得一个操作系统“安全”或者

“值得信赖” 如何设计可信系统，及在这些设计原

则中，有哪些设计准则可以应用于其他程序开发任务中

我们如何促进对可信操作系统的正确性的保障

如果一个操作系统能够稳定而有效地提供内存保护、文件保护、一般对象的访问控制、用户鉴别 4 种服务，那么我们就说它是可信的 (trusted) 。

本章将从设计者的角度来观察一个可信操作系统的设计以及提供安全服务的组件功能。

本章将讨论可信系统的 4 个主要方面： 策略：操作系统的安全需求是一个被良好定义

的、一致且可实现的规则集，而且这些规则能被非常清楚并且无二义性地表达出来。为了保证需求是清楚、一致和有效的，操作系统通常会遵循一个预先规定好的安全策略——一个规则集，它展示了将要保护什么，以及为什么要保护。

模型：设计者通常先为需要保护的环境构建一个模型，这个模型实际上体现了系统将要实施的策略。设计者将模型和系统需求进行比较，以保证整个系统功能不会因为安全需求的引入而失效或降低。

设计：在确定了一个安全模型之后，设计者开始选择实现模型的方法。因此，设计包含两方面的内容：什么是可信操作系统 ( 可信操作系统要实现的功能 ) ，以及怎样去构造( 即实现 ) 它。

信任：我们对一个系统的信任基于两个方面：特征 ( 操作系统包含了实施安全策略所必需的全部功能 ) 和保障 ( 操作系统的实现方式使我们确信它能够正确有效实施安全策略 ) 。

# 一些安全系统最初就是针对安全需求而设计的，另一些安全系统则是将安全特性加入到现有的操作系统中。两种方法建立可信操作系统都是可行的。

5.1 什么是可信系统 如果代码被严格地开发和分析，使我们有理

由相信代码只做其被要求做的，那么我们就说这个软件是可信软件 (trusted software) 。一般来说，可信代码能够作为其他不可信代码的运行基础。也就是说，不可信系统的质量部分地依赖可信代码；可信代码是构建整个系统安全的基础。特殊的，当我们确信操作系统能够对运行在它上的组件或系统的访问进行正确控制，就可以认为它是可信的。

5.1 什么是可信系统 ( 续 )

要相信一个软件，必须对其进行严格测试分析，找到某些关键特性：

功能的正确性：程序按预期正确执行。 保持完整性：即使出现错误也能维持与其交

互的数据正确。 有限的特权：允许访问安全数据，但这种访

问是最小化的。 适合的可信级别：根据使用的数据和环境，

对程序进行检查并给出适当的信任评级。

5.1 什么是可信系统 ( 续 )

安全专家喜欢说“可信操作系统”而不是“安全操作系统”。可信操作系统是指这个系统不但达到了设计时的安全要求，质量很高，而且能证明用户对系统质量的信任是正确的。也就是信任是由系统的接收者或使用者来体会的，作为用户，你或许不能够直接评价一个系统是否值得信任。你可能会相信设计方案，可能会相信专家的评估，也可能相信同事的意见。但最终，还得由你自己来确定所需要的信任度。

5.1 什么是可信系统 ( 续 )

信任度非常重要。与安全不同，信任不是一个互斥的概念。信任通常随着时间的推移而增加，其程度与证据和经历有关。

表 5.1 安全和可信的性质比较

5.1 什么是可信系统 ( 续 )

可信操作系统还涉及以下几个概念： 可信进程 (trusted process) ：能够影响系统

安全的进程，或者说这个进程的不正确执行或恶意执行会破坏系统安全策略。

可信产品 (trusted product) ：经过评估和认可的产品。

可信软件 (trusted software) ：系统赖以实施安全策略的软件部分。

5.1 什么是可信系统 ( 续 )

可信计算基 (trusted computing base) ：计算机系统内所有保护机制的集合，包括硬件、固件和软件，它们一起对产品或系统实施了统一的安全策略。

可信系统 (trusted system) ：该系统使用了充分的硬件和软件完整性措施，能够处理敏感信息。

# 与这些概念相关的概念是： 安全策略实施、足够的措施和机制、评估。

5.2 安全策略 5.2.1 军事安全策略 军事安全策略是很多可信操作系统的基础，

而且很容易对其进行精确描述。军事安全策略 (military security policy) 是基于保护机密信息的策略。每条信息被标识为一个特定敏感等级，如不保密的、受限制的、秘密的、机密的、绝密的。这些等级构成了一个层次结构。我们用符号 rankO 表示对象O 的敏感度。

5.2.1 军事安全策略 ( 续 )

图 5.1 敏感度的层次结构

5.2.1 军事安全策略 ( 续 )

我们使用须知 (need-to-know) 原则来限制访问：只有那些在工作中需要知道敏感数据的主体才允许访问相应的敏感数据。每条机密信息都与一个或更多的项目相关，这些项目称做分隔项 (compartments) 。分隔项使人们只能访问那些与他们工作相关的信息，一个分隔项可以属于一个敏感级也可以属于多个敏感级。

5.2.1 军事安全策略( 续 )

图 5.2 分隔项和敏感等级# 可以通过指定名字来区分分隔项。单独一条信息可以不赋予分隔项名，也可以被赋予一个、两个或多个，这取决与信息的属性。

5.2.1 军事安全策略 ( 续 )

图 5.3 信息与分隔项的联合

5.2.1 军事安全策略( 续 )

<等级；分隔项 > 的组合被称为信息片断的类(class) 或分类 (classification) 。通过以这种方式指定信息，我们就能够用安全等级和主题来实施须知原则。用户必须得到许可 (clearance)才能够访问敏感信息。许可表明可以信赖某人访问某个级别以下的敏感信息，以及此人需要知道某些类的敏感信息。我们用组合 <等级；分隔项 > 来表示对主体的许可。

5.2.1 军事安全策略 ( 续 )

由此，我们可以建立在敏感对象和主体集合上，称为支配 (dominance) 的关系“≤”。对于一个主体 s 和一个对象 o ：

一个主体可以读一个对象，如果： (1) 主体的许可等级至少和访问信息的敏感等级一样高；

(2) 主体需要知道该信息分类时涉及的所有分隔项。

5.2.1 军事安全策略 ( 续 )

军事安全同时实施了敏感度要求和须知要求。我们知道，敏感度是层次化 (hierarchical) 的要求，因为它们反映了敏感等级层次结构；而须知限制是非层次化 (nonhierarchical) 的，因为分隔项不需要表现为一个层次结构。许可和分类通常由一些称为安全职员的人控制，而并不是个人能够随意改变的。这个策略非常适合通过权威中心进行严格访问控制环境。

5.2.2 商业安全策略 商业企业也非常关心安全问题。因此，即使商业界不像军事领域那样严格苛刻和层次化，在商业安全策略中仍然会发现许多与军事策略相同的概念。分属不同部门的数据项也具有不同的敏感度，例如，公共的、专有的或内部的。当然，这里并没有一个通用的层次结构。我们可以假设公共信息不如专有信息敏感，而专有信息又不如内部信息敏感。

5.2.2 商业安全策略 ( 续 )

图 5.4 敏感信息的商业观点

5.2.2 商业安全策略 ( 续 )

商业信息安全和军事信息安全有两个很显著的区别。

(1) 商业与军事不同，通常没有正式的“许可”概念；从事商业项目的人不需要得到中心安全职员的正式批准就可以访问项目。典型的，在允许一个雇员访问内部数据之前不需要对其授予不同的信任度。

(2) 由于没有正式的“许可”概念，所以允许访问的规则不太规范。

因此，对于大多数商业信息访问不存在一个支配函数，因为没有正式的“商业许可”概念。

5.2.2 商业安全策略 ( 续 )

前面的讨论主要集中在机密性问题上。然而，完整性和可用性在许多情况下和机密性至少是同等重要的。通过下面的几个例子探讨完整性。

(1) Clark-Wilson 商业安全策略 Clark 和 Wilson 为他们所称的良构事务 (we

ll-formed transactions) 提供了一个策略。为了明白其中的原因，考虑这样一个例子：一家公司预定货物，然后付款。典型的流程如下：

5.2.2 商业安全策略 ( 续 )

(A) 采购员先做一张货物订单，并把订单同时发给供货方和收货部门。

(B) 供货方将货物运到收货部门。收货部门的接收员检查货物，确保收到货物的种类和数量是正确的，然后再送货单上签字。再将送货单和原始订单交给会计部门。

(C) 供货方将发票送到会计部门。会计人员将发票同原始订单进行校对 (校对价格和其他条款 ) 并将发票同送货单进行校对 (校对数量和品种 ) ，然后开支票给供货方。

5.2.2 商业安全策略 ( 续 ) 在大多数实例中，订单和送货单都需要有某个授权的人员来签订。委任专人按顺序准确执行以上步骤，就构成了一个良构事务。 Clark-Wilson 策略的目标是使内部数据与其外部 ( 用户 ) 期望保持一致。 Clark 和 Wilson 用约束数据项 (constrained data item)来表达他们的策略，受约束数据项由转变程序 (transformation procedure) 进行处理。转变程序就像一个监控器，对特定种类的数据项执行特定的操作，确认特定操作已经执行来维持数据项的完整。 Clark 和 Wilson 将这个策略定义为访问三元组 (access triple) ： userID ， TPi ， CDIj ， CDIk ，… ，通过它将转变程序、一个或多个受约束数据项以及用户识别结合起来，其中用户是那些已被授权且以事务程序的方式操作数据项的人。

5.2.2 商业安全策略 ( 续 )

(2) 职责分离 还是上面的那个订货的例子，我们希望建

立一个策略，这个策略能够明确规定三个不同的人分别发送订单、接收货物和开支票，这种需求被称做职责分离 (separation of duty) 。由于访问三元组是“无状态的”，无法实现职责分离，但如果将它作为一个策略需求表述出来，上述限制是容易实现的。

5.2.2 商业安全策略 ( 续 )

(3) 中国墙安全策略 Brewer 和 Nash 定义了一个名为中国墙 (Chine

se Wall) 的安全策略，用于反映商业信息访问保护中的利益冲突问题。

安全策略建立在三个抽象等级上。 (A) 对象：位于最低等级，比如文件。每个文

件只包含一家公司的信息。 (B) 公司群体：位于第二个等级，由与一家特

定公司相关的所有对象组成。 (C) 冲突类：位于最高等级，相互竞争的公司

的所有对象聚集。

5.2.2 商业安全策略 ( 续 )

假设一家广告公司，存储了巧克力公司 Suchard 和 Cadbury ，银行 Citicorp 、 Deutsche Bank 和 Credit Lyonnais ，以及航空公司 SAS的数据。广告公司希望其雇员不能从这些信息中牟利。运用中国墙等级结构形成三个冲突类： {Suchard ， Cadbury} ， {Citicorp ，Deutsche Bank ， Credit Lyonnais} 和 {SAS} 。这个结构可以导出一个简单控制策略：如果被访问的对象所属的公司群体中的某个对象已被访问过，或者这个对象所属的冲突对象从未被访问过，那么就允许访问该对象。

5.2.2 商业安全策略 ( 续 )

图 5.5 中国墙安全策略

5.2.2 商业安全策略 ( 续 )

中国墙策略在商界中是非常有名的机密策略。中国墙策略注重完整性。它的访问许可可以动态变化：当一个主体访问某些对象后，就不能够访问先前可以访问的这一类中的其他对象了。

5.3 安全模型 我们常常用模型来描述、研究或者分析一个

特定的情况或者关系。 Mclean 给出了安全模型的一个良好概述。安全模型用于：

(1) 检测一个特定策略的完善性和一致性。 (2) 对策略进行验证。 (3) 有助于构思和设计一个实现。 (4) 检测一个实现是否满足需求。 安全需求是由策略决定的，而模型仅仅是实

施策略的一种机制。

5.3.1 多极安全 在理想情况下，我们希望建立一个模型能够

表示一系列的敏感度，同时能够反映这样一个需求，即将主体同它们不能访问的对象严格地隔离开。这种一般化的模型被称为安全性的格模型 (lattice model) ，因为它的元素构成了一种被称为格的数学结构。

5.3.1 多极安全 ( 续 ) 格是通过关系运算符 (relational operator) 来组织元素的一种数学结构。用符号“≤”或“≥”来表示这种关系。当元素之间有传递关系和反对称关系时，该关系称为偏序 (partial ordering) 。也就是对于任意三个元素 a ， b 和 c 有：

传递性：若 a≤b 且 b≤c ，则 a≤c

反对称性：若 a≤b 且 b≤a ，则 a=b

在一个格中并不需要任意两个元素都可以比较。但是每个元素都应该有个上界。也就是说即使 a 和 b没有可比性，也存在一个上界元素 u ，使得 a≤u 和b≤u 。进一步，格中每个元素还应该有一个下界。

5.3.1 多极安全 ( 续 )

数字 60 的所有因子构成格。

图 5.6 格的实例

5.3.1 多极安全 ( 续 )

格可以帮助我们描述关系。但是，许多典型的关系都只能表示成半格。在“小于”、“是其子非空集”、“报告于 ( 对于雇员 )” 或者“是一个后续”这些关系中，都有一个唯一的上界 ( 比如，一个共同的祖先 )，但是可能任何一对元素都没有一个下界。

5.3.1 多极安全 ( 续 )

访问安全的格模型 军事策略中定义的支配关系“≤”就是格的

关系。格中最大的元素是分类 <绝密；所有分隔项 > ，最小的元素是 < 不保密；无分隔项 > 。商业安全策略中的数据敏感度分为公共的、专用的和内部的，并按自然排序为：公共数据没有专用数据敏感，而专用数据没有内部数据敏感，这也构成格。

因为格是递增顺序的一种自然表示，所以被选作安全系统的基础。敏感等级的格表示被应用于很多计算场合。

5.3.1 多极安全 ( 续 )

Bell-La Padula 机密模型 Bell-La Padula机密模型的目标是识别出对维

持保密性至为重要的允许通信。该模型已经用来定义那些并发处理不同敏感等级数据的系统安全需求。该模型是军事安全策略的形式化结果。我们对安全信息流感兴趣，是因为它描述了处于不同敏感等级的主体和对象之间可接受的连接。安全等级分析的一个目的是为了构建一个系统，此系统能够对处于两个不同敏感等级上的数据执行并行计算。

5.3.1 多极安全 ( 续 )

系统包含了主体集 S 和对象集 O ， S 中的每一个主体 s 和 O 中的每一个对象 o 都有一个固定的安全类 C(s) 和 C(o) 。安全类按关系“≤”排序。安全信息流有两个特性：

简单安全特性：仅当 C(o)≤C(s) ，主体 s才可以对于对象 o “ ”有 读 访问权。

*- 特性 ( 称作“开始特性” ) ：对于对象 o 行使了“ ”读 访问权的主体，仅当 C(o)≤C(p) ，才可能对于对象 p 有“ ”写 访问权。

5.3.1 多极安全 ( 续 )

解释 (1) 在军事模型中，简单安全特性是说信息接收者的安全等级 ( 许可 ) 不可低于信息的安全等级。

(2) *- 特性是说得到某个等级信息的人只能将这条信息传递给那些等级不低于这条信息等级的人。 *- 特性是用来防止“下写” (write-down) ，当一个能够访问高级别数据的主体通过“写”将数据传递给低级别对象时便会发生这种情况。

5.3.1 多极安全 ( 续 )

图 5.7 安全信息流

# 仅当对较高级别信息有访问权的主体不传送任何敏感数据给低级敏感对象时，向下的流才是可接受的。

5.3.1 多极安全 ( 续 )

Biba 完整性模型 数据的完整性也很重要， Biba 定义了“完

整性等级”。对象和主体依据一个完整性分类方案来排序，分别用 I(s) 和 I(o) 表示。特性为：

简单安全特性： 主体 s 能够修改 ( 有权“ ”写 ) 对象 o仅当 I(s)≥I(o) 。

完整性 *- 特性：如果主体 s “ ”有权 读 具有完整性等级 I(o) 的对象 o ，则仅当 I(o)≥I(p)时， s “ ”有权 写 对象 p 。

5.3.1 多极安全 ( 续 )

解释 这两条规则自然包含对不可信信息的处理情况。一个不可信主体对于对象拥有写访问权会降低对象的完整性。类似的，人们有理由怀疑一份依据不确切证据作出的报告。源对象的低完整性意味着对于任何基于它的对象的完整性都很低。

5.3.2 安全系统在证明理论模型上的局限 模型对于说明方法的可行性非常有用。考虑一个系统应具有的安全特性，我们希望建立一个模型，能 ( 在系统设计、编码和测试之前 )告诉我们是否能真正获得这些特性。基于计算理论的模型可以帮助我们回答这些问题。

5.3.2 安全系统在证明理论模型上的局限( 续 )

Graham-Denning 模型 Graham-Denning 模型对主体集合 S ，对象集合 O ，权限集合 R 和访问控制矩阵 A 进行操作。对每一个对象，标明为“拥有者”的主体拥有特殊权限；对每一个主体，标明为“控制者”的另一个主体也拥有特殊权限。

在 Graham-Denning 模型中，有 8 种基本的保护权。这些权限被表示为主体能够发出的命令，作用于其他主体或对象。 这实际给出一个保护系统的访问控制机制模型所必需的特性。

5.3.2 安全系统在证明理论模型上的局限( 续 )

(1) 创建对象：允许主体引入新对象。 (2) 创建主体、删除对象以及删除主体：效果与创

建或销毁一个主体或对象相似。 (3) 读访问权：允许一个主体确定一个主体对一个

对象或主体当前访问权。 (4) 授予访问权：允许拥有者把对象的任意访问权

交给另一个主体。 (5) 删除访问权：允许一个主体删除另一个主体对

一个对象的权限。 (6) 转移访问权：允许一个主体把它对对象的权限转移给另一个主体。每个权限可以是可转移的，也可以是不可转移的。

5.3.2 安全系统在证明理论模型上的局限( 续 )表 5.2 保护系统的命令命令 前提 效果创建对象 o - 在 A中为 o加一列；拥有者置于 A[x,

o]

创建主体 s - 在 A中为 s加一行；控制权置于 A[x, s]

删除对象 o A[x, o]中的内容是拥有者 删除列 o

删除主体 s A[x, s]中的内容是控制权 删除行 s

s对 o的读访问权 A[x, s]中的内容是控制或 A[x, o]中的内容是拥有者

将 A[s, o]复制到 x

删除 s对 o的访问权 r

A[x, s]中的内容是控制或 A[x, o]中的内容是拥有者

从 A[s, o]删除 r

授予 s对 o的访问权 r

A[x, o]中的内容是拥有者 将 r添加到 A[s, o]中

转移 s对 o的访问权 r

A[x, o]中的内容是 r 将 r添加到 A[s, o]中

访问控制矩阵是 A[s, o] ，其中 s 是主体， o 是对象。用符号 x 表示执行命令的主体， r 是权限。

5.3.2 安全系统在证明理论模型上的局限( 续 )

Harrison-Ruzzo-UIIman 模型 假设将要使用某个操作系统，并且想要知道是否一个给定的用户能被授权进行某种访问。 Harrison-Ruzzo-UIIman 模型 (HRU模型 ) 能够回答这类问题。 HRU 模型是基于命令 (command) 的，其中每条命令含有条件 (condition) 和原语操作 (primitive operation) 。

5.3.2 安全系统在证明理论模型上的局限( 续 )

在 HRU 模型中，每个主体同时也是对象。因此，访问控制矩阵的列表示了所有主体和不是主体的对象。因此，一条命令的所有参数都表示为 o ，尽管它们要么是主体，要么是非主体的对象。每个 op 是一个原语操作。

5.3.2 安全系统在证明理论模型上的局限( 续 )表 5.3 HRU 模型中的访问控制矩阵

对象主体 s1 s2 s3 o1 o2 o3

s1 控制 拥有、挂起、恢复 拥有 拥有 读、传播s2 控制 扩展 拥有s3 控制 读、写 写 读

原语操作 op 包括：创建主体 s 、创建对象 o 、撤消主体 s 、撤消对象 o 、往 A[s, o]输入权限 r 、从A[s, o]撤消权限 r 。一个保护系统 (protection system) 就是由主体、对象、权限和命令组成的集合。 Harrison等人说明，这些足以用于对几种常见保护系统进行建模。

5.3.2 安全系统在证明理论模型上的局限( 续 )

HRU 模型的两个重要结论： (1) 在模型化系统中，当每个命令都被限制

为一个单独的操作时，我们就可能判断出一个给定的主体是否能够获得对一个对象的特殊权限。

由此我们知道，一个低级的主体能否获得对高级对象的读访问权是可以判定的 ( 也就是说，能事先知道 ) 。

5.3.2 安全系统在证明理论模型上的局限( 续 )

(2) 如果不把每条命令限制为单一操作，就不总能判定是否能够将给定的权限授予一个给定的保护系统。

因此，我们并不总能确定一个主体是否可以获得对一个对象的特殊权限。对特殊的保护系统集合可能存在一种算法来判定访问权问题，但不存在适合所有保护系统的访问权问题的判定算法。

5.3.2 安全系统在证明理论模型上的局限( 续 ) 获取 - 授予系统

获取 - 授予系统 (take-grant system) 只有 4个原语操作：创建、撤消、获取和授予。 S表示主体集合， O 表示对象集合。对象要么是主动的 ( 主体 ) 要么是被动的 ( 非主体对象 ) ， R 表示权限集合。用图中的节点表示主体或对象，特定主体对特定对象的权限用一条从主体到对象的有向边表示。

图 5.8 主体、对象和权限

5.3.2 安全系统在证明理论模型上的局限( 续 )

假定 S 为执行操作的主体， 4 个原语操作定义如下： Create(O, r) ：图中增加一个标记为 O 的新节点。 Revoke(O, r) ：撤消 S 对 O 的权限 r 。 Grant(O, P, r) ：主体 S 将对 P 的访问权限 r授予给

O 。主体 S 可以将它在 P 上的访问权授予 O ，当且仅当 S 对 O 有授予权，并且 S 对 P 有访问权限 r 。

Take(O, P, r) ：主体 S 从 O 那里获取 O 对 P 的访问权限 r 。主体 S 能够从 O获取 P 的访问权 r ，当且仅当 S 对 O具有获取权，并且 O 对 P拥有访问权 r 。

5.3.2 安全系统在证明理论模型上的局限( 续 )

图 5.9 创建一个对象；撤消、授予和获取访问权

5.3.2 安全系统在证明理论模型上的局限( 续 )

获取 -授予系统回答了两个问题： (1) 是否能判定一个给定的主体可以和另外

一个主体共享一个对象？ 回答是肯定的，只要其他主体一起拥有对

于对象所期望的访问权，且第一个主体通过具有特定形式的边与其他主体的每一个组相连，共享就可能发生。

5.3.2 安全系统在证明理论模型上的局限( 续 )

(2) 是否能判定一个给定的主体可以从另外一个主体那里窃取对一个对象的访问权？

在严重依赖共享能力的环境中，这个问题的回答也是肯定的。

# 获取 -授予系统假设了用户的最坏情况：如果一个用户能够授予访问权，这个模型就假设用户将会授予。这种最坏情况的假设限制了该模型在控制信息共享环境下的应用。但总的来说，获取 -授权模型是有用的，因为它可以识别出用户能够获得对一个对象访问权的条件。

5.3.3 保护系统模型总结 研究计算机安全模型有两个作用。首先，

在确定一个安全系统应该实施的策略时，模型很重要。其次，对于抽象模型的研究能够引导我们理解保护系统的特性。 对于保护系统的设计者来说，知道这些特性是很重要的。利用保护系统的模型来建立我们的安全策略，并确定什么是可行的和合意的。

5.4 可信操作系统的设计 操作系统本身是很难设计的，将安全的职

能加入到操作系统中大大增加了操作系统设计的难度。软件工程原则告诉我们设计初期就考虑安全因素比在设计末期再考虑更好。我们首先考察标准的多用途操作系统的基本设计。然后，在考虑隔离。通过隔离，操作系统支持用户域的共享和分离。接下来，我们将重点考察操作系统内核的设计；内核的设计方法表明了是否能够有效地提供安全。最后，我们将研究两种不同的内核解析，并考虑分层或环结构化的设计。

5.4.1 可信系统设计元素 安全因素渗透于操作系统的设计和结构中包括两

个方面：首先，一个操作系统控制着主体和对象间的合作，因此，操作系统设计的每一个方面都必须考虑安全性。即操作系统设计必须包括这样一些定义：哪些对象将以什么样的方式被保护，什么样的主体具有访问权，以及这些访问权在什么等级上。其次，由于安全体现在操作系统的每一个部分中，因此，不能到了操作系统的其余部分开始工作和测试的时候，安全的设计和实现都还模糊不清。对一个安全不够完善的操作系统中的安全特性进行改进是极其困难的事情。

5.4.1 可信系统设计元素 ( 续 ) 好的设计原则对于安全十分重要， Saltzer 以及 Saltz

er 和 Schroeder 将这些原则清楚地表达出来： (1) 最少特权：每一个用户和程序都应该通过使用尽

可能少的特权进行操作。 (2) 机制的经济性：保护系统的设计应该小而简单，

且直截了当。 (3) 开放设计：保护机制一定不能依赖于潜在攻击者

的无知；机制应该是公开的，且依赖于相对很少的关键项的保密性，如一个口令。

(4) 完全检查：对每次访问企图都必须进行检查。直接访问的企图和绕过访问检查机制的企图都应该加以考虑，而且检查机制应正确摆放以避免被绕过。

5.4.1 可信系统设计元素 ( 续 ) (5) 基于许可：默认情况下应该是拒绝访问。

稳健的设计者确定那些应该将被访问的项，而不是将不应该访问的项。

(6) 特权分离：理想情况下，对于对象的访问应依赖于多个条件。

(7) 最少公用机制：共享对象为信息流提供了潜在通道，但也带来了风险。

(8) 易用性：如果一个保护系统用起来很简单，那么人们就会使用它。

# 实践表明，在操作系中出现的安全问题都是由于没有遵守这些原则中的一条或者多条而引起的。

5.4.2 普通操作系统的安全特性

图 5.10 操作系统功能概括

5.4.2 普通操作系统的安全特性( 续 )

操作系统完成与安全性相关的几种特殊功能，可以总结如下：

(1) 用户鉴别：操作系统必须识别每一个请求访问的用户，并查明该用户是否与其声称的相符。

(2) 内存保护：每个用户的程序都运行在一个受保护的内存区域中以防止未授权访问。

(3) 文件和输入 / 输出设备访问控制：操作系统必须保护用户、系统文件和设备以防止非授权用户的访问。

5.4.2 普通操作系统的安全特性 ( 续 )

(4) 对一般对象的分配和访问控制：用户需要一般对象，如允许并行和同步的机制。

(5) 共享的实施：资源应该恰当地被用户获取，保证完整性和一致性。

(6) 保证公平服务：所有用户都按期望使用 CPU和其他服务，这样用户就不会产生“饥饿”现象。

(7) 进程间通信和同步：正在运行的进程有时需要和其他进程进行通信，或者需要对共享资源的访问进行同步。

(8) 对操作系统保护数据的保护：操作系统必须维护那些用于实施安全的数据。

5.4.3 可信操作系统的安全特性 可信操作系统集成了一些技术实现可信特征 (featu

re) 和保证 (assurance) 。可信操作系统的设计是精细的，涉及选择一个合适且一致的特性集合以及一个合适等级的保证程度使得特性被正确组合与实现。相对于传统的操作系统，该机制提供了更多的保护和分离。此外，内存也按用户划分，且数据和程序库有可控的共享和分离。

可信操作系统的主要特性包括：用户识别和鉴别、强制访问控制、自主访问控制、对象重用保护、完全检查 、可信路径、审计、审计日志精简、入侵检测。

5.4.3 可信操作系统的安全特性 ( 续 )

图 5.11 可信操作系统的安全功能

5.4.3 可信操作系统的安全特性 ( 续 ) 识别和鉴别 可信操作系统需要安全的个体识别机制，并且所有个

体必须是独一无二的。 强制和自主访问控制 强制访问控制 (MAC ， mandatory access control) 是指访问控制策略的判决不受一个对象的单个拥有者的控制。例子有军事安全中的文件。自主访问控制 (DAC ， discretionary access control) ，顾名思义，留下一些访问控制让对象的拥有者来自主决定，或者给那些已被授权控制对象访问的人。例子有商业应用。

MAC 和 DAC 可同时应用于同一个对象。 MAC 的优先权要高于 DAC ，即在所有具有 MAC 访问许可的人中，只有通过 DAC 的人才能真正被允许访问这个对象。

5.4.3 可信操作系统的安全特性 ( 续 ) 对象重用保护 必须小心控制可重用的对象，以免它们产生严重的缺陷。新文件占用的磁盘空间通常是先前用过、但现在已经释放的空间。这些被释放的空间是“脏”的，也就是说，它仍然包含先前用户的数据。恶意用户会申请大量磁盘空间，然后检查获取其中的敏感数据，这种攻击被称为对象重用 (object reuse) 。 非常精密和昂贵的仪器有时候能够将最近的数据与其先前记录的数据分开，然后再将后者与后者之前的数据分开，以此类推。这种威胁称为磁记忆 (magnetic remanence) 。因此，在任何情况下，操作系统在允许对资源访问之前必须负责清除资源上的信息。

5.4.3 可信操作系统的安全特性 ( 续 ) 完全检查 完全检查 (complete mediation) ，意思就是所

有访问都必须经过检查，而不仅仅限于文件访问控制检查。这样可信操作系统的设计和实现难度就大大增加了。

可信路径 对于关键的操作，如设置密码或者更改访问

许可，用户希望能进行无误的通信，称为可信路径 (trusted path) 。一些操作系统，用户通过输入唯一的键序列请求可信路径，而其他操作系统，通过与安全相关的改变只能在系统启动时进行来保护。

5.4.3 可信操作系统的安全特性 ( 续 )

可审计性和审计 可审计性通常涉及到维护与安全相关的、已发生

的事件日志，即列出每一个事件和所有执行过添加、删除或改变操作的用户。

审计日志精简 (1) 审计日志的观念是吸引人的，但在实际应用中，

由于其容量很大且还需要进行分析，所以对审计日志的处理是非常困难的。如果要为每个读入字符的访问和每条执行指令作审计记录，则审计日志就会非常庞大 (事实上，审计每条指令是不可能的，因为审计命令自身也会被审计，这样就会永无休止 ) 。

5.4.3 可信操作系统的安全特性 ( 续 )

(2) 在大多数操作系统中，只需要在打开或者关闭文件 ( 或类似对象 ) 的时候进行审计，就可以大大简化工作量。但针对文件打开和关闭的审计，在一些情况下可能会造成审计数据太多，而在其他情况下，又可能不足以满足安全需求。

(3) 另一个困难是“海底捞针” 现象。即使审计数据可以限制在一个合理数值，但大量的数据都是合法访问，可能只有一个访问是攻击。进一步，由谁来分析或者做怎样的分析也很重要。是由系统管理员来分析审计日志中的所有数据吗？或者是由开发者写专门程序来分析数据？如果是后者，我们该怎样自动识别出不可接受的行为呢？

5.4.3 可信操作系统的安全特性 ( 续 )

# 一些可信操作系统执行审计精简 (audit reduction) ，用分离工具来精简审计数据的数量。对大多数分析来说，精简审计日志就足够了。

入侵检测 计算机有助于将独立数据联系起来。入侵

检测 (intrusion detection) 软件构造了正常系统使用的模式，一旦使用出现异常就会发出警告。一些可信操作系统包含了一个基本的入侵检测软件。

5.4.4 内核化设计 内核 (kernel) 是操作系统的一部分，执行操

作系统的最底层功能。在标准的操作系统设计中，内核实现这样一些操作，如同步、进程间通信、消息传递以及中断处理。内核也称为核 (nucleus) 或核心 (core) 。

一个安全内核 (security kernel)负责实施整个操作系统的安全机制。安全内核负责在硬件、操作系统、计算系统的其他部分之间提供安全接口。安全内核一般包含在操作系统内核中。

5.4.4 内核化设计( 续 )

将安全功能隔离在安全内核中的原因： (1) 覆盖：对受保护对象的每次访问必须通过

安全内核。 (2) 隔离：通过将安全机制从操作系统的其余

部分和用户空间中隔离出来，易于保护安全机制免遭操作系统或用户的侵入。

(3) 统一：所有的安全功能都由单一的代码集合来执行。这样，追踪由于这些功能引起的任何问题的原因就会容易些。

5.4.4 内核化设计 ( 续 )

(4) 可修改性：易于对安全机制做出修改和对这种改变进行测试。

(5) 紧凑性：由于安全内核只是执行安全功能，所以它相对较小。

(6) 可验证性：由于相对较小，所以安全内核能够被严格地分析。

# 另一方面，实现一个安全内核会降低系统的性能。因为内核在用户程序和操作系统资源之间又添加了另外一层接口。在某些情况下，安全内核可能很大。

5.4.4 内核化设计( 续 )

引用监视器 引用监视器 (reference monitor) ，它控制着

对对象的访问。一个引用监视器不一定是代码，也可以是对设备、文件、内存、进程间通信以及其他种类对象的访问控制的集合。它必须是：

(1) 抗干扰：即不可弱化或使其无效。 (2) 不可绕过：当出现对任何对象的访问请

求时，它总能被激活。 (3) 可分析：由于它足够小，经过测试和分

析，能够确保其完整性。

5.4.4 内核化设计 ( 续 )

图 5.12 引用监视器

# 引用监视器不是可信操作系统中唯一的安全机制。其他安全组件与引用监视器交互，从引用监视器那里接收数据或者为其提供操作数据。

5.4.4 内核化设计 ( 续 )

可信计算基 可信计算基 (TCB ， trusted computing base)

是可信操作系统中用于实施安全策略的所有事物的一个统称。可信计算基由可信操作系统中的正确实施安全策略的部分组成。因此，我们对整个系统的信任建立在 TCB之上。 TCB 必须正确和完整。

5.4.4 内核化设计( 续 )

TCB 是由下列安全实施依赖的系统元素构成的。 (1) 硬件，包括处理器、内存、寄存器和 I/O 设备。 (2) 一些进程概念，以便我们能够分离并且保护关

键的安全进程。 (3) 原始文件，如安全访问控制数据库和识别 / 鉴

别数据。 (4) 受保护的内存，以防引用监视器受到干扰。 (5) 一些进程间通信，以便 TCB 的不同部分能够

相互传递数据并且激活其他部分。例如，引用监视器能够激活并且将数据安全地传递给审计程序。

# 以上五点似乎包含了操作系统的大部分内容，实际上 TCB只是一个很小的子集。

5.4.4 内核化设计 ( 续 )

图 5.13 TCB 和非 TCB 代码

5.4.4 内核化设计 ( 续 )

TCB 必须维护每一个域的保密性和完整性，监视 4 个基本的交互：

(1) 进程激活：在多道程序环境下，进程的激活或钝化是经常发生的。

(2) 执行域切换：在一个域中运行的进程经常会激活其他域的进程以获得更多的敏感数据和服务。

(3) 内存保护： TCB 必须监视内存引用以确保每个域的保密性和完整性。

(4) 输入 / 输出 (I/O) 操作： I/O 操作能够贯穿所有的域。

5.4.4 内核化设计 ( 续 )

将操作系统划分为 TCB 和非 TCB ，这种区分不仅仅是逻辑上的，为了确保非 TCB 代码不会影响安全实施， TCB 代码必须运行在一些可以将其区分开的受保护状态下。因此，应该有意识地创建 TCB 和非 TCB 的结构。这种结构一旦创建， TCB 之外的代码就能够任意修改，只有 TCB 的代码需要小心地控制。划分也简化了评估，因为不需要考虑非 TCB 。

5.4.4 内核化设计( 续 )

安全特性都是融合在具体应用中的，将所有的安全功能都包含在 TCB 中会破坏现有操作系统的模块化。不过，设计者可能将现有操作系统的安全功能隔离出来，从而创建一个安全内核。

5.4.4 内核化设计 ( 续 )

图 5.14 组合的安全内核 / 操作系统

5.4.4 内核化设计 ( 续 )

更为合理的方法是先设计一个安全内核，然后再围绕这个安全内核设计操作系统。在一个基于安全的设计中，安全内核在系统硬件之上形成了一个接口层。安全内核监视着所有操作系统的硬件访问，并执行所有的保护功能。安全内核允许操作系统处理大部分与安全无关的功能。由于这种划分，计算机系统至少具有三个执行域：安全内核、操作系统和用户。

5.4.4 内核化设计 ( 续 )

图 5.15 单独的安全内核

5.4.5 分离 /隔离 对于物理分离 (physical separation) ，要求两

个不同的进程使用不同的硬件设施。当不同进程运行在不同时间的时候就出现时间分离(temporal separation) 。加密用于加密分离 (cryptographic separation) ，所以两个不同的进程能在同一时间运行，是因为未授权用户不能够以可读的形式访问敏感数据。逻辑分离(logical separation) ，也称为隔离 (isolation) ，用于一个进程将一个用户的对象和其他用户的对象分割开。

大多数操作系统将操作系统的一个副本提供给很多用户使用，并以这种方式为所有用户提供单一的环境。

5.4.5 分离 /隔离 ( 续 )

图 5.16 传统多用户操作系统内存

5.4.6 虚拟化 虚拟化 (virtualization) 为可信系统设计者提

供了强有力的支持，允许用户通过可控方式来访问复杂的对象。一个虚拟机 (virtual machine) 是真实的或模拟的硬件设施的集合：一个运行指令集的 ( 中心 )处理器、一定数量的直接编址存储器和一些输入 /输出设备。

真实的资源不一定要与模拟资源完全一致。操作系统向用户提供虚拟资源，安全内核则精确地控制用户的访问。

5.4.6 虚拟化 ( 续 )

多个虚拟内存空间 IBM MVS/ESA 操作系统运行虚拟化提供逻辑分离，给用户造成一个物理分离的印象。通过页面映射机制，将每个用户的逻辑地址空间和其他用户的分开，而使操作系统独立于用户的虚拟地址空间之外。然而，操作系统是每个 MVS/ESA 用户逻辑空间的一部分。

5.4.6 虚拟化 ( 续 )

图 5.17 多重虚拟寻址空间

5.4.6 虚拟化 ( 续 )

MVS/ESA 的一个优点是，每个用户的虚拟内存空间可以与总的可寻址的内存控制一样大。而内存这种表示方法的第二个优点是保护。由于每个用户的逻辑地址空间都包含了操作系统，用户便会感到是在单独的机器上运行，甚至像真的一样。

5.4.6 虚拟化 ( 续 )

虚拟机 IBM 处理器资源 / 管理器 (PR/SM ， Process

or Resources/System Manager) 提供了一个更强的保护，每个用户不仅拥有逻辑内存，而且还拥有 I/O 设备、逻辑文件以及其他逻辑资源。 PR/SM 依靠严格的资源分割来执行这项技术。 PR/SM 系统是虚拟内存概念的自然延伸。虚拟机提供用户一个完整的硬件特性集合，也就是说，一个完整的机器可能和实际的机器有质的不同。

5.4.6 虚拟化 ( 续 )

图 5.18 传统的操作系统

5.4.6 虚拟化 ( 续 )

图 5.19 虚拟机

# 附加的复杂性增加了且转换和保护都带来额外开支。

5.4.7 分层设计 分层信任 正如前面所说明的，一个内核化的操作系

统至少由四层组成：硬件、内核、操作系统和用户，其中每一层都可以包含一些子层。当然，也可以将一个分层的可信操作系统描述成堆栈，其中安全功能离硬件最近。一些与保护功能相关的活动都是在安全内核之外执行的。所有这些操作在安全内核执行出现一个情况是，一些不需要高安全性的操作，也具有了高安全性。

5.4.7 分层设计 ( 续 )

图 5.20 分层的操作系统

5.4.7 分层设计 ( 续 )

换一种方法，可在几个不同的模块中实现一个单一的逻辑功能；我们称此为分层设计 (layered design) 。可以通过操作不同层的一组模块来执行一个单一功能。每层的模块执行一个某种敏感等级的操作。

5.4.7 分层设计 ( 续 )

图 5.21 操作在不同层中的模块

5.4.7 分层设计 ( 续 )

Neumann描述了可证明安全操作系统 (Provably Secure Operating System ， PSOS) 的层次结构。一些等级较低的层向等级较高的层提供部分或者全部的功能。但每一层适当地封装一些仅属于自己的内容。

5.4.7 分层设计 ( 续 )表 5.4 PSOS 设计层次层 功能 通过哪一层隐藏 用户是否可见16 用户请求解释程序 可见15 用户环境和名字空间 可见14 用户 I/O 可见13 程序记录 可见12 用户进程和可见 I/O 可见11 创建和删除用户对象 可见10 目录 11 部分可见9 扩展类型 11 部分可见8 段 11 部分可见7 分页 8 不可见6 系统程序和 I/O 12 不可见5 原语 I/O 6 不可见4 算术和其他基本操作 可见3 时钟 6 不可见2 中断 6 不可见1 寄存器和可寻址存储器 7 部分可见0 性能 可见

5.4.7 分层设计 ( 续 )

分层方法的优点在于： (1) 分层方法是实现封装的一个重要途径。每一层调用内层的服务，同时也向外层提供一定功能级的服务。这样，剥去个别的层仍然拥有一个逻辑上完整的系统，只是功能减少一些。

(2) 分层方法有利于对破坏进行控制。层次结构 (hierarchical structuring) 允许我们识别非常关键的部分，然后认真分析其正确性，这样问题就会少一些；隔离将问题的影响范围限制在问题发生的层及上层，从而可以限制大多数问题的影响。

5.5 可信操作系统的保证 假设操作系统的提供者已经考虑了所有因素，

并声称安全设计是有保证的，那么，接下来就该考虑如何向别人证明模型、设计和实现符合声称。我们需要一套方法来确定一个特定的操作系统是否适合给定的要求。这里通过运用测试、形式化和非形式化验证，探讨证明一个操作系统安全性的方法。

5.5.1 操作系统的典型缺陷 已知的漏洞 (1) 用户接口是操作系统最大的薄弱点，这

是因为用户接口是通过独立的、智能硬件子系统来完成的，常常独立于安全内核之外；与用户交互的代码比计算系统其他部件的代码复杂得多，并且更依赖于特定的硬件设备；用户接口通常是面向字符的，为了提高处理速度，传输这些数据常常限制指令数量。

5.5.1 操作系统的典型缺陷 ( 续 )

(2) 操作系统安全方面的第二个突出弱点是访问策略的二义性 (ambiguity in access policy) 。在策略上，隔离和共享之间的区别并不总是很明确。因此，在实现的过程中，也不能够严格区分。

(3) 第三个潜在的问题是不完全检查 (incomplete mediation) 。某些系统对每次 I/O 操作、进程执行、用户界面执行只做一次访问权限检查。

(4) 通用性 (generality) 也是弱点。作为操作系统的一部分，一些软件包必须拥有和操作系统一样的访问特权才能被执行。

5.5.1 操作系统的典型缺陷( 续 )

漏洞利用的例子 (1) 某些操作系统只在用户操作开始时进行

访问权限检查，这就导致了典型的检查时刻到使用时刻 (time-of-check to time-of-use flaw) 的缺陷。

(2) 操作系统为一些安全软件包的安装保留了一种特殊的管理功能，允许这时的操作不受严格控制。

5.5.2 保证方法 测试、验证和证实是三种使人们确信一个系统正

确的保证技术。但没有一种技术是完美无缺的，每一种技术都有各自的缺点。

测试 测试结果基于正被评估的现实产品，而不是产品

的某些抽象。有必要对基于测试的结论进行限制，因为：

(1) 测试能够证明问题的存在性，但粗略的测试并不能证明不存在某些问题。

(2) 在有限的时间和精力下，很难达到充分的测试覆盖要求，因为大量输入和内部状态使测试变得非常复杂。

5.5.2 保证方法 ( 续 ) (3) 测试通常是基于可观察到的结果，而不是基于产品的内部结构，因此不能够确保其完善程度。

(4) 基于产品内部结构的测试涉及到通过增加代码来修改产品，以提取和展示内部状态。但这样会影响产品的性能，而且可能会引入新的漏洞或掩盖其他漏洞。

(5) 在实时系统的测试中，很难记录所有的状态和触发事件。因此，很难重建和分析测试人员在测试过程中报告的问题。

# 测试通常受到项目预算和进度的限制。这意味着测试在某种程度上是不完善的。因此，需要了解测试策略中的测试覆盖度、测试完整性和测试有效性的情况。

5.5.2 保证方法 ( 续 ) 渗透测试 渗透测试 (penetration testing) 或称为攻击对分析

(tiger team analysis) 或合乎道德的黑客攻击 (ethical hacking) 是常用的一种计算机安全测试策略。渗透测试既是科学也是一门艺术。它艺术的方面要求仔细分析和测试用例选择上的创造力。而在科学方面则要求严密、次序、精确和有条理。没有通过渗透测试的操作系统肯定有错误，但是，能够通过这一测试也并不能保证没有错误。渗透测试成功的一个可能原因是它得以运用到真实环境中。渗透测试在商业团体中非常流行，但也不是一种神奇的技术。

5.5.2 保证方法 ( 续 )

形式化验证 在形式化验证中，操作系统被模型化，其原

理被描述为一些断言。模型和断言的集合被归结为一个“定理”，然后加以证明。形式化验证确认操作系统仅仅提供了它应该具有的安全特性。定理证明器 (theorem provers)的计算机程序可以帮助证明。形式化检验方法有两个主要困难：

时间：形式化验证方法执行起来很耗费时间。 复杂：形式化检验是一个复杂的过程。对某

些大的系统没有办法描述和验证断言。

5.5.2 保证方法 ( 续 ) 证实 证实 (validation) 和验证相互对应，确保系统开发

者实现所有需求。证实保证了开发者开发的是正确产品 ( 按照需求说明书 ) ，而验证核查实现的质量。有几种不同的方法可对操作系统进行证实。

需求检查：目标是证实系统完成了功能需求中所列出的每一件事。这一过程的目的只是证实系统至少在一种情况下做了它应该做的每一件事，而很难保证“不做”它不应该做的事情。

设计和代码审查：审计也可将重点放在需求实现之上，确保从每个需求到设计和代码部分都是可追踪的。

系统测试：程序员或者一个独立小组选择数据来检查系统的正确性。

5.5.3 开放源代码 软件界曾对所谓开源 (open source) 操作系统展开

了辩论，这种操作系统的代码可以自由发布以供公众分析。分析者通过仔细阅读开源代码找出其缺陷，而封闭 ( 专用 ) 的代码却能让攻击者很难找到并利用缺陷。

开源的其他好处包括： (1) 费用：由于源代码对公众可用，如果代码的所

有者收费很高，则公众就会买盗版软件。 (2) 质量：很多对审查者都可以分析代码，而这些审查者和软件与其开发公司无关。

(3) 支持：一旦公众找到缺陷，开放源代码将为修补缺陷提供很好的条件。

(4) 可扩展性：为了不断满足新需求，公众总是想办法扩展代码，并且和其他人共享这些扩展。

5.5.3 开放源代码 ( 续 )

一些知名计算机安全研究人员则认为是否公开源代码并不是问题的关键。一个软件是否可信，取决于它的质量以及我们所关心的设计、开发、安全问题。一些可靠性统计模型表明：在开放或封闭测试之后，这两种方法的平均失败率是相等的。

5.5.4 评估 大部分消费者 ( 即用户和系统的购买者 ) 并

不是安全专家。尽管需要安全功能，却无力进行详细的技术评估。因此，常常需要独立的第三方对操作系统的安全性进行评估。由于标准方法对评估非常有用，所以已经设计了一些用于构建独立审查的方案。

5.5.4 评估 ( 续 )

美国桔皮书评估 美国的可信计算机系统评估准则 (Trusted Comp

uter System Evaluation Criteria ， TCSEC) 发表在所谓的“桔皮书” (Orange Book) 上，为独立评估提供了准则。作为美国安全机构，国家计算机安全中心 (National Computer Security Center ，NCSC)指导并认可实际评估。

准则将信任等级分为 A ， B ， C ， D四类，其中 A 的安全等级最高。每一类，又存在不同级别，并用数字来标识，数字越大表明安全要求越严格。完整等级集合是 D ， C1 ， C2 ， B1 ， B2 ， B3 和 A1 。

5.5.4 评估( 续 )

(1) D ，没有要求。 (2) C1/C2/B1 ，要求许多商业操作系统共有

的安全特性。 (3) B2 ，要求对基础模型的安全性有精确的

证明，并对可信计算基 (trusted computing base) 有阐述性规格说明。

(4) B3/A1 ，要求对可信计算基进行能更精确证明的描述和形式化设计。

5.5.4 评估 ( 续 ) D类：最低保护。 C1类：自主安全保护——这一分类中有一个关

键词是“自主”。 C2类：受控访问保护——控制的粒度更细的自

主访问控制。 B1类：带标号的安全保护——每个受控的主体

和对象都要指派一个安全级。 B2类：结构化保护——必须把系统内部构造成

一些“明确的和大体独立的模块”。 B3类：安全域——设计中将实现“综合运用分层、抽象和信息隐藏”。

A1类：经过验证的设计——要求一种经形式化验证的系统设计。

5.5.4 评估 ( 续 )

欧洲 ITSEC评估 欧洲几个国家也认识到准则和方法在评估安

全产品中的作用，最终制定了 ITSEC ，即信息技术安全评估准则 (Information Technology Security Evaluation Criteria) 。

5.5.4 评估 ( 续 ) 德国绿皮书 德国准则确定 8 种基本安全功能，这些功能足以实施广泛

的安全策略： (1) 识别和鉴别：标识 (身份 ) 与主体或对象间唯一且特定

的联系。 (2) 权限的管理：控制主体和对象间访问权的分派和撤消。 (3) 权限的验证：对主体访问对象的合法权限进行检查。 (4) 审计：成功或不成功权限使用的信息记录。 (5) 对象重用：以没有违背安全策略的信息流出现的方式重置可重用的资源。

(6) 错误校正：找出需要校正的位置，恰当地撤消某些行为。

(7) 服务的连续性：识别系统中必须可用的功能，可以容忍什么样的延迟和丢失。

(8) 数据通信安全：对等实体鉴别、控制对通信资源的访问、数据保密性、数据完整性、数据源鉴别和防抵赖。

5.5.4 评估 ( 续 )

德国绿皮书定义了 10 个功能类。在功能要求上，类 F1 到 F5 对应于美国的类 C1 到 B3 。类 F6 适用于数据和程序的高完整性，类 F7适用于高可用性， F8 到 F10 和数据通信状况有关。为了解决保证性问题，德国这套方法定义了 8 个质量等级，从 Q0 到 Q7 ，大致对应于美国 TCSEC 中 D 级到 A1 级的保证要求。德国准则的一个突出贡献就在于它通过使用独立、商业化的评估工具进行评估。

5.5.4 评估 ( 续 )表 5.5 德国和美国评估准则的关系

Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7

F1 =US C1 超出美国 A1级F2 =US C2 超出美国 A1级F3 =US B1 超出美国 A1级F4 =US B2 超出美国 A1级F5 =US B3 =US A1 超出美国 A1级F6 新的功能表F7 新的功能表F8 新的功能表F9 新的功能表

F10 新的功能表

5.5.4 评估 ( 续 )

英国准则 最初的英国准则基于“声明” (claim)语言，它是

一种分析用语言，通过该语言销售商可以声明产品功能。声明语言由带有参数的行为短语 (action phrase) 和目标短语 (target phrase) 构成。行为短语和目标短语组合起来可以构成声明：

This access control subsystem can determine the read access granted to all subjects in respect to system files.

除了声明语言，还有 6 个等级的保证评估，即 L1到 L6 ，大致对应于美国的 C1 到 A1 或德国的 Q1到 Q6 。

5.5.4 评估 ( 续 ) 其他国家 除此之外，加拿大、澳大利亚、法国也在

制定评估标准。有三个突出的难点，其实是同一个问题的不同方面：

(1) 相似性：我们并不清楚不同的评估准则是如何联系起来的。

(2) 可转移性：在需要达到美国 C2等级的地方，通过德国 F2/Q2 或 F2/Q3 评估等级的销售商是否可以被接受？

(3) 市场特性：一个销售商能够支持多少种评估准则？

5.5.4 评估 ( 续 ) ITSEC：信息技术安全评估准则 ITSEC 保留了德国的 F1-F10 功能类，同时也保留

了英国声明语言的灵活性。一个相似的有效评估(effectiveness) 组件，大致对应于美国保证的概念。一个生产商必须定义评估目标 (target of evaluation, TOE) 这是评估的焦点所在。厂商陈述下列信息：

(1) 系统安全策略或基本原理：为什么要构建此产品 ( 或系统 )？

(2) 安全实施功能的规格说明：产品 ( 或系统 ) 的安全特性。

(3) 产品 ( 或系统 ) 的安全实施机制的定义。 (4) 机制强度的声明。 (5) 在功能和有效性方面的目标评估等级。

5.5.4 评估 ( 续 ) 评估进而决定以下方面： (1) 功能的合适性：选择的功能是否实现了

预期的安全特性。 (2) 功能绑定：选择的功能是否能够在一起协同工作。

(3) 脆弱性：在 TOE 中是否存在脆弱性或者在预期的环境中这些脆弱性如何起作用。

(4) 易用性。 (5) 机制强度： TOE抵抗直接攻击的能力。

5.5.4 评估 ( 续 )

美国联合联邦准则 联合联邦准则 (Combined Federal Criteria) ，

是由美国国家标准和技术研究所 (NIST ， National Institute for Standards and Technology)和美国国家安全局 (NSA ， National Security Agency)联合制定的。重点解决与欧洲诸国标准兼容问题。联合准则草案模型仿效了欧洲模型，并且将特性和保证适当分开。联合联邦准则引入了安全目标和保护轮廓的概念。

5.5.4 评估 ( 续 )

对于具体情况或一般情况，用户都能够生成保护轮廓 (protection profile) 来详细列出功能和保证的保护需求。保护轮廓可以是信息技术产品安全方面的一个抽象说明书。

为了响应保护轮廓，销售商应该生产满足轮廓需求的产品。然后，销售商将具体产品的保护轮廓的需求映射成为一个叫安全目标 (security target) 的声明。安全目标成为评估的基础。

5.5.4 评估 ( 续 )

通用准则 通用准则和美国的联邦准则非常相似。其

中保留了安全目标以及保护轮廓的概念。将保护需求打包可以确保对于特定类型的应用是完善和一致的。示例包在通用准则中受到特别的关注。通用准则定义了安全有关的类。以这些类为基础，定义了功能或保证需求的族，基于族定义了独立组件，将独立组件组合成组件包，以满足综合要求或某个信任等级。包成为特定应用和产品需求的断言。

5.5.4 评估 ( 续 )表 5.6 通用准则中的类功能 保证识别和鉴别 开发可信路径 测试安全审计 脆弱性评估安全功能调用 配置管理用户数据保护 生命周期支持资源利用 文档向导可信安全功能保护 发布和操作隐私通信

5.5.4 评估 ( 续 )

图 5.22 通用准则中的保护轮廓和安全目标

5.5.4 评估 ( 续 ) 评估准则总结 准则的目的是提供一个值得信赖的、独立的安全评估方法。 评估过程 可以运用一些客观准则集合来考核评估过程本身。在评估

中有几种我们都期待的良好性质，包括： (1) 可扩展性： 随着产品功能的增强，评估能否扩展？ (2) 粒度。 (3) 速度。 (4) 全面。 (5) 客观性与一致性。 (6) 可移植性：能够对运行在任何平台上的产品进行评估吗？

(7) 兼容性：不同准则对同一产品的评估过程是否相似？ (8) 可输出性：评估证实了另一个方案符合所有和部分安

全需求时，对当前方案的这种评估是否能被接受 ?

5.5.4 评估 ( 续 )准则开发活动

图 5.23 准则开发成果

5.5.4 评估 ( 续 ) 有关评估准则的经验 准则一直受到军方的关注，但是在商业领域并没有得到太多的认可。一些大厂商欣然接受低保证评估的产品。现实要求每个人都认识到市场 ( 并非某个准则文档 ) 最终决定需要什么，不需要什么。一般认为市场最终会选择优质产品。经验表明按照上述准则，厂商能够生产出高质量、值得信赖的产品。虽然大声宣布产品质量比提供清晰可信依据更容易和廉价，但是一些厂商已经宣布共同致力于评估，认为独立的评估是质量的标志。

5.6 本章总结 安全操作系统开发包括几个步骤：第一，通过策略描述和模型，可以确定系统中的各基本组成部分，然后研究各组成部分之间的交互。第二，在了解了环境之后，必须设计一个系统提供所期望的保护，我们较为详细地学习了特定的安全设计原则，包括隔离或分离、分层设计以及安全内核的概念。第三，仅有一个好的操作系统设计还不够，还需要确保设计和实现是正确的，因此，本章提供了形式化验证、证实以及渗透测试来证明正确性。除此之外，还简单讨论了几种评估准则。

谢谢！