资源目录

翻译：陈海燕，CISSP（phrackchen@hotmail.com）

美国国家标准和技术学会推荐

英文版PDF 中文版PDF

注：以下内容因排版原因有所省略，完全信息请查阅中文版PDF。

1.0 介绍

1.1 背景

国家计算机安全中心（NCSC）的主要目标是促进受信计算机系统的推广。为了达成这一目标，NCSC创建了一项基准，《国防部受信计算机系统评测标准（TCSEC）》［17］，根据此基准对计算机系统进行评测。

TCSEC首先于1983年8月15日以CSC-STD-001-83的形式出版。在经过修改后国防部于1985年12月予以采纳，并做为国防部标准DoD 5200.28-STD。国防部5200.28指令《自动化信息系统（AISs）的安全需求》［10］要求国防部使用TCSEC。TCSEC是用于评测国防部AISs中建立的安全控制效率的标准。

TCSEC被分为四个部分：D、C、B和A。这些部分以等级形式排列。TCSEC最高部分（A）保留用于可得到的提供最佳保证级别的系统。C和B部分中有被称为级的分部分，它们也是以等级形式排列以代表这些部分中不同的级别。

1.2 目的

在TCSEC中B3级和A1级出现的一项重要保证需求是受信恢复。受信恢复的目的是确保在运作故障和中断情况下维护系统的安全和职能特性。为了达到此目的，系统应该加入一系列机制使其在预先定义的一系列预期故障或中断发生时能够保持安全状态。它还应该包括一系列规程使管理员能够在非预期故障或中断发生时将系统带回到安全状态（第6章解释预期和非预期故障的区别）。

除了这些机制以外，TCSEC的B3－A1级还要求实施者遵循特定的设计原则和实务，被统称为保证措施。TCSEC进一步要求开发者向评测者或审批者提供充分的特定文档证据以证明机制和保证充分满足了特定的需求。

本指南提供了与受信恢复相关的议题。它为制造商提供了何种受信恢复功能应该被加入到系统中的指导。它还为系统的评测者和审批者提供了如何评测受信恢复功能的设计和实施的指导。本文包含由TCSEC目标导出的意见和建议，但这些并不是TCSEC的要求。本文的例子不是实施受信恢复的仅有方式。这些建议也不是对TCSEC的补充需求。衡量遵循TCSEC的尺度仅限于TCSEC本身。

本指导方针不是恢复议题的教导性介绍。而是描述了满足B3和A1级受信恢复需求的操作系统的设计要点。我们假设本文读者是已经熟悉操作系统恢复概念的操作系统的设计者或评测者。本指南解释了系统恢复的安全特性（和受信恢复的概念）。它还定义了一系列受信恢复机制和保证的基线需求和建议。不熟悉系统恢复以及B3和A1级系统所需安全模型的读者可以在本指南引用的恢复文献（如［1、5、14-16、20-23、25、27］）和安全文献（如［3、11、26、29］）中查找到有用的信息。

1.3 范围

受信恢复是指确保故障和运作中断不会破坏系统安全运作所需的机制和规程。所提供的受信恢复指导方针涉及到TCSEC中B3和A1级所需的这些机制和规程的设计。这些指导方针适用于为满足TCSEC需求而建立和修改的计算机系统和产品。我们提出了由TCSEC所陈述目的导出的附加建议。

这里没有涉及到被设计用来对ADP设备的物理攻击、自然灾害、水灾或火灾造成的故障进行容错的恢复措施，也没有涉及到处理这些事件的管理措施。这些措施的评测超出了TCSEC的范围［17,p.89］。

1.4 控制目标

受信恢复是运作保证的一个领域。保证控制的目标提到：

“用于处理或运用保密或其它敏感信息的系统必须被设计成能够保证安全策略的正确和准确解释并且没有歪曲其政策的本意。必须为存在于整个系统生命周期的策略的正确实施和运作提供保证。”［17,p.63］

此目标从两方面影响到受信恢复。首先，恢复机制和规程的设计和实施必须满足正确实施和运作的生命周期保证需求。第二点，系统的管理规程和恢复机制都应该保证在系统故障和运作中断的情况下系统安全策略的正确执行。第2章中定义了故障和运作中断。

1.5 文档概述

本指南除了本介绍章节以外还包含五章。第2章回顾了故障、运作中断和恢复的关键概念。第3章讨论了受信恢复的特性。第4章提供了恢复的设计方法和可以被用于受信恢复的选项。第5章讨论了其它TCSEC需求对受信恢复的影响。第6章提供了影响受信恢复功能设计和实施的TCSEC需求，并包括与B3－A1评测级对应的附加建议。术语表包含了所使用的重要术语的定义。接下来是文章所摘录的参考资料列表。

2.0 故障、中断和恢复

TCSEC要求B3和A1安全级：

“应提供规程和／或机制以确保ADP系统故障或其它中断时能够被恢复而不会破坏其受保护的状态。”［17,p.39］

我们在本章中讨论受信计算基（TCB）故障和运作中断的概念，并提供其对系统状态影响的非形式化定性描述。我们还简要地表述了实践中使用的一般恢复方法。我们在本章和全文中使用术语“故障”表示有事件造成系统的功能与其非形式化规格说明不一致。我们保留术语 “运作中断”用于表示由用户、管理员或操作员的行为造成的故障。

计算机系统的恢复机制被设计用来响应预期的故障或运作中断。这些机制不处理“非预期”的故障和“非预期”的运作中断；所以计算机系统文档应该包括管理规程的描述来处理这样的事件。在设计良好的系统中，非预期故障和运作中断是那些预计发生频率很低的事件，也就是一年一次或两次。因此，管理规程不同于系统中的自动化机制，它们是复杂而昂贵的，并提供了对非预期故障和运作中断的充分响应。

人们无法建立故障和运作中断的形式化模型来证明模型的内部一致性。诸如设备、处理单元、存储器以及用户、管理员和操作员的行为也都不具有形式化特性［21］。所以，预期故障和运作中断的形式化模型和规格说明是不必要的。只能作出从运作经验中导出的关于预期故障、中断、及其影响和频率的非形式化假设。参考资料［14、15、21］提供了这种假设的例子。这些非形式化假设应该被明确地写进系统文档以构成恢复机制和管理性恢复规程设计的基础。

但是，做为对预期故障或运作中断发生的直接响应，恢复机制和管理规程必须重建一致的系统状态，或防止状态转换到不一致的状态［8、9］。如果其定义的变量满足预先给定的形式化或非形式化的系统不变式特性的表述，则系统状态是“一致的”，这个问题在3.1节中讨论。“状态转换”是以特定的方式改变系统状态变量的功能，也就是设定为对系统运作规则的约束，这个问题在3.2节中讨论。所以，恢复机制和管理规程的设计应该使用不变式特性和为系统定义的安全模型的状态转换约束，这个问题在第3 章讨论。

可以通过对典型系统的故障和运作中断的影响进行描述来很好地理解恢复机制和受信恢复的角色。在文献［14、15、21］中提供了由不同系统的运作经验导出的非形式化和定性的故障假设。使用这些非形式化假设我们可以定义影响TCB运作的通用类别。

一种故障类别是当用户向TCB元语输入错误的参数，或启动错误的TCB元语，以及当系统资源被耗尽或发现由于用户行为造成不一致状态时导致的错误类别。这些被称为状态转换故障或行为故障。我们将这种更多地属于异常处理范畴的用户导入故障归纳为两点：（1）这种类别的故障无论其原因都是TCB范围的故障；并且（2）这些故障的处理－不仅限于规格说明和文档－与系统安全相关。

例如， 不正确的错误处理会将系统带入用户无法与TCB进行通信的状态，或会造成对隐蔽信道的错误处理。但是，本指导方针的主要重点更多集中在故障的传统概念上，也就是TCB故障、介质故障和管理员引入的运作中断。

2.1 状态转换（行为）故障

状态转换故障，也被称为行为故障，发生在导致状态转换的TCB元语由于在执行期间探测到异常条件而无法完成时。状态转换故障可以是由于向TCB元语输入了错误的参数，或有限的资源被耗尽，或TCB元语执行期间遗失了所需的对象等情况造成。

状态转换故障对TCB状态的影响不像其它故障那样深远。因为这些故障经常发生，所以TCB元语代码中通常包括恢复机制以便在元语返回之前还原系统状态的临时更改，这样系统就返回到稳定状态了。如果TCB元语的恢复机制无法还原系统状态的临时更改，系统就可能处于不一致的状态并逐渐崩溃。崩溃是导致处理器的寄存器复原到标准值的故障［21］。由于在崩溃后无法由处理器和主存储寄存器恢复一致的系统状态，所以这些寄存器被称为“易失”寄存器。相反的，一致的系统状态通常可以由诸如磁盘和磁带的磁介质恢复；这些介质被称为“非易失”存储器。

与TCB元语在状态转换故障后还原临时状态修改相关的恢复机制的例子可以在大多数现代操作系统中找到。例如，考虑一下在假定的UNIX系统上分配文件表条目之前分配I-NODE表条目的情况下使用“CREATE”元语的情形。如果在调用“CREATE”时文件表条目已满就会发生状态转换故障。在返回调用者之前，“CREATE”的恢复代码释放无法创建文件的I-NODE表条目。无法释放这样的条目将导致I-NODE表被填满或保持满状态，从而导致系统崩溃。

2.2 TCB故障

TCB故障发生在TCB代码探测到TCB元语的接口层下方有无法修复的错误时；也就是错误无法被屏蔽。TCB故障是由关键系统表中持久的不一致性，或TCB代码的无序分支（可能由瞬态硬件故障造成），或电源故障，或处理器故障等造成的。TCB故障总是会导致系统崩溃。

在提供高度硬件容错的系统中，系统崩溃仍然会因软件错误而发生。因为崩溃会导致易失存储的丢失，而且因为非易失存储通常会在崩溃后保存下来，所以恢复机制可以在运作的维护模式重建一致状态。重建一致状态后，恢复机制重启系统，但在此过程中没有进程被执行，如在崩溃被终止前已被激活、禁止或交换的进程。运行崩溃时被终止执行的进程代码的新的进程可以由用户在一致的状态被重建后启动。恢复机制可以通过清除或完成在非易失介质中取回的各种对象未完成的更新来重建一致的状态。可以在TCB故障后由非易失存储重建恢复机制的特性和设计方法在3.2节和第4章中讨论。

一些TCB故障允许以有序的方式关闭系统。这些故障可以是由进程交换空间耗尽、计时器中断表耗尽，以及通常由TCB元语自身在常规运作模式中无法处理的条件造成。由持续的硬件故障如内存和总线较验错误引发的陷阱也可能导致故障。

2.3 介质故障

介质故障发生在探测到一些TCB无法修复的非易失存储设备错误时（也就是错误无法被屏蔽）。介质故障是由诸如磁头损坏、由于磁头偏离造成的持久读／写故障、磁涂层划伤、磁盘表面的灰尘等情况引起的。它们也可以由诸如引起介质无法读取的TCB故障之类的软件故障造成。

介质故障的影响是部分或全部的TCB对象介质变得无法使用和损坏。与系统安全相关的数据结构也可能被介质故障破坏，如对象的安全标签。除非丢失的数据能够被从归档介质中提取并在冗余存储设备上重建，否则系统通常会崩溃。当然，不影响TCB的介质故障可能不会造成系统崩溃。如果没有冗余介质，或用户和管理员不保持归档数据的更新状态，介质故障可能就会变成无法恢复的故障。管理性恢复规程可以被用于将系统带到一致的状态。正如第5和第6章中讨论的那样，所有这些规程都应该在系统《受信设施手册》中阐明。

2.4 运作的中断

由用户、管理员和操作员引入的故障造成运作中断。在操作系统中，运作中断通常以状态转换故障和TCB故障的形式出现而很少以介质故障的形式出现。它们由错误行为造成，如关闭电源这样意外的系统关闭。它们也可以由缺乏行动造成，如管理控制没有理会书面或在线警告而导致对关键系统资源耗尽的忽略，这种警告可能是审计跟踪达到95％溢出限额、所剩的交换空间不够、所安装的配置不充分等。

运作中断的影响与上面提到的状态转换和TCB故障相同。重建一致的状态所需的恢复机制和管理规程也相应的与这些故障类似。例如，在执行调用期间按下“BREAK”键取消TCB元语的调用可能与TCB元语探测到状态转换故障的影响一样。每个TCB元语和状态转换都必须被设计为在关键代码段执行期间忽略取消信号，或在处理这样的信号期间清理内部数据结构。

诸如在TCB代码执行期间，通过关闭电源进行系统关闭的行为可能造成TCB故障。由电源故障造成的TCB故障的恢复机制也有可能可以处理意外系统关闭。无论是哪种情况，在后续的加电规程中，TCB应不仅能够探测到TCB故障造成的不一致状态，而且还应在系统进入常规运作模式前进行一致状态的恢复。

像是管理员或操作员的行为造成介质故障的情况较少发生。如在常规的系统运作模式下，而不是在维护模式下对介质控制器进行在线诊断测试，这很可能导致介质故障。类似地，在常规的运作模式中，启动诸如磁盘格式化这样的TCB维护行为也必将造成后续的介质故障。由管理员或操作员引入的故障造成的运作中断可以要求使用管理性恢复规程。

3.0 受信恢复的特性

受信恢复的特性由两个概念术语定义：安全状态和安全状态转换。当由安全和职能模型的正确解释导出的一致性不变式被满足时，系统的状态是安全的。如果其输入状态和其输出状态是安全的，并且满足安全策略和职能模型的正确解释对其进行的约束，则状态转换是安全的。

职能模型包括用户认证、受信路径和审计模型。在本章中会简要描述安全状态的不变式和特定状态转换的约束的概念，在参考资料［11］中有详细讨论。参考资料［29］详细讨论了安全模型的正确解释的概念，在参考资料［3］中有相关描述。为了简洁起见，本指导方针不描述安全模型的解释。

3.1 安全状态

安全的状态机（或“状态转换”）模型，如Bell-La Padula模型［3］使用以下抽象变量定义了状态：

a. 主体（受信的和非受信的）
b. 对象
c. 访问特权
d. 访问矩阵（定义主体对对象的特权）
e. 当前访问集（定义了主体当前可以对对象使用的特权）
f. 安全功能（定义了主体最大的和当前的主体许可证和对象保密级）
g. 对象等级序列

这些抽象变量被用于定义状态不变式以帮助定义安全状态的概念。以下段落编号从（1）－（5）讨论了受信恢复状态不变式的使用和特点。

（1）安全不变式由安全模型解释形式化地导出。

状态机模型也包括条件或公理，它们在给定系统中的解释提供了必须满足安全状态的不变式特性。例如，Bell-La Padula模型包括以下条件：

a. 主体的简单安全条件
b. 安全功能的＊－特性
c. 当前访问集的访问特权的任意安全条件
d. 对象等级序列的兼容条件

模型描述［3］使用系统状态变量及其正确解释的例子精确地定义了这些条件的特定含义。

（2）在需要时，非形式化导出的不变式应该用来增强形式化导出的不变式。

状态转换模型可能不包括与安全或职能概念相关的所有条件。这种情况下，需要定义新不变式以便增强由模型条件（或公理）解释导出的现存不变式集。例如，附加的不变式可能被用来定义诸如口令文件、用户帐户文件、安全映射文件以及系统配置文件之类的对象，支持Bell-La Padula模型的系统受信进程使用这些对象。这些不变式可能涉及到多种类型的对象，正如这个例子中描述的那样：

在所有的系统状态中，所有用户和组的标识符必须是唯一的、完整的值；标识符的长度可以从零到所定义的一个字符最大数。

用户和组标识符可以包含在一个口令文件、用户帐户文件和定义组成员的文件中。当模型条件的解释无法提供给定系统的充足细节时，在安全策略和职能领域可能也需要附加不变式。例如，特定于TCB实施任意访问控制的多访问控制列表（ACLs）的不变式可以这样描述：

在所有系统状态中，ACL条目必须如下排序：

• <user id.group id > 条目领先于 <user id.* > 条目
• <user id.* >条目领先于< *.group id > 条目
• < *.group id: >条目领先于< *.* > 条目
  “*”表示通配符。

类似的不变式也应该增强访问控制和职能的其它领域（如用于用户和系统安全特征文件的不变式，该文件包括最小和最大的用户许可证以及对象保密级；用于审计机制的不变式）。

要使TCB恢复机制成为可信的，它们必须能够在常规的运作模式中维护安全状态，即使发生了故障和中断，也必须能够探测到不安全状态并在维护运作模式中重建安全状态。为了探测系统故障后的非安全状态或验证恢复后的状态是安全的，恢复机制必须检查安全不变式是否被满足。所有的安全不变式与处理状态转换故障的恢复机制相关。这些故障通常将系统遗留在常规的运作模式而不是使系统进入维护模式。所以，所有必须在常规运作模式中保持的不变式也必须在状态转换故障恢复后保持。

（3）一些安全不变式可能与受信恢复无关。

不是所有的安全不变式都与其它类型的故障相关。例如，考虑一下所有易失记忆丢失并且系统进入维护模式的TCB故障情况。在维护模式中，一致的状态被恢复，安全不变式得以检查，系统被重置到处于安全状态的常规运作模式，这种状态通常包括用户进程（也就是非受信主体）的一个空集和对应的当前访问的空集。

在多数系统恢复设计中，恢复机制仅仅重启了一些受信进程（如监听终端的“登陆”进程）。在TCB故障时执行的用户进程由于其状态随着易失记忆的丢失而丢失，或者易失记忆在恢复过程中丢失所以被终止。用户可以在系统被置于常规运作模式后启动执行这些被终止进程代码的新进程。所以，在TCB故障后，恢复机制无需检查与当前访问集相关的不变式特性。

例如，在由Bell-La Padula模型的条件导出的不变式集中，只有那些对应于简单安全条件和来自兼容条件的不变式，在系统崩溃后相应地保持与受信进程和对象等级序列相关。但是，如果至少有一些用户进程的当前状态能够在TCB故障后恢复，由Bell-La Padula模型条件（如＊－特性）导出的其它不变式也就变得相关了。这样，相关的不变式类型依赖于希望和可能的系统状态恢复类型（如没有活动进程的状态），没有被打开的文件或设备，或至少有一些活动进程的状态、被打开的文件和设备。系统状态恢复的类型取决于设计者的选择或其它非TCSEC需求。但是，完整的安全不变式集应该由用于所有系统状态恢复类型的安全模型的解释导出。

（4）所有的TCB完整性不变式应该被受信恢复满足。

为了探测不安全状态，或验证恢复的状态是安全的，安全机制还必须验证TCB的完整性不变式是否被满足。内部TCB完整性不变式不一定只涉及到由用户级安全或完整性模型定义的状态变量。它们也可能涉及到用于对象和主体表现的内部TCB变量，并且可能在用户和TCB管理接口层无法看到。例如，内部TCB完整性不变式可能需要满足以下条件：

a. 磁盘块是空闲的或已被分配。
b. 空闲的和已被分配的磁盘块之和等于磁盘块的总数。
c. 所有已被分配的磁盘块只被分配给一个对象并且只分配了一次，而且空闲的磁盘块不属于任何对象。
d. 能够从其等级序列的根到达所有活动的对象。
e. 如果某对象的链接数或参考数是零，则该对象不存在任何链接或参考。

多数操作系统提供恢复机制，试图在崩溃后探测到内部的不一致并恢复到一致的状态。［1,§5.18］提供了用于UNIX文件系统的内部操作系统不变式的例子，该不变式由操作系统检查程序“FSCK”强制执行。

（5）安全不变式的缺乏使受信恢复变得不可能。

确定安全状态在受信恢复中的关键作用突现了安全不变式的重要性。缺乏这样的不变式则无法确定TCB元语是否能够忍受状态转换故障，也就是TCB元语是否能够在其返回调用者之前清除临时的状态改变。类似地，如果所有的状态转换都被设计为在“预期”TCB故障和运作中断的情况下满足所有的模型约束，缺乏安全不变式就无法让恢复机制和规程确定已恢复的状态是否是安全的，这种情况在3.2节中讨论。“非预期”的TCB故障、介质故障或中断可能会使系统处于不安全状态。这样的状态是否安全只决定于对状态不变式的验证。

3.2 安全状态转换

源于安全输入状态的安全状态转换保证（1）其输出是安全的，并且（2）满足为其定义的所有安全约束。与不变式相反，不变式被定义于单独状态的变量之上并且用于所有的状态转换，约束是事先设定的并与两个或以上状态的变量相关。约束可能只与特定的状态转换相关。典型的约束如下：

对于任何改变对象安全级别的TCB元语，新的级别必须高于原来的对象安全级别。

此约束表示用户只能够提升不能降低对象保密级的策略需求，可以在参考资料［3］的附录中和参考资料［11］中找到其它类似的约束。

（1） 受信恢复需要所有的约束被满足。

TCB元语实施安全状态转换。元语在其返回调用者之前可能临时将系统置于不安全的状态。状态转换期间的任何故障或运作中断可能将系统置于不安全的状态。此外，即使恢复后的系统状态显示是安全的，也可能由于故障而违反了放置在安全状态转换上的约束（在TCB出故障期间）。

例如，考虑一下改变对象安全级别的状态转换以及在没有故障的情况下满足上面定义的约束。由于安全级别可能是一个多字段、多字的数据结构，对它的任何更改都需要执行至少包括输入／输出指令的多项指令。故障可能发生在安全级别更新过程中，如在磁盘写入操作期间的电源故障会使安全级别只进行了部分更新。这可能会违反上面定义的约束但可能不会影响到任何状态不变式。更新可能在故障以前更改了许可证字段和一些内容，但不是所有类别的安全级别字段。因此造成对象安全级别不能再高于原来的对象安全级别，违反了上面的约束。但是，有可能造成对象的安全级别满足所有的状态不变式，如由Bell-La Padula模型的简单安全和兼容安全条件的解释导出的不变式。恢复机制将无法探测恢复后的状态所包括的更新内容是否是不安全的。

类似地，当TCB在向新创建的文件中写入标记时、在系统管理员进程更新安全映射过程中、在对包含访问控制列表或任何其它安全相关数据结构的文件进行更新的过程中崩溃更有可能产生问题。在下面标记为（2）的段落中讨论的原子化状态的概念将防止此类恢复问题违反系统安全策略。

在对安全不变式进行广泛的和耗时的检查后，恢复机制能够探测到TCB或介质故障导致的系统处于不安全状态的情况，而无需依赖于实施安全状态转换的TCB代码的特殊设计。少数情况下，恢复机制仍然能够恢复老的安全状态，或由非易失介质建立新的安全状态，而无需依赖于应对各种故障的TCB代码的特殊设计和实施。

在安全状态转换创建新的状态过程中，由于约束与老的状态变量相关，故障可能导致无法验证约束。也就是说，新的状态在故障中没有被完全更新时又无法再得到老的状态值。所以，实施状态转换的TCB代码的设计保证为转换的安全输入状态或安全输出状态提供恢复是很重要的。在后面的情况中，应该保证恢复机制满足转换的安全约束－而不仅是安全状态不变式。

（2） 所有TCB元语的原子化状态确保受信恢复。

原子化状态是实施安全状态转换的TCB代码的关键特性，即使发生了（预期）故障，也能够使恢复机制重建安全状态。假设所有的状态转换能够按照产生控制机制的方式串行化［21］，如果其要么完全执行要么根本不产生影响则状态转换就是“原子化的”。在实践中，这种特性意味着实施状态转换的TCB代码被设计为确保对于预期的故障类型，恢复机制总是能够在故障后重建输入安全状态或输出安全状态。

文献描述了在操作系统级［16、21、23、25、27］和数据库管理系统级［14、15］提供原子化状态的各种方法。我们在第4章总结这些方法。

（3） 所有TCB元语的原子化状态不总是受信恢复所需的。

在许多操作系统或TCB元语中，确保所有安全状态转换是原子化可能是比较困难的。一些操作系统元语包含许多单独的对象更新，原子化状态要求这些元语做为“事务”（在4.2.2节和参考资料［14、15、16、21、23、25、27］中定义）来实施。在所有TCB元语中实施事务行为的复杂性和造成的性能损失对于很多小操作系统来说可能是难以接受的。

在很多小操作系统中，都采用了更实际的方法进行TCB元语设计和对象表示来帮助恢复机制探测不一致性。仅帮助探测崩溃后的不一致（不安全）状态而不确保安全状态转换的原子化状态的TCB元语机制是可以接受的。这些实施方法将重建一致性或安全状态的任务留给了管理用户和工具。是选择使TCB元语具有原子化特性还是选择TCB元语只帮助探测崩溃后的不安全状态由系统设计者决定。

在［22］中提供了通过“提取”进程探测不一致性的文件系统设计的例子。提取进程发现表现不完整的文件并删除崩溃后表现出不一致性的文件。对于比较大的系统来说，如UNIX系统调用就被设计为只需要一些用于一致状态恢复的设施而无需管理性干预就能确保“FSCK”程序可以探测到崩溃后文件系统的各种不一致情况， 这在[1,Chs.5.16-5.18]和［5］中有介绍。4.2节提供了帮助恢复机制探测和矫正不一致性的TCB元语设计考虑的例子。

4.0 受信恢复的设计方法

本章中我们讨论管理用户在受信恢复中的责任，概述一些设计受信恢复机制的实际困难，并总结可能会用于受信系统恢复的几种通用设计方法。我们也回顾操作系统设计者可采用的受信恢复的主要选项。本章的首要目标是给读者提供文献中和过去十年里各种系统中所实施的恢复设计方面的概况。

4.1 受信恢复的责任

根据所发生故障的类型将受信恢复的责任分为两类：（1）TCB设计责任，和（2）管理员责任。状态转换故障通常由TCB元语在系统不处于维护模式的情况下处理的。受控的系统关闭和后续的重启也由TCB在很少或没有管理性干预的情况下进行，也就像UNIX的“FSCHK”程序那样。

相反的，紧急系统重启和冷启动主要由系统管理员使用TCB支持工具执行。在系统管理员中，系统程序员的角色负责受信恢复功能（如系统对象、单个TCB文件和数据库的一致性检查，受损安全标记的修复等类似情况［24］）。当系统程序员角色没有被系统设计分离并确定时，安全管理员也可能执行恢复任务。

系统程序员可能有检查TCB结构完整性以及初始状态的安全不变式所需的额外工具，也就是建立初始的安全系统状态。这个状态的确定与恢复后的状态是否安全的确定是类似的。但是，初始系统状态可能不需要与恢复后的状态一样，因为不像恢复后的状态，初始状态可能不包括任何用户可见的对象。这样，与确定初始状态安全相关的不变式可能会比较少。

诸如参考资料［2］中建议的用于识别某些系统状态缺陷的工具对于建立安全初始状态和恢复后的状态也可能有用。由于一些用于探测不安全状态和用于修复各种系统数据结构的工具被放置在TCB的维护模式中（如FSCK工具［1、5］），所以这些工具的使用应该限定于系统程序员角色。

4.2 当前形式体系的一些实践难点

安全状态不变式和状态转换约束在受信恢复中的关键作用意味着B3－A1级系统的设计应该使用安全策略的状态机模型［11］，而不是其它不使用安全状态和安全状态转换的模型类型，如信息流模型。虽然在原则上这个建议是正确的，但是实际上现存的安全策略状态机模型如［3］并不是完全适用于设计受信恢复机制。这种情况至少是因为以下两个原因造成的。

首先，解释当前状态机模型时，扮演系统管理员角色的受信进程的状态不变式和转换约束在数量上不足。其二，现存的模型不包括安全系统的职能特性，这造成无法对职能不变式和约束进行形式化导出。这些现存状态机模型的不足之处明显是由其过于抽象以至于无法包括上面提到领域的系统特定不变式和约束造成的。

需要在职能领域的受信进程和管理性规程中定义的不变式和约束比其它TCB领域现存的状态机模型导出的更多也更复杂。［4］中报告了一个定义受信进程领域状态不变式的尝试，该尝试是出于安全验证目的而非受信恢复目的的。参考资料［19］的附录E定义了出于验证初始和恢复后系统状态安全这一特定目的的职能领域中，用于状态变量的不变式条件的完全扩展列表。

缺乏用于受信进程和职能程序的状态变量和状态转换的不变式和约束，使确定TCB元语是否能够忍受状态转换故障变得困难，如形式化确定元语在返回调用者前是否正确地清理了不一致状态。形式化确定恢复机制是否能重建当前状态，或在预期的TCB或介质故障后是否能在维护模式中完成状态转换对于任何人来讲都是具有挑战性的工作。但是，系统特定不变式和约束的非形式化导出在受信恢复设计中是可以接受的，只要提供了这些机制设计中对其正确和广泛使用的证据。这样的使用体现了这些机制被正确设计的重要的附加保证。

4.3 当前恢复方法的总结

4.3.1 系统恢复的类型

操作系统对故障的响应可分为三种常规类型：（1）系统重引导、（2）紧急系统重启、和（3）系统冷启动［14］。

系统重引导是在对TCB故障响应期间以受控方式关闭系统后执行的。例如，当TCB探测到一些重要表的空间被耗尽，或发现不一致的对象数据结构，它将关闭所有的对象，终止所有活动的用户进程，在没有用户进程执行的情况下重启。但是在重启前，恢复机制会尽力矫正不一致性的来源。有时，仅仅终止所有进程就可以释放一些重要的资源，使重启拥有足够的可用资源。应该注意的是，当恢复机制可以确定影响系统安全和完整性的TCB和用户数据结构实际上处于一致状态时，系统重引导才是有用的。

紧急系统重启是在对TCB或介质故障响应期间，在非受控的方式下发生系统故障后执行的。在这种情况中，属于TCB或介质故障发生时活动进程的非易失存储中的TCB对象和用户对象可能会被置于不一致状态。系统进入维护状态自动执行恢复，在将系统带入到一致状态后系统重启但不执行用户进程。

系统冷起动发生在非预期TCB或介质故障发生且恢复规程无法将系统带到一致状态时。TCB和用户对象可能在自动恢复尝试后依然处于不一致状态。这时需要管理人员将系统从维护模式带到一致状态。

4.3.2 当前方法

将所有内部TCB数据结构和安全属性视为一个数据库是TCB自动化恢复机制的一种可行的方式。这种方式由于近十年来在数据库的一致性和恢复方面取得了重要的技术进步变得更有价值；从理论上，人们可以使用这些进步对TCB受信恢复进行设计。因此，我们要回顾用于实施原子化行动和事务的数据管理和其它存储系统的可能方法。

一种大多被用于操作系统级的恢复的可选方法依赖于对非原子化状态转换期间的故障所造成的不一致性的探测及其不一致性的后续矫正。这种方法，一般被称为恢复（和行动串行化）的“乐观”方法，它假设TCB故障是罕见的，故其广泛的恢复机制带来的负荷方面的损失不至于严重影响整体性能。通常，乐观的恢复方法比使所有状态转换变为原子化的方法具有更好的整体性能，但是恢复的设计会困难很多。4.3.4节提供了帮助探测故障后TCB不一致性的操作系统机制的例子。

4.3.3 原子化状态转换的实施

如果行为是单式的和串行化的则它就是原子化的；如果要么发生要么没有影响则它是单式的；如果它是活动集合的一部分并且集合中任何两个或多个行动与同一对象相关并按照表面上连续的顺序执行则它是串行化的［14、15、21、25、27］。一个事务包含一序列的读和写行为，如果整个行为序列是单式的和串行化的则它是原子化的。应该实施原子化行为或事务的TCB元语的例子包括更新一个口令文件、更新一个安全映射、改变一个安全级别、改变一个用户的安全特征文件、更新一个ACL、以及链接对象或取消链接对象到等级序列。

有三种基本技术被用于实施原子化的行为和事务：（1）更新映像、（2）更新日志、和（3）更新映像和日志的组合。映像和日志的主要区别是系统使用映像完成冗余磁盘页或文件的所有更新直到原子化事务的所有更新被完成，然后将这些更新引入到原来的系统数据中；而系统使用日志只是先向日志中写入每个更新，然后直接更新原来的系统数据，也就是更新就地进行。

两种可选方法的优点和缺点、非易失内存的存储和110需求、以及事务实施的两阶段提交概念在［14、15］中讨论。

4.3.3.1 映像

使TCB元语像原子化事务一样动作的核心思想是两个阶段更新元语。首先，元语的所有更新被集中在一个“意图”序列中而不对系统数据进行更新，也就是更新不就地进行。元语的最后行为是通过向意图序列添加特定的“提交”记录提交其更新的。

其二，意图的更新对系统原来的数据进行替换，使更新对于其它系统行为或事务是可见的。

如果崩溃发生在提交记录被写入后，但在所有的意图替换非易失存储器中原来数据之前，只要需要（因为可能会在恢复期间有后续的崩溃）第二阶段就会被恢复机制重启而不留下不想要的副作用。这样，恢复机制就能够通过继续进行所有更新意图完成由崩溃中断的状态转换。然后意图序列被擦除。

恢复机制能够重建由状态转换创建的新安全（输出）状态而不被故障打断。如果崩溃发生在写入提交记录之前，恢复机制只能找到或重建非易失存储器中不完整的意图序列并将其擦除。这样，恢复机制就保持了存在于崩溃中断状态转换前原来的安全（输入）状态。

为了确保以上方案能够对预期的TCB和介质故障序列起到正确的作用，非易失介质必须被设计为这样一种方式（1）恢复机制可以在崩溃后找到或重建完整的意图序列或确定意图列表是不完整的（如没有找到它的提交记录）；并且（2）写入提交记录的行动即其完成意图序列行为本身是原子化的。

为确保上面的特性（1），使用冗余存储器表示意图序列，如将同样的意图数据顺序写入一对相关的磁盘页。非易失介质上两个磁盘页被定义为配对关系，其中每一页的都以一对的形式放置从而使其在所有的“预期”故障中至少能够保存下来一个。例如，如果希望包含意图列表的冗余存储器在磁头损坏时能够使用，就应该使用双份磁盘，在第一个磁盘中的页“A”也被做为页“A”写入第二个磁盘。但是如果只是希望在磁盘读故障中能够使用冗余存储器，页“A”也可以被做为页“F(A)”写入同一个磁盘，这里“F”功能定义了两个页之间的关系。在崩溃后，只有与恢复完整意图集相关的不一致探测和重建工作被执行。应该注意到，不一致探测和重建工作被放置在TCB中的较低层次，所以这时无需关心TCB在崩溃时可能更新的各种对象特性的维护问题。

为确保上面的特性（2），应该使用单一硬件提供的110指令实施提交事务意图序列的最后磁盘写操作，这对于预期故障集来说是原子化的或探测性非原子化的。多数可用的商业硬件能够满足这个需求。

这个方案被称为映像，由Lampson和Sturgis于1976年提出概念，在［21］中有详细报告，由Xerox PARC公司在多个分布式存储系统中应用［20、23、25、27］。

4.3.3.2 日志

确保TCB元语体现事务的原子化，以及基于日志的机制假设可以使现有的非易失存储器对于预期的故障足够可靠，如使用存储器双工。使用日志时，TCB元语的每一次更新，都会在被更新对象实际在存储器上更改前，将对象原值和更新值的表示写入非易失存储器的日志中，也就是就地更新。元语最后的行为是向日志写入提交记录表示元语使命的结束。

如果系统在提交点以前崩溃，整个TCB元语，也就是事务被终止。因为日志在任何单个更新就地进行前被写入，所以只要在恢复过程中读取元语的日志记录并恢复存储在日志条目中的原值就可以取消所有的更新。无需复杂的的一致性检查。这样，恢复机制就可以保持存在于状态转换被崩溃中断前的原来的（输入）状态。这个协议在［15］中被称为“写前日志”协议并在［18］中被应用。但是，如果系统在向日志写入提交记录后崩溃，则可以使用日志记录重新进行所有TCB元语的更新。这样，仅剩的重建活动就是从日志记录恢复对象内容。

与刚才概述的日志机制类似的技术在数据库管理系统中已经使用很长一段时间了。在［14、15］和很多现有的商业数据库管理系统［18］的系统参考手册中可以找到类似日志特征的完整描述，实际中它还可以包括状态检查点和事务存储点特性。

4.3.3.3 日志和映像

日志和映像都有各自的优缺点。在［15］中有这些内容的讨论。Gray et al.指出，映像的性能特点使其成为适用于小型数据库和系统的机制，而日志适合于大型数据库系统。事实上很多系统结合两种机制以保留各种的优点［15、16］。

通常，操作系统和TCB都会维护比较小的数据库用于实施安全策略。许多现有的操作系统，如UNIX，也使用简化版的文件映像来进行原子化行为和事务。很少有操作系统因为恢复原因在TCB级应用日志。日志多数被用于TCB以外的应用级。

在文献中有关于使用映像、或映像和日志恢复机制的正确性的非形式化［21］和形式化［16］证明。这些证明仅做了故障行为的非形式化假设。

4.3.4 非原子化状态转换的恢复

许多现存的操作系统采用“乐观”的方法进行恢复。这种系统设计假设系统重启的故障很少发生。所以，对运作常规模式性能的影响以及由实施原子化行为的TCB元语造成的设计复杂性可能不用太多考虑。这种影响的严重程度还存在着一些争论。一些相关性能指标读者可以查阅参考资料［14］和［23］。

这种具有不支持原子化状态转换特性的TCB元语设计仍然帮助确保恢复机制可以重建一致的系统状态。在这一节中，我们呈现了由TCB崩溃导致的不一致性一般来源的例子，描述了能够进行一致和安全状态恢复的非原子化TCB元语的特定特性。当然，这些特性不一定要对受信恢复具有充分性。虽然可能发现其它类似的用于受信恢复的特性，但是表现非原子化TCB元语受信恢复的充分性仍然是对具体系统设计的挑战。

4.3.4.1 不一致性的来源－一个普通例子

由TCB崩溃造成的典型的不一致性出现在操作系统维护多个TCB中用于对象共享、保护和管理的相关数据结构中。例如，存储在目录中对象的用户级参考，它通常指向单一的“对象映射”（如“对象映射表”中、“主对象目录”中、“全局对象表”中、“卷内容表”中、或“I－节点空间”的一个I－节点中的一个条目）。这个映射包含定义诸如长度、状况（活动的／非活动的、锁定的／非锁定的、访问和更改的时间等）的对象属性、访问特权或参考以及由映射分配给所参考对象的内存块分配列表之类的各种字段。映射确定第二存储器中的对象表示。表示活动对象的全对象映射的一个复件被保留在主内存中。这些复件确定在活动对象缓存中的对象表示。分配给对象表示的内存块自身可能包含对其它对象的用户级参考，如当对象是目录时。

任何删除这种对象的TCB元语都必须取消和／或释放三个相关数据结构中至少两个，即对象表示和对象映射。在大多数系统中，对于被释放对象未完结的用户级参考也必须被取消或删除。基于许可的系统在这方面是个例外，因为许可做为用户级对象参考使用了系统范围的唯一标识符所以它不能被重用［12］。

在TCB元语活动期间三种相关结构类型的取消或删除（用户级参考=>对象映射=>对象表示）应该由单一的原子化行为或事务执行。类似地，任何创建对象及其参考的TCB元语活动必须在单一的原子化行为或事务中分配所有三个相关结构。TCB元语使用非原子化行为独立地分配／释放三个相关结构时，如果其中一个相关结构的分配／释放期间发生崩溃，可能会造成参考指向不存在的对象，从而引起“虚悬参考”的问题。另一种可能是这样的崩溃造成参考指向已经被分配给其它的用户对象，引起“对象重用”问题。

4.3.4.2 非原子化的TCB元语

有些TCB元语设计能够使恢复机制在无需（所有）TCB元语和（所有）对象更新具有原子化特性的情况下重建一致的状态。下面我们提供两个TCB设计特性来描述这种情况：

例子 1－在TCB元语中顺序的磁盘写入

分配和释放TCB结构的TCB元语，如以前提到的三个相关结构可以以一种防止崩溃后虚悬参考和对象重用问题的方式向非易失存储器顺序进行其写入（更新）操作。考虑一下下面的更新顺序和同步写入需求：

（1） 任何在其活动期间释放用户级参考、对象映射和对象表示的TCB元语，其所需的磁盘写入操作都应该遵循参考的指向，即包含用户级参考的对象应该首先被写入磁盘，对象映射次之，对象表示殿后。

任何在其活动期间分配用户级参考、对象映射和对象表示的TCB元语，其所需的磁盘写入操作应该遵循参考的相反指向，即对象表示应该首先被写入磁盘，对象映射次之，包含用户级参考的对象殿后。

（2） 任何在其活动期间更新用户级参考、对象映射和对象表示的TCB元语的磁盘写入操作都应该是同步的，即在磁盘写入操作完成之前不允许调用者继续执行。

考虑一下系统崩溃和后续TCB重引导的影响，就可以很容易地理解在所有相关的TCB元语中顺序进行磁盘写入的作用。假设释放对象及其最新参考的TCB元语不按照上面提到的磁盘写入操作顺序进行。在这种情况中，对象映射和表示可能会被首先释放，在包含用户级参考的对象被更新前其对应的表可能会被两个磁盘写入操作更新。

发生在两个磁盘写入操作中第一个操作完成之后的崩溃使用户级参考虚悬。这就要求恢复规程在TCB重引导前以及被释放对象的映射和表示空间释放前搜索整个目录系统以找到虚悬的参考（如果有的话）。如果不这样，或者恢复规程无法发现崩溃后的虚悬参考，系统就可能由于对象重用问题而进入不安全状态。当系统崩溃发生在对象表示释放之后但在对象映射和用户级参考删除之前，则类似的问题也会出现。

相反的，如果对象释放和参考删除需要的磁盘写入操作按照例子1中需求（1）建议的顺序进行，两个连续磁盘写入操作之间的崩溃只会造成对象或其映射变得不可访问。这可能会造成拒绝服务问题但不会是对象重用问题。

例如，崩溃可能发生在最后的用户级参考被删除后，以及对应的磁盘写入操作被完成后，但是在对象映射和表示删除所需的磁盘写入完成之前。对象表示和映射对于用户级程序都变得无法。

发生在删除用户级参考和对象映射之后的崩溃也可以造成对象的无法访问。但是，处理对象无法访问的恢复规程只需要进行“垃圾收集”操作就可以了。如果没有进行这些操作（这种操作本质上比发现所有的虚悬参考容易），或其没法找到崩溃后无法访问的对象，就可能发生拒绝服务（但是没有违反安全策略）。这个例子显示了在所有相关TCB元语中进行正确顺序的磁盘写入操作有助于降低系统崩溃后出现安全缺陷的机会。

上面关于同步磁盘写入操作的需求（2）对于保持需求（1）中建议的磁盘写入操作顺序是必须的。异步磁盘写入操作不一定能够保护这种顺序。

类似的磁盘写入顺序规则适用于参考的多叶树结构。当一个分离的ACL对象参考处于对象映射中，或与对象映射（用户级参考=>对象映射=>对象表示）暗中关联时，会在相关数据结构集（对象映射=>对象表示和对象映射=>ACL）中出现这种树结构。在这种情况中，对象表示和ACL都应该在对象映射之前被创建，并且对象映射应该在对象表示和ACL之前被删除。无法按照正确的顺序进行磁盘写入操作可能导致崩溃后外部对象ACL的重用。如果不与矫正，这样将会出现严重的访问控制问题。

例子2－TCB存储结构的冗余

维护用于关键数据结构的冗余存储器，使恢复机制能够重建一致系统状态并不是什么新奇的想法。类似的想法已经在帐务系统中的“双条目薄记”中使用，以便完成类似的目标。此外，在TCB元语的原子化行为或事务的设计方法中也是这样－正如前面章节中讨论过的那样－也使用了冗余存储结构。我们在这里建议，冗余存储结构可以只被使用于协助恢复机制探测并可能矫正不一致的TCB结构，而不一定要为所有的TCB元语提供故障的原子化特性。

虽然B3和A1安全级需要最小化的TCB，但这样很可能在其接口处只提供结构非常简单的对象，如数据段而不是文件，这些对象的在非易失存储器中的表示通常需要其它更原始的结构来维护。冗余、底层TCB结构的维护确保能够发现崩溃后不一致甚或是无法访问的对象，但不一定确保对象的更新符合原子化要求。

例如，考虑一下系统磁盘中的数据段表示包含一系列由索引页识别的不一定邻近的页（即磁盘扇区）的情况。为了使恢复机制能够探测到不一致的数据段结构，冗余结构可以独立于定义对象标识符和页之间唯一关联的索引页进行维护。所有的TCB元语将被设计为反映冗余结构中索引页的每次更新，而且反之亦然；但是，只有在成功地完成原处的磁盘写入后才能反映更新（即索引页的磁盘写入是同步的）。恢复机制将通过对索引页内容与对应的冗余结构进行比较来探测并可能矫正数据段表示的不一致性。探测两个结构中哪一个受到了故障影响的附加能力，以及确保两个结构中至少有一个在所有预期的故障后可以使用的能力使恢复机制可以在需要时矫正两个结构中的任何一个。

数据段表示结构的冗余不能保证数据段内容在内部将是一致的，也不能保证它们将与其它数据段内容保持一致。例子2中建议的冗余结构的维护不能为TCB元语故障的原子化提供保证，虽然类似的结构可以被用做实施故障原子化附加机制的基础［23］。

4.3.4.3 恢复规程的幂等性

恢复规程应该在重复的崩溃后具有可重启性，并且其中每一次重启，TCB都应该被放置在不坏于以前的状态。这种特性被称为幂等性，无论TCB使用有何种类型的磁盘写入或冗余这种特性都应该存在。恢复规程的重复崩溃将不会对系统的TCB产生任何不想要的副作用。虽然支持原子化TCB元语和事务的系统其恢复规程也必须具有幂等性，但是这些规程幂等性的证明似乎比不支持TCB元语故障原子化的系统简单得多。在［21］中提供了使用4.3.3.1中讨论的 “意图集”的恢复机制的幂等特性。

4.3.4.4 非原子化系统元语的恢复

例子1－UNIX文件系统

同步磁盘写入操作的顺序由UNIX内核执行［1］。例如，每当“UNLINK”元语删除对象的最后链接并释放对象时，以及每当“CREATE”元语分配一个对象并在目录中放置一个它的参考时，就如4.3.4.2节中建议的那样安排磁盘写入操作的顺序并同步执行这些操作。在UNIX中，由目录条目中I－节点数字表示的用户级参考，由I－节点表示对象映射，并由磁盘块表示对象表示。参考资料［1,ch5］描述了不顺序进行磁盘写入操作以及不同步进行的负面影响。

UNIX的“FSCK”程序也是典型的恢复程序例子。FSCK探测虚悬I－节点和I－节点数字、与相同磁盘块关联的重复I－节点、不平衡I－节点参考和对象链接，以及遗失的和被破坏的I－节点和磁盘块。但是，对于虚悬I－节点和I－节点数字、与相同磁盘块关联的重复I－节点、不平衡I－节点参考和对象链接，“FSCK”需要管理用户的干预来解决不一致性。如［5］中指出的那样，管理员很少情况能够得到足够的信息做出正确决策并解决不一致性。［5］中提出的更改建议将有助于管理员作出底层恢复决策。所以，不仅非原子化系统元语应该被设计为支持恢复，而且恢复机制也应该能够支持管理员做出正确的恢复决策。

例子2－剑桥文件服务器

剑桥文件系统（CFS）实际上实施了单个文件的故障原子化更新［23］。虽然由CFS提供的机制是磁盘冗余的好例子，但是它只被用于保证恢复机制可以重建一致的文件结构而不一定保证文件内容。

在CFS中，磁盘中文件的表示包含一个或多个指向数据页的索引页。文件可以被视为单根树，它的节点是索引页而叶子是数据页。CFS维护一个被称为柱映射的冗余结构，该结构表示文件标识符、文件页之间的关系以及每个磁盘柱的所有对象的页状态。每个柱映射条目包含（1）所定义页的归属文件的唯一标识符，（2）由文件表示中的页占据的树地址，以及页的位置和使用状态。这样，每个磁盘页被其在柱映射中的条目和其在表示结构的页树中的位置定义。

CFS元语只在文件树被一致更新后更新柱映射。这样，CFS恢复规程就可以在崩溃产生的故障后使用冗余信息重建文件系统结构。例如，每当崩溃损坏了一个文件索引页，恢复机制就搜索柱映射来发现属于该文件的所有页。在搜索结束时，由被损坏的索引页指向的所有页及其树位置都被找到，被损坏的索引页就可以被重建了。反过来，每当柱映射被崩溃损坏，恢复机制就从文件系统根开始检查每个文件结构来发现所有属于被损坏柱映射的磁盘页。在搜索结束时，被损坏的柱映射被重建，搜索范围可能包括整个文件系统，在当前磁盘技术条件下可能要花费半个小时时间。

CFS的柱映射被用于附加功能，包括保持意图集的页状态信息。虽然在提供实施原子化行为的可恢复存储器中，柱映射冗余功能的使用不如映像页［23］的使用那样成功，但是这个功能在文件系统结构自动化恢复方面的使用还是非常适当的。

例子3－选择性原子化

对不使用原子化TCB元语的安全状态进行恢复的另一个方法是“选择性原子化”。选择性原子化意味着在TCB对象的特定子集上运作时，只有TCB行为的一个子集是原子化的。意图是保护某些对象和对象等级序列表现的一致性，但不一定是对象内容的一致性。当对象内容与安全相关时，对象内容的一致性就留给特殊的程序处理了。特殊的原子化机制维护安全相关对象－所有系统对象中的一小部分内容的一致性。

使用选择性原子化方法的优点是避免了全原子化对性能的影响，并且安全状态的系统恢复也比较简单。例如，恢复程序可以恢复文件系统的结构（包括目录、磁盘块和物理记录的索引）、最小化管理干预－这是在大多数安全程序诸如“FSCK”中所没有的特性。

选择性原子化存在于AIX系统3.1版中。在这个系统中，通过对包含目录、I－节点和非直接文件块的数据段实施原子化更新而得到了一个相当强壮的文件系统。任何对磁盘块分配映射的更改也是原子化的［6］。原子化特性的实施是基于使用被称为“数据库内存”概念的日志，因为它与数据库管理系统的日志特性有类似之处［7］。应该注意的是，AIX3.1中实施的选择性原子化不涉及非内核对象（如由系统进程实施的对象）。这样，使用AIX3.1内核的TCB将不得不在行为需要时继续进行受信进程内的原子化或恢复性行为。

4.4 受信恢复的设计选项

受信恢复机制和规程的设计和实施应该包括以下通用型选项：

（1） 对于所有状态转换故障集，TCB恢复代码应该确保安全输入状态的恢复，即清除所有违反安全不变式的安全状态的临时更改。
（2） 对于预期的TCB或介质故障集（由系统设计者进行适当选择），引起状态转换的TCB代码应该被设计为在所有可能的情况下使安全状态转换原子化，即恢复机制既应该重建这些转换的安全输入状态也应该重建其安全输出状态。
（3） 对于在预期的TCB或介质故障情况中状态转换不是原子化的子集，恢复机制应该探测这些转换给TCB留下的不安全状态。TCB支持的管理工具应该在有或没有管理用户干预的情况下使预期的安全状态得以重建。这个状态可能不同于这样的故障期间状态转换的安全输入和输出状态。
（4） 对于“非预期”或罕见TCB和介质故障补集，其管理规程和工具（用于恢复预期安全状态）应该被定义和制作成文档。这个安全状态也可能不同于这样的故障期间安全转换的安全输入和输出状态。

上面的选项（3）和（4）建议，由自然发生的事件或用户、管理员、或操作员引入的中断造成的预期TCB或介质故障可能产生安全状态，但其仍违反用户应用的完整性和可用性需求。很明显，如果恢复后的状态既不同于故障发生期间的安全输入状态也不同于其安全输出状态，则有可能产生“遗失”更新和“脏”读取［13、14］。但是，选项（3）和（4）在TCSEC的系统评测中还是可接受的，因为TCSEC不包括应用的完整性和可用性需求。

如果用户应用要求比TCB所支持的更高水平的完整和可用性，它们总是可以实施附加的、单独的恢复机制。事实上，这种方法被大多数当前应用采用，其中包括数据库管理系统［14、15］。这种方法从系统体系的观点来看也是不错的，因为它分离了应用和TCB的恢复机制。TCB中应用级恢复的支持不是必要的和得到保证的。不必要是因为应用的可移植性不信赖特定TCB的恢复特性，这样应用就倾向于实施其各自的恢复特性了。不能得到保证是因为它违反了TCB对B3－A1安全级的最小需求并且增加了保证的负担。

受信恢复需要用于安全系统设计的状态转换模型，既包括状态不变式也包括转换约束。只包括状态不变式的模型是不够的，因为受信恢复需要满足状态转换约束（即3.2节中讨论的情况）。类似地，只包括转换约束的模型是不够的，因为非预期故障和运作中断的发生可能使系统无法完成状态转换，并将其置于不安全的状态。这些状态只能在检查了安全状态不变式是否被满足后才能确定其是否安全（即3.1节中讨论的情况）。

读者应该注意到，安全策略的状态转换模型特别适合于受信恢复机制的设计。因为这些模型包括了安全状态和安全状态转换的概念，它们可以被集成到恢复模型中，都可以使用状态和状态转换（可能有所差异）术语进行定义。不像状态转换模型那样，信息流和非干涉模型没有明确包括状态和状态转换的概念，这样使用它们来形式化定义受信恢复概念就比较困难，如果不是不可能的话。另外，信息流和非干涉模型涵盖了非任意访问控制，并缺乏任意访问控制和其它策略组件。这造成使用这种模型进行受信恢复的形式化定义变得不切实际了。

5.0 其它TCSEC需求对受信恢复的影响

TCSEC的安全策略和职能需求只是间接与受信恢复相关。也就是，这些可能与受信恢复相关领域的特定需求已经被受信设施管理功能和接口所涵盖［24］。在本章中，我们仅关注特定于受信恢复的TCSEC领域，我们讨论特定需求的相关性和不相关性。

5.1 运作的保证

TCSEC的大多数保证需求适用于受信恢复，因为受信恢复代码是系统TCB代码的一部分。由于受信恢复功能的接口对用户不可见，或可见时只能由受信设施管理授权的管理人员使用，所以一些TCSEC保证需求就变得无关了。受信恢复接口的用户可见性，或其缺乏，是建立在受信设施管理的保证需求之下［24］，所以我们这里就不再重复了。

在运作的保证领域中，只有受信设施管理和系统体系领域有与受信恢复相关的特定需求。因为系统完整性需求涉及到TCB硬件和固件部分的诊断测试，所以除了可能包括恢复机制的硬件／固件以外就没有什么特定的相关内容了。由受信恢复提供TCB接口的隐蔽信道分析是不必要的。

管理用户是唯一可能用到受信恢复机制的用户。他们对系统和用户数据进行多种级别的访问，并且得到信任在运行时以管理角色维护数据秘密且不会利用隐蔽信道。这样，管理用户必须获得系统现有的最高数据级的许可。另外，所有实施受信恢复功能的代码应该被仔细审查以尽最大可能确保这些功能不包含任何木马或陷门。

多数TCB的系统体系需求适用于受信恢复代码。例如，实施受信恢复的TCB程序和数据结构必须符合以下需求：

a. 满足模块性需求。
b. 大量使用抽象和信息隐蔽。
c. 使用层次化恢复功能。
d. 尽最大可能满足最小特权原则的需求。

因为所有分段的或不分段存储器都必须对恢复代码可用，所以受信恢复大多被用于维护模式中，大多数保护机制被禁止。这样，最小特权原则的应用和尽量逻辑化地使用具有分离属性的独特对象在这里就不如机制在系统运作的常规模式中使用那么显而易见了。

仅有的影响受信恢复的受信设施管理需求是将安全相关和不相关的管理功能隔离。因为受信恢复功能显然是安全相关的，所以它们必须被分配给系统管理员或系统程序员角色［24］。

5.2 生命周期保证

与运作的保证相反，生命周期保证的所有领域都与受信恢复有关。这些领域是安全测试、设计的规格说明和验证、配置管理，以及受信分配。

5.2.1 安全测试

测试受信恢复机制的目的是发现设计和实施的错误，这些错误使故障恢复置TCB于不安全状态。这个领域的主要议题是划定安全测试的范围，即将安全测试的主要目标和实践与实际可能发生的故障和操作中断有限的覆盖范围协调一致。

为了达到安全测试的主要目标,应使用TCB以外的测试装置执行安全测试，测试应无需TCB装置，并且是可重复的，应包括精确的覆盖分析。为了测试受信恢复功能，只有B3级需求是相关的，因为如［24］中讨论的那样，形式化高级规格说明对于受信恢复是不必要的。

但是，只有状态转换故障和运作中断（而不是所有的TCB和介质故障）能够以可重复的方式和无需任何TCB装置的条件下在TCB以外产生。每当TCB和介质故障不能以可重复的方式和无需任何TCB装置的条件下在TCB以外产生时，就需要对设计和实施进行分析与检查来确定恢复机制是否能够处理未经测试的故障响应。可以使用与其它TCB领域安全测试所使用的类似的测试计划的结构和程序来产生状态转换故障，如测试安全策略的执行和隐蔽信道的带宽。

使用管理接口可以产生运作中断，这种方式至少可以重复产生一些TCB故障，并可能产生介质故障。相反的，自然的TCB和介质故障在不使用TCB软件和硬件装置的条件下无法再现。使用这样的装置将违反安全测试的主要目标之一。让我们回忆一下不希望使用TCB装置原因，这是因为我们不能在常规模式配置中测试系统，而且它还可能使测试装置变为TCB中的陷门。所以，受信恢复功能的测试局限于使用测试计划，即测试条件、数据、以及只涵盖第2章定义的状态转换故障和运作中断的覆盖分析。在这种受限条件下，所有常规安全测试需求和要求都是适用的。

5.2.2 设计规格说明和验证

由于从本质上无法形式化定义TCB故障和运作中断模型（也就是在本指导方针第2章和参考资料［21］中讨论的），以及由于通常缺乏受信设施管理和管理角色的模型的原因，使TCSEC对形式化策略模型对应的高级规格说明的需求与受信恢复无关。但是，使用安全策略模型和更精确状态机的需求在两个领域与受信恢复有关。

首先，状态机模型使设计者和实施者能够定义安全系统状态和状态转换的概念。这些概念对于受信恢复是很关键的，因为它们提供了恢复机制应该满足的安全不变式和约束。只有它们满足了这些不变式和约束，恢复功能才能取得信任，正如第4章讨论过的那样。

其二，TCB元语对状态转换故障（在第2章定义的）的响应使用了形式化安全策略模型并由高级规格说明设定。例如，Bell-La Padula模型尝试通过对TCB请求（Rk）的TCB响应集（Dm）“错误”和“？”元素来建立这些故障的模型，这个模型虽然还不完整，但是已经很清晰了。这样，因为受信恢复的原因，TCB元语在状态转换故障响应期间的错误消息和异常的规格说明也是需要的。

5.2.3 配置管理

B3和A1级的所有配置管理需求按规定应用。

5.2.4 受信分配

B3和A1级的所有受信分配需求对于实施受信恢复的TCB功能和接口按规定应用。

5.3 文档

大多数B3和A1级的文档需求在每个评测级中按规定应用。但是，一些需求，如对于安全特性用户指南（SFUG）和隐蔽信道文档方面的规定明显是无关的。SFUG只在受信恢复仅是系统管理员的责任这一点上与非管理用户相关。管理员得到有关其不会泄漏保密和私有信息的固有信任，他们可以不必使用隐蔽信道而直接获得这些信息。

5.3.1 受信设施手册

受信设施手册（TFM）不仅与受信恢复有关而且非常重要。TFM必须包括“在任何系统操作失误后继续安全系统操作”的规程描述。这样，TFM就应该包括TCB故障和操作中断的类型描述和规程、工具、警告清单以及如何可能最好地处理这些故障的例子。

所有的TCB恢复规程必须在TFM中定义。这些规程包括分析系统崩溃后的“转储”、崩溃恢复和重启行为、检查TCB文件和目录的一致性、更改系统配置参数（如表规模、设备和设备驱动器等）、运行定期的系统完整性检查以及修复对象的不一致性和受损的标签。得到批准使用的TCB恢复工具、相关命令、异常、警告和建议清单也应该在TFM中。

5.3.2 测试文档

受信恢复测试文档包括测试计划、测试项目和测试结果的文档。受信恢复测试计划和测试结果与其它所有的测试计划和结果的主要结构是一样的。例如，测试计划应该包含测试条件部分、测试数据部分（即包括测试环境的建立、测试参数和预期的测试输出）、以及测试覆盖分析。

但是，这些部分的内容在本质上与其它测试计划不同。例如，测试条件中应该确定使用管理接口产生当前测试的运作中断类型（以及所引入的TCB或介质故障）。在测试数据领域，环境建立应该定义系统的初始化数据，包括TCB和用户级数据结构和对象，这些数据是产生所设定的运作中断需要的。管理员所使用的产生运作中断的参数和命令应该被列出。

测试的输出应该包括自动化（如重引导、温启动）规程和受信恢复的人工（如冷启动、紧急重启）规程的规格说明及其在系统上的预期结果。覆盖分析应该使用测试涵盖的中断类型和由于无法通过管理行为引入的未覆盖的自然故障类型来说明测试的范围。

5.3.3 设计文档

受信恢复的设计文档应该包括以下对应TCSEC的B3和A1级需求的条目：

a. 受信恢复通过自动化或使用管理规程要处理的预期故障和操作中断类型描述。
b. 受信恢复的基本方法（如在TCB元语设计中使用故障原子化，使用能够恢复安全状态的非原子化行为，恢复后的安全状态类型－转换的输入安全状态和输出安全状态或一些任意安全状态）。
c. 关于无法使用常规方式处理的“非预期”故障的警告。
d. 受信恢复维护的状态安全不变式和约束。
e. 实施受信恢复功能的TCB元语的描述性高级规格说明（DTLS）。

设计文档的精确性应该与B3和A1级系统其它类似的文档相当。在这个领域里，B3和A1级需求之间没有本质的区别。在设计规格说明和验证领域的这些内容因为同样的原因也是这样。

6.0 满足TCSEC需求

在TCSEC中，没有B3级以下安全级别在受信恢复方面的需求。另外，在受信设施需求之中已经包括了也可能适用于受信恢复的安全策略和职能需求［24］。本章只包括特定于受信恢复的附加需求和建议。

6.1 B3安全级的需求

6.1.1 运作的保证

6.1.1.1 系统体系

实施受信恢复的TCB程序和数据结构必须满足以下需求：

a. 满足模块化需求。
b. 大量使用抽象、信息隐蔽、以及在实施受信恢复功能的设计和应用中使用层次化方法。

6.1.1.2 受信设施管理

受信恢复功能应该只被设定给负有安全相关责任的管理人员，如系统程序员或安全管理角色［24］。

6.1.2 生命周期保证

6.1.2.1 安全测试

B3级的安全测试需求适用于处理用户引入故障的TCB功能和接口以及管理角色的功能和接口而不仅仅是管理人员产生的中断。参加5.2节的讨论。

6.1.2.2 设计规格说明和验证

实施受信恢复的TCB功能和接口的DTLS必须得到维护，使用异常、错误消息和影响来全面和精确地描述这些功能和接口。

a. 形式化安全模型应该被用于定义TCB对状态转换（在第2章得到定义在5.2节讨论的）的响应。
b. 形式化安全模型应该被用于受信恢复设计的安全策略不变式和约束的导出。
c. 附加的不变式和约束应该被用于受信恢复在职能领域所需的设计。

6.1.2.3 配置管理
B3级的所有配置管理需求在受信恢复中按照规定应用。

6.1.3 文档

6.1.3.1 受信设施手册

以下条目应该被包括在受信设施手册的受信恢复部分：

a. 用于系统转储分析、用于TCB对象一致性检查以及用于系统冷启动和紧急重启的规程。
b. 容错故障类型描述和响应类似故障的建议规程的例子。
c. 用于在TCB数据库上运行定期完整性检查和用于修复受损安全标签的规程。
d. 处理系统对象不一致性的规程（如对象磁盘块重复分配、不一致的对象链接）。
e. 受信恢复的命令、系统调用、以及功能定义清单（当这些内容没有被包括在系统DTLS中时）。
f. 受信恢复规程的例子、相关警告和潜在错用情况。

6.1.3.2 测试文档

所有B3级测试文档需求，除了用于隐蔽信道测试（5.1节中提到）的之外，都按照规定在实施受信恢复的TCB功能和接口中应用。受信恢复的测试计划应该包括以下内容：

a. 测试条件，即可以通过管理接口产生的运作中断及其对系统的影响清单。
b. 测试数据，包括以下内容：

(1) 环境建立，如产生计划内的中断所需的TCB和用户级数据结构和对象。
(2) 由管理员用来产生中断的参数和命令。
(3) 预期的输出，如处理所产生的中断的自动或人工启动的规程类型以及这些规程对系统状态的影响。

c. 覆盖分析，如这包括故障或故障类型清单，它们的影响涵盖于所产生的中断，以及其影响没有涵盖于测试中的自然故障或故障类型。

6.1.3.3 设计文档

设计文档应该描述下面的内容：

a. 实施受信恢复功能的TCB模块之间的接口。
b. 用于确保受信恢复功能仅供管理用户使用的TCB特定保护机制。
c. 实施受信恢复接口的TCB模块的DTLS；受信恢复接口并不需要形式化高级规格说明（FTLS）－相关管理接口的讨论在［24］中提到。

设计文档还应该包括以下内容的描述：

a. 自动化或使用管理规程的受信恢复所处理的故障和运作中断的预期类型。
b. 受信恢复的主要方法，在5.3节中提到。
c. 关于无法通过常规方式处理的“非预期”（即罕见的）故障的警告。
d. 受信恢复维护的状态安全不变式和约束。
e. 实施受信恢复接口的TCB元语的DTLS。

设计文档应该与B3和A1级其它类似文档的精确性相当。

6.2 A1安全级的附加需求

这里包括B3安全级的所有需求。下面的是附加的生命周期保证领域的需求。

6.2.1 附加的生命周期保证需求

6.2.1.1 配置管理

按照规定应用所有的A1级配置管理需求。

6.2.1.2 受信分配

按照规定对实施受信恢复的TCB功能和接口应用所有的A1级受信分配需求。

术语表

访问

主体和对象之间导致信息从一方向另一方流动的特定交互类型。

管理员

参见安全管理员。

批准／鉴定

基于对系统硬件、固件和软件的安全设计、配置和实施以及其它系统规程、管理、物理、防电磁泄漏、人事和通讯安全控制的全面安全评测而允许ADP系统处理其运作环境中敏感信息的官方授权。

审计

对系统记录和活动进行独立检查和检验。

审计员

具有包括选择系统中受审计的事件、执行系统操作以便能够记录这些事件，并分析审计事件跟踪在内管理任务的，得到授权的人员或角色。

审计机制

用于收集、检查和／或检验系统活动的一个或多个设备。

审计跟踪

能够对操作、规程或事务从开始到最终结果的主要和相关环境因素及活动进行重建、检查和检验的，对系统活动充分和顺序的记录。

类别

做为加强数据保护和进一步限制数据访问的手段，用于保密和非保密数据的限制性标签。

崩溃

造成系统处理器的寄存器对一些标准值重置的系统故障。

数据

具有特定物理表现的信息。

描述性高级规格说明（DTLS）

使用自然语言（如英语）撰写的高级规格说明，非形式化的程序设计概念，或两者的结合。

任意访问控制（DAC）

基于用户、进程和／或其归属组的身份和需知原则，或基于对包含对象特权（如能力）受系统保护标签的占有的，一种限制对象访问的方法。拥有具体访问许可的主体具有将许可（也许是非直接地）传递给任何其它主体的能力，在这种意义上，该控制是任意的。

形式化安全策略模型

安全策略精确的数学陈述。为了足够精确，这样的模型必须表示系统的初始状态，系统从一个状态进行到另一个状态的方式，以及系统“安全”状态的定义。为了使其做为TCB的基础具有可接受性，模型必须被形式化证明所支持，应证明如果系统的初始状态满足“安全”状态的定义，并且如果所有模型所需的假设都成立，那么系统未来的状态将是安全的。一些形式化模型技术包括状态转换模型、指称语义模型和代数规格模型。

形式化高级规格说明（FTLS）

使用形式化的数学语言撰写的高级规格说明，能够使定理显示系统规格说明与其假设的形式化需求的对应关系并予以形式化证明。

幂等性行为

如果行为清单中反复未完成的执行后面有一个已完成执行，并具有行为清单单一完成执行的效果，则这个顺序化的行为（如规程调用等）清单被说成具有幂等性。幂等性行为是可重启的行为，即如果行为在崩溃时处于进行过程中，行为可以在崩溃恢复期间重复而没有不想要的副作用［14、21］。

对象

包含或接收信息的被动实体。访问对象潜在地意味着访问其包含的信息。对象的例子是：记录、块、页、段、文件、目录、目录树、程序、比特、字节、字、字段、处理器、视频显示、键盘、时钟、打印机和网络节点等。

操作员

被设定执行ADP系统的常规维护操作并响应常规用户请求的管理角色或用户。

口令

用于认证身份的受保护／秘密的字符串。

进程

执行中的程序。

读取

仅造成信息从对象向主体流动的基本操作。

安全管理员

负责自动化信息系统的安全并有权对所有其它访问自动化信息系统的人（可能不包括审计员）执行安全防范措施的管理角色或用户。

安全级别

等级保密序列和表示信息敏感性的非等级类别的组合。

安全映射

定义安全级别的二进制和ASCII格式之间对应关系的映射（如安全级别的二进制格式和敏感标签之间）。

安全策略

规范机构如何管理、保护和分配敏感信息的法律、规则和实务系列。

安全策略模型

安全策略模型的表达由系统执行。它必须确定规范系统如何管理、保护和分配敏感信息的规则和实务。

安全测试

用于确定系统安全特性是否根据设计进行实施的过程。这包括具体操作的功能测试、入侵测试和验证。

主体

通常以人、进程或设备形式出现的主动实体，它导致信息在对象之间流动或改变系统的状态。从技术上是一个进程／域对。

系统程序员

负责受信系统分配、配置、安装和非常规维护的管理角色或用户。

高级规格说明（TLS）

系统行为在最抽象级别的非规程性描述，功能规格说明通常忽略所有的实施细节。

陷门

能够得以激发使系统安全机制被绕过的隐藏软件或硬件机制。它会以一些看上去无害的方式被激活（如终端的一个特定“随机”击键序列）。软件开发者经常在其代码中引入陷门使其能够重新进入系统并执行一定的功能。与后门是同义词。

木马

具有表面上或实际上有用的功能的但含有附加（隐藏）功能的程序，其中隐藏功能暗中破坏确定安全调用进程的合法授权。例如，为木马创造者制作敏感文件的“秘密复件”。

受信计算基（TCB）

计算机系统中保护机制的统称－包括硬件、固件和软件－这些的组合负责执行安全策略。一个TCB包括一个或多个组件一起执行产品或系统的统一安全策略。TCB正确执行统一安全策略的能力只依赖于TCB内的机制以及系统管理人员正确输入与安全策略相关的参数。

用户

通过直接（即通过终端）或间接（即准备输入数据，或接收不由负责人员对内容或保密情况进行检查的输出）的连接访问自动化信息系统的人或进程。

验证

比较两个级别的系统规格说明的适当对应关系的过程（如安全策略模型与高级规格说明，TLS与源代码，或源代码与目标代码）。这个过程可以是也可以不是自动化的。

写入

仅造成信息从主体向对象流动的基本操作。

参考书目

[1] Bach, M. J., The Design of the UNIX Operating System, Prentice-Hall Inc., Englewood Cliffs, New Jersey, 1986.

[2] Baldwin, R. W., Rule-Based Analysis of Computer Security, Massachusetts Institute of Technology, Cambridge, Massachusetts, Technical Report MIT/LCS/TR-401, March 1988.

[3] Bell, D. E., and L. J. La Padula, Secure Computer System: Unified Exposition and Multics Interpretation, MITRE Corp., Bedford, Massachusetts, Rep. No. MTR-2997, 1976. Available as NTIS AD-A023 588.

[4] Benzel, T. V., and Travilla, D. A., “Trusted Software Verification: A Case Study,” Proceedings of the IEEE Symposium on Security and Privacy, Oakland, California, April 1985, pp. 14-30.

[5] Bina, E. J., and P. A. Emrath, “A Faster fsck for BSD UNIX,” in Proceedings of the USENIX Conference, San Diego, California, February 1989, pp. 173-185.

[6] Chang, A., M. Mergen, S. Porter, R. Rader, and J. Roberts, “Evolution of Storage Facilities in the AIX System,” in IBM Risc System/6000 Technology, SA23-2619, IBM Corporation, Austin Communications Department, 11400 Burnet Road, Austin, TX 78758, pp. 138-142.

[7] Chang, A., and M. Mergen, “801 Storage: Architecture and Programming,” ACM Transactions on Computer Systems, vol. 6, no. 2, February 1988, pp.2-50.

[8] Cristian, F., “Correct and Robust Programs,” IEEE Transactions on Software Engineering, SE-10/2, March 1984, pp. 163-174.

[9] Cristian, F., “A Rigorous Approach to Fault-Tolerant Programming,” IEEE Transactions on Software Engineering, SE-11/1, January 1985, pp. 23-31.

[10] Department of Defense, Security Requirements for Automated Information Systems (AISs), DoD Directive 5200.28,21 March 1988.

[11] Gasser, M., Building A Secure Computer System, Van Nostrand Reinhold, New York, 1988.

[12] Gligor, V. D., J. C. Huskamp, S. R. Welke, C. J. Linn, W. T. Mayfield, Traditional Capability-Based Systems: An Analysis of their Ability to Meet the Trusted Computer Security Evaluation Criteria, Institute for Defense Analyses, Alexandria, VA. IDA Paper P-1935, February 1987; available as NTIS AD-B119332.

[13] Gligor, V. D., “A Note on the Denial-of-Service Problem,” Proceedings of the 1983 IEEE Symposium on Security and Privacy, Oakland, California, April 1983, pp. 5101-5111.

[14] Gray, J. N., “Notes on Database Operating Systems,” in Operating Systems—An Advanced Course, R. Bayer, R. M. Graham, and G. Seegmuller, eds., Springer-Verlag, New York, 1978, pp. 393-481. Also published as IBM Research Report RJ 2188, February 1978.

[15] Gray, J. N., Paul McJones, Mike Blasgen, Bruce Lindsay, Raymond Lorie, Tom Price, Franco Putzolu, and Irving Traiger, “The Recovery Manager of the System R Database Manager,” Computing Surveys, 13/2, June 1981, pp.223-242.

[16] Hecht, M. S., and Gabbe, J. D., “Shadowed Management of Free Disk Pages with a Linked List,” ACM Transactions on Database Systems, 8/4, December 1983, pp. 503-514.

[17] National Computer Security Center, Department of Defense Trusted Computer System Evaluation Criteria, DOD 5200.28-STD, December 1985.

[18] IBM Corp., “Information Management System/Virtual Systems (IMS/VS), Programming Reference Manual,” IBM Form No. SH20-9027-2, Section 5.

[19] IBM Corp., Secure Xenix, Version 1.1—System Administrators Guide, June 1987.

[20] Israel, J., J. Mitchell, and H. Sturgis, “Separating Data from Function in a Distributed File System,” Proceedings of the Second International Symposium on Operating Systems, IRIA, Rocquencourt, France, October 1978.

[21] Lampson, B. W., “Atomic Transactions,” in Distributed Systems—an Advanced Course, B. W. Lampson, M. Paul, and H. J. Siegert, eds., Springer-Verlag, New York, 1981, pp. 246-265.

[22] Lampson, B. W., Robert F. Sproull, “An Open Operating System for a Single-User Machine,” in Proceedings of the Seventh Symposium on Operating Systems Principles, Pacific Grove, California, December 1979, pp. 98-105.

[23] Mitchell, J. G, and J. Dion, “A Comparison of Two Network-Based File Servers,” Communications of the ACM, 25/4, April 1982, pp. 233-245.

[24] National Computer Security Center, A Guide to Understanding Trusted Facility Management, NCSC-TG-015, version 1, 18 October 1989.

[25] Paxton, W. H., “A Client-Based Transaction System to Maintain Data Integrity,” Proceedings of the Seventh Symposium on Operating Systems Principles, Pacific Grove, California, December 1979, pp. 18-23.

[26] Saltzer, J. H., “Protection and Control of Information Sharing in Multics,” Communications of the ACM, vol. 17, no. 8, July 1974, pp. 388-402.

[27] Swinehart, Daniel, Gene McDaniel Boggs, “WFS: a Simple Shared File System for a Distributed Environment,” Proceedings of the Seventh Symposium on Operating Systems Principles, Pacific Grove, California, December 1979, pp. 9-17.

[28] Walker, S. T., “The Advent of Trusted Computer Operating Systems,” National Computer Conference Proceedings, May, 1980, pp. 655-665.

[29] Walter, K. J., W. F. Ogden, W. C. Pounds, F. T. Bradshaw, S. R. Ames, K. J. Biba, J. M. Gilligan, D. D. Schaefer, S. l. Schaen, D. G. Shumway, Modeling the Security Interface, Technical Report, Case Western Reserve, University, Cleveland, Ohio, August 1974.