资源目录

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

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

英文版PDF 中文版PDF

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

1. 介绍

国家计算机安全中心（NCSC）的主要目标是促进受信计算机系统的推广。为了支持这一目标创建了一项基准，《国防部受信计算机系统评测标准（TCSEC）》，据此对计算机系统进行安全评测。TCSEC最早于1983年8月15日以CSC-STD-001-83的形式出版。在经过一些修改后，国防部于1985年12月予以采纳，并做为国防部标准DoD 5200.28-STD。因为其它原因撰写的国防部5200.28指令，《自动化信息系统（AIS）的安全需求》要求在整个国防部范围内使用《国防部受信计算机系统评测标准》。TCSEC是用于评测AIS中建立的安全控制效率的标准。TCSEC被分为四个部分：D、C、B和A，这些部分以等级形式排列并且最高部分（A）被保留用于可得到的、提供最佳保证级别的系统。C和B部分中有被称为级的分部分，它们也以等级形式排列以代表不同的安全级别。

1.1. 目的

出现在B2到A1级中的一项重要的TCSEC保证需求是受信设施管理。它涉及到用于安全系统配置、管理和运作的规程、角色、功能（如命令、程序、接口）、特权和数据库。

受信设施管理的目标是支持整个系统运行期间的安全和职能政策。为了达成这个目标，两项关键的需求是，在B2级中对管理员和操作员功能的分离，以及在B3级中对系统管理员的安全相关和非安全相关功能的分离。对管理员和操作员功能的分离，以及对系统管理员的安全相关和非安全相关功能的分离也适用于A1级。这些分离帮助确保人为错误、过失和系统故障造成的负面安全影响不会影响到管理功能和数据。

《理解受信设施管理的指南》的目的是为厂商提供指导，以便其了解如何将受信设施管理功能融入其系统；为系统评测者和审批者提供指导，以便其了解如何评测受信设施管理的设计和实施；为最终用户提供指导，以便其了解如何有效使用这些功能的，如怎样避免系统管理的常见隐患。

1.2. 范围

这里提供的受信设施管理指导方针，涉及到与TCSEC的B2到A1级中一项重要保证需求相关的管理功能、接口和规程的分离。本指导方针试图提供关于受信设施管理设计方面的讨论。

本指导方针还包含另外五个部分。第2部分包含管理角色固有的缺陷概述。第3部分叙述了影响到受信设施管理功能的设计和实施的TCSEC需求，并包括对应每一个评测级的建议。第4部分回顾了TCSEC中叙述的受信设施管理的主要需求。第5部分介绍了管理员和操作员功能的分离，以及有可能将管理员和操作员的安全相关功能分割成不同的角色、功能和数据库的情况。第6部分讨论了其它TCSEC需求对受信设施管理的影响，包括受信设施管理的设计和模型化的选择。

这里不涉及的内容是人事安全措施、自动化信息系统设备的物理安全，以及AIS以外的其它管理措施。对这些措施的评测超出了TCSEC评测的范围［12,p.87］。本指导方针适用于建立或修改想要满足TCSEC需求的计算机系统、处理环境和产品。注意，本文所包含的由TCSEC目标导出的意见和建议并不是TCSEC所要求的。所提出的附加建议是由TCSEC所叙述的目标导出的。

1.3. 控制目标

受信设施管理是运作保证的一个领域。因此，受信设施管理是“保证”目标的一个方面。TCSEC中所描述的保证目标是：

“用于处理保密或其它敏感信息的系统，必须被设计为保证安全政策的正确和准确解释，并且不得歪曲政策的本义。必须提供保证以便能够在系统的整个生命周期中正确地实施和执行政策。”

此目标以两种方式影响到受信设施管理。首先，系统的管理角色是帮助确保系统安全政策执行的要件，所以其功能必须支持政策的意图。其二，管理角色必须满足正确的实施和执行的生命周期保证需求。

2. 安全管理－问题

受信设施管理的弱点是角色特定的和对于所有管理角色共有的。对共有的管理角色和角色特定弱点进行仔细检查对于系统设计者和管理员是重要的，因为通过特定的设计或目标系统的外部管理规程可以减少或消除这样一些弱点的暴露。对两种类型弱点的区分也有助于增强有选择地支持不同角色的机制和规程。

下面讨论的这些一般意义上的弱点不特定于任何特殊的系统或设计。在设计和实施特定系统以识别特定的附加弱点及其所需的应对措施时应该进行仔细的分析。设计、实施和使用用于分析特定系统弱点的自动化工具是有效的，但这只是一项研究课题［1］。

在不同程度上影响所有管理角色的三种弱点是：

（1）对硬件和软件系统配置的非受权修改，对系统配置的非受权更改，包括在系统生命周期所有阶段可能发生的对硬件和软件的更改。

（2）突破特定的管理角色。由非管理用户，或由非受权管理用户对管理角色的突破通常是由识别和认证、TCB保护或角色分离机制的错误和弱点导致的。

（3）滥用管理授权。这可以由对管理授权的无意或蓄意滥用引起。授权的滥用既可能由TCB也可能由用户的安全违规造成，所以可以导致广泛的损害。

3. 受信设施管理的TCSEC需求

在TCSEC中，对于B2到A1安全级有多条受信设施管理需求。C1到B1级没有受信设施管理需求。

3.1. B2安全级的需求

3.1.1. 安全政策

没有附加的需求。

3.1.2. 职能

B2级所有的识别和认证需求，包括受信路径都必须逐一应用于管理用户。

管理用户的所有行为都必须是可以按照B2级审计需求进行审计的。

3.1.3. 运作的保证

3.1.3.1. 系统体系

实施管理功能的TCB程序和数据结构：

• 必须满足B2级的模块化需求；
• 必须满足最小特权原则；
• 必须使用具有分离属性的逻辑独立存储对象（如文件、数据段）。

必须完整定义由TCB实施的管理角色的接口，并且必须识别实施管理角色的所有TCB部件。

3.1.3.2. 受信设施管理

TCB必须支持对操作员和管理员功能的分离。管理员功能包括：

• 安全管理员
• 系统程序员
• 审计员
• 帐户管理员（当此角色被定义为与安全相关时）

这些功能必须与安全操作员的功能相分离。管理员的功能可能被组合成一个功能，但是我们建议如第5部分描述的那样将其分离。剩下的功能只包括非安全相关功能。

3.1.4. 生命周期保证

3.1.4.1. 安全测试

B2级所有的安全测试需求按照规定适用于实施管理角色的TCB功能和接口。

3.1.4.2. 设计规格说明和验证

建议：

－必须维护实施管理角色的TCB功能和接口的描述性高级规格说明（DTLSs），应使用异常、错误消息和影响来完整和正确地对其进行描述。

－应该使用形式化的受信设施管理安全和完整性模型来定义管理角色、功能、特权和数据库的分离。

3.1.4.3. 配置管理

B2级所有的配置管理需求按照规定适用于实施管理角色的TCB功能和接口。

3.1.5. 文档

3.1.5.1. 受信设施手册

必须有能够提供以下内容的手册：

• 涉及到ADP系统管理员的内容必须对运行安全设施时应该控制的功能和特权提出警告。
• 给出检查和维护审计跟踪的规程。
• 给出每一种审计事件的详细审计记录结构。
• 描述与安全相关的操作员和管理员功能，包括更改用户的安全特性。
• 为系统保护特性的一致和有效使用提供指导方针。
• 解释系统的保护特性是如何互相影响的。
• 说明如何安全地创建新的TCB。
• 对需要得到控制以便在安全的方式下运作设施的设施规程、警告和特权提供指导方针。
• 识别包含参照确认机制的TCB模块。
• 描述在任何TCB模块修改后通过源代码安全创建新的TCB的规程。

3.1.5.2. 测试文档

B2级所有的文档需求，除了用于隐蔽信道测试的以外，都按照规定适用于实施管理角色的TCB功能和接口。

3.1.5.3. 设计文档

必须有文档提供以下内容的描述：

• 实施管理角色功能的TCB模块之间的接口；
• 用于管理角色分离的特定TCB保护机制；
• 实施管理角色功能和接口的TCB模块的描述；
• TCB实施管理角色的功能和接口如何支持最小特权原则；
• 如何对管理角色的行为进行审计。

建议：

－应该有用于定义管理角色分离的安全和完整性模型的形式化描述，而且应该证明其所宣称分离执行的充分性。

3.2. B3安全级的需求

这个级别包含B2级的所有需求。下面列出附加的B3级需求。

3.2.1. 安全政策

没有附加需求。

3.2.2. 职能

B3级的受信路径需求适用于管理用户。

B3级附加的审计需求适用于管理用户。

3.2.3. 运作的保证

3.2.3.1. 系统体系

B3级附加的TCB结构化需求（如大量使用抽象、信息隐蔽和多层化）适用于实施管理角色的TCB功能和接口。

3.2.3.2. 受信设施管理

安全相关的管理功能（如上面定义的安全管理员、系统程序员、审计员和安全操作员的功能）必须与非安全相关的管理功能相分离。

安全相关的管理功能必须被限定于那些对有效执行安全角色非常必要的部件中。

安全人员的所有行为必须得到审计。

建议：

－安全管理和人事功能应该区分以下内容：

• 系统程序员、安全管理员、审计员和安全操作员
• 其特权
• 其数据库。

－应根据其权力和缺陷为以下角色建立信任级别：

• 系统程序员（维护和诊断模式）；
• 安全管理员
• 审计员
• 安全操作员
• 帐户管理员
• 操作员。

（注意：在TCSEC的审计需求中明确了系统管理员、操作员和系统安全官之间的区别［11,p.16］。这些角色相当于上面的帐户管理员、安全／普通操作员、以及安全管理员／审计员角色。也要注意，在审计中这些区别没有要求安全相关和非安全相关功能的分离，不像是在受信设施管理的需求部分那样。）

3.2.3.3. 受信恢复

B3级受信恢复需求适用于实施管理角色的TCB功能和接口。

3.2.4. 生命周期保证

3.2.4.1. 安全测试

B3级所有附加的安全测试需求适用于实施管理角色的TCB功能和接口。

3.2.4.2. 设计规格说明和验证

建议：

－B3级附加的设计规格说明和验证需求适用于实施管理角色的TCB功能和接口。

3.2.4.3. 配置管理

没有附加需求。

3.2.5. 文档

3.2.5.1. 受信设施手册

附加需求必须包括确保系统在初始启动时处于安全状态的规程，以及在系统运作的任何失误后继续进行安全系统运作的规程。

3.2.5.2. 测试文档

没有附加需求。

3.2.5.3. 设计文档

没有附加需求。

3.3. A1安全级的需求

这里包含B3安全级的所有需求。只有如下“生命周期保证”领域的附加需求：

3.3.1. 附加的生命周期保证需求

3.3.1.1. 配置管理

A1级所有附加的配置管理需求适用于实施管理角色的TCB功能和接口。

3.3.1.2. 受信分配

A1级所有受信分配需求适用于实施管理角色的TCB功能和接口。

4. 满足TCSEC的需求

受信设施管理的主要需求是：

• 操作员和管理员功能的分离；
• 对应这些功能的数据库信息的逻辑（或物理）分离；以及
• 实施最小特权原则，即这些功能对于数据库只有所需的最小特权。

4.1. 管理员和操作员功能的分离

管理员和操作员功能的分离是TCSEC的B2级需求，其中规定：

“TCB必须支持操作员和管理员功能的分离。”

操作员和管理员功能分离的主要目的是限制不可信或错误的代码对TCB用于执行安全政策的信息造成的潜在损害。任何以操作员或管理员特权执行的代码都具有改变TCB数据结构的功能，进而影响到政策的执行。通过对最小特权原则和操作员与管理员功能的分离，就可以避免执行不可信的代码，就可以保护TCB的数据结构。最小特权原则要求授予每一个主体特定任务所需的最严格特权集。对于操作员和管理员的功能，需要在低级粒度上建立特权，这样实施这些功能的过程就没有不需要的特权了。这种低级粒度提供了几项重要保护：

• 限制管理员方面的错误影响；
• 限制实施管理员功能的错误代码的影响；
• 提供对有害管理员的一些防范，由此造成的损害会被控制在角色所定义的特权范围内。通过对管理员行为的审计可以提供一些附加的保护。（这一点可以被扩展到插入管理员功能的有害代码。）

TCSEC认为有必要从普通用户执行代码的能力中分离出操作员和管理员功能。有多种方法能够实施这种分离。一种方法是对管理员和操作员功能进行这种限制。他们只能执行那些被证明能够正确保护TCB数据结构的可信代码。这要求执行这些功能的人也要有分离的帐户使其成为普通用户。这种分离的帐户没有操作员或管理员能力。无论选择何种分离方式，必须被证明能够限制操作员或管理员去执行非可信代码。

操作员和管理员功能的分离，也就是设施这些功能的命令、程序和接口的分离是很重要的，因为这些功能对于不同的系统数据使用了不同的特权。如果这些功能不被分离，操作员就可以使用包括管理员特权和数据库的命令。这就意味着，需要像对管理员一样信任所有的操作员。这也意味着，违背了最小特权原则和特权分离原则这两个最重要的安全原则（这些原则的详细解释请参见参考资料［18］），将系统过度地暴露给错误、故障和非法行为。此外，缺乏功能的分离将无法限制任何功能突破的影响，使整个系统处于脆弱状态。

除了管理员和操作员功能的分离，受信设施管理还应该分离操作员和管理员使用的内部系统数据库。需要进行检查和平衡以防止信任太多的全能管理员。必须对安全相关的内部系统数据库、各功能之间的合作以及所对应的数据库进行仔细识别和记录。操作员和管理员功能的分离也必须导致可访问对象以及共享数据库访问特权的分离。这是在TCB中执行最小特权原则的基本设计需求，因为它能够帮助识别和分离操作员对管理员数据的不必要访问。例如，管理员对系统数据库具有完全的访问权，而操作员不需要完全的访问；也就是管理员对于一些（共享的）诸如系统安全特征文件之类的数据库具有读／写特权，对于这些数据库操作员只需要读特权。这样，操作员对这些数据库的写特权就将被清除。同样的，由于这些数据库是分离的，所以可以从管理员的安全相关数据库导出一致性检查并应用于操作员的安全相关功能。这将增强系统管理功能的健壮性，也就意味着其有效性。

注意，虽然操作员和管理员的功能被完全分离，但是管理员的特权包括了操作员的特权，这样，管理员就总是可以获得所有操作员的功能、数据库和特权的访问。例如，管理员总是可以以操作员的身份登录并执行操作员的功能。反过来，操作员无法获得管理员特有的功能、数据库和特权的访问。注意，这种角色的等级关系是功能性等级序列。系统可以提供“扁平”的角色、功能和特权序列，可以使用行政的方式管理等级序列。

4.1.1. 系统管理员的安全相关功能

系统管理员的安全相关功能包括这些：

• 定义和更改用户的安全特性以及系统安全数据（如用户标识符、用户的组标识符、用户／组的最高安全级别；以及系统数据的最高／最低安全级别、每个文件系统的最高／最低安全级别）。
• 定义和更改系统安全特性（如多级别通道、输入／输出处理器、通讯线路、以及设备的安全级别限制；单一级别设备所有可能的级别更改）。
• 执行系统编程功能；（如根据配置管理政策对受信系统的配置、系统安装、可能影响系统配置、分配和安装的TCB代码维护）。
• 执行审计功能（如确定应该审计何种事件、管理审计跟踪、分析审计跟踪、创建审计报告）。

4.1.2. 操作员的安全相关功能

操作员的安全相关功能包括这些：

• 允许和禁止外设、在管理员所定义的限制内更改设备的安全特性（如在管理员定义的范围内操作员设定单一级别设备的级别）。
• 控制文件系统的装载并在适当的驱动器上加载有标记的磁盘堆和磁带卷。
• 在系统崩溃后恢复用户文件。
• 处理打印输出。
• 执行用户数据库的维护操作和TCB数据库的常规维护。
• 启动和关闭系统。

4.2. 安全和非安全相关功能的分离

受信设施管理的第二项需求是识别、审计管理员的安全相关功能并将其从非安全相关功能中分离出来。这项需求的目的是防止操作员或管理员使用其特权执行不可信的代码，这些代码会造成对政策执行数据或机制的破坏。这项需求是在B3级引入的，在TCSEC中有如下规定：

“必须识别以安全管理员角色执行的功能。必须只有AIS管理人员才能执行安全管理员功能，并且在此之前必须采取明确的可审计行为使其担当安全管理员角色。安全管理员角色可以执行的非安全相关功能必须被严格限定于对有效执行安全角色非常必要的范围内。”

管理员和操作员角色都包括安全相关功能。安全相关功能包括所有被用于实施系统支持的安全和职能政策的管理功能。非安全相关功能是那些对系统支持的安全和职能政策的实施不产生影响的功能。安全相关和非安全相关功能的分离是很重要的，因为非安全相关功能需要得到的信任低于安全相关功能。更高度的信任意味着运作的和生命周期保证工作要比低程度信任功能所需的更广泛。虽然一些管理员的非安全相关功能可能是B2级中TCB功能的一部分，但是这些功能的缺陷只会导致潜在的拒绝服务情况，而不会侵害到安全性和完整性。在B3级中，必须将本质上是非安全相关的管理员功能部分从TCB中移出。TCSEC确实允许包含对于执行安全角色非常必要的非安全相关功能。虽然在B2级以下不要求管理员功能的分离，但是还是应该认真考虑它所提供的好处和保护。

注意，虽然操作员和安全管理员（即管理员的非安全相关角色）的功能被完全分离。

（在［5］中建议了不支持任何角色分离系统的可选管理规程。这些规程可能对TCSEC的C1到B1级系统有用。）

4.3. TCSEC的其它需求对受信设施管理的影响

受信设施管理的第三项重要需求是对TCB中实施管理角色的功能和程序的集成，该集成要满足特定TCSEC级别的安全政策、职能、保证和文档需求。例如，在B3或以上级系统中，支持特定角色的每一项功能设计都必须确保程序执行此功能时使用所需的最小特权，并且其设计要满足抽象、信息隐蔽和多层化需求。另外，在B3或以上级系统中，必须将非安全相关的管理员功能从TCB中移出，因为“最小化TCB的复杂程度是系统工程非常重要的任务，要将那些不起关键保护作用的内容排除在TCB模块之外”［11］。一些工作环境要求系统支持多工作班次。如允许多人属于同一角色的系统设计必须确保这些人不会被迫共享一个角色口令，这样将失去个体层面上的职能。

TCSEC的大多数文档需求按照每一个评测级的规定用于受信设施管理。但是，诸如那些规定安全特性用户指南（SFUG）和隐蔽信道分析之类的一些需求显然是不适用的。SFUG与所有用户相关，而受信设施手册和受信设施管理只与管理用户相关。同样，由于大多数管理用户对系统和用户数据具有多级访问权，所以他们必须被信任以维护数据的秘密和及其保密级别。这样，管理用户就必须获得数据保密级别的最高级许可。另外，所有实施管理角色功能的代码必须得到仔细审查以最大可能地确保其中不含有木马或陷门。在名为“受信设施管理的TCSEC需求”的部分中讨论了由TCSEC所对受信设施管理的附加需求。

5. 操作员和管理员角色的分离

受信设施管理的一个重要方面是将管理员和操作员的安全相关任务分割为分离的角色。例如，这种分割可以区分安全管理员、系统程序员和审计员的安全相关角色－以及帐户管理员的非安全相关角色；并且还可以将操作员的安全相关功能（安全操作员角色）与非安全相关功能（操作员角色）区分开。进一步分割管理员任务不是TCSEC的要求，但是因以下原因我们建议这样做：

• 对管理员和操作员不同的安全相关功能所需技能进行区分的需要。
• 将包含所有权力（如能力）的管理员任务分成多个角色以赋予不同信任级别的需要。
• 防止将所有安全相关功能委托给一个角色或人员的需要。在这种管理员任务分割中，安全管理员角色保留了定义和修改用户及系统安全特征的功能。

系统程序员的功能不同于安全管理员、审计员、帐户管理员和操作员的功能。系统程序员的功能、特权和数据库包括其它角色的内容，因为系统程序员是系统中定义的最有特权的管理用户。与其它角色相反，一些系统程序员的行为可能不具有可审计性。因为一些系统程序员的行为发生在配置和加载审计程序和数据库之前。另外，系统程序员的维护活动可能涉及到TCB的维护／维修，包括其它角色的接口（如命令、程序）、数据库和特权。应尽可能在系统维护模式中提交系统程序员功能并通过管理规程进行监视。应尽可能在试验系统上进行TCB代码的处理工作，而不是在当前使用的系统上。试验系统可能是物理分离的系统，或是在执行TCB维护前将用户数据，特别是保密数据移出（如通过更改磁盘堆或覆盖内存）的系统。注意，任何对TCB代码的修改，即使是系统程序员角色中的受权用户进行的也可能使系统的评级无效。以上措施能够让所设计系统的运作模式不包括全能角色。

审计员的功能、数据库和访问特权非常不同于其它管理角色（如安全管理员、帐户管理员、操作员）。将审计功能、数据库和访问特权从安全管理员、帐户管理员和操作员中分离出来是特权分离和最小特权原则的重要运用。如果不进行这种分离，安全管理员就会被允许执行审计员的功能，反之亦然，在系统运作的常规模式下整个安全功能就将变成一个无需负责的人员或角色的责任。例如，安全管理员可能进行滥用授权的活动，然后使用审计功能删除其活动的任何证据。这显然是不希望发生的，虽然TCSEC没有要求安全管理员和审计员功能的分离（也没有要求安全操作员和操作员功能的分离）。

5.8节中解释了这里所定义的不同角色之间的关系。

每一个管理角色的设计都应该包括特定于该角色的、明确的命令、特权和数据库集。相反的，该角色的人员设定最好留给熟悉被设定人员技能、利益和可信度的职位管理人员去进行。另外，本指南不对进行特定安装的程序员角色与设定给厂商的程序员角色进行区别。这种区别依赖于运作环境和环境中执行的管理规程。在小型系统环境中，两个角色变得难以区分，而在大型系统环境中两个角色是不同的。在一些环境中，系统程序员有权检查、修改、重编译和重建TCB，而在另一些环境中，系统程序员就只能安装其给定的目标代码版本。例如，系统程序员在给定的安装站点为系统中所支持的、新的多级别设备向TCB添加设备驱动器，然后重建TCB的情况并不罕见。当允许系统程序员修改、重编译和重建TCB时，应该在安装站点遵循严格的配置管理规程，并且收集证据来向审批者证明系统的评级得到了正确的维护。还应该注意的是，对所评测的TCB代码或配置进行任何更改都可能使系统的评级无效。

各种操作员和管理员功能之间的区别由以下因素确定：

（1） 谁执行了系统配置、分配、安装和维护，
（2） 谁定义了用户和系统安全特性，
（3） 谁执行了诸如常规维护和响应用户请求之类的系统操作。本节建议了更结构化的角色分离，它提供了更有效的计算机资源管理和这些人员的职能。

5.1. 安全管理员的功能

安全管理员的安全相关功能可以在多个安全级别上运作，并调用一些使用系统特权的进程或程序。因此，必须高度信任这些功能。这些功能包括识别和认证功能、强制访问控制功能和任意访问控制功能。

1. 安全管理员的识别和认证功能可以包括：

登录／退出机制的参数设定，如

• 超时时间（系统等待下一个命令或完成当前命令的最长时间量）；
• 最长登录时间（用户可以在系统中保持登录状态的最长时间量）；
• 在通报管理员前，从特定终端登入的连续失败尝试的数量限制；
• 在通报管理员前，登入帐户而无论终端位置的连续失败尝试的数量限制；
• 终端封锁建立和重置；
• 多（同时）登录属性；
• 是否特定用户的登录需要触发管理警告（给管理员或给操作员控制台）。

认证参数的设定；安全管理员功能可以包括对以下决定的执行：

• 认证机制是否是基于口令的，安全管理员确定口令的特性（用户口令的选择是用户创建还是系统创建，最长和最短口令使用期限的设定、口令复杂程度参数等。）；
• 机制是否是基于对话框的，管理员是否以每个用户为基础安装对话框程序；
• 管理员定义和管理用于通过口令启动的受信进程的特殊口令的分配（即TCB维修和维护进程，如安全标签的维修等。）。

［注意：在为特定机构安装系统时作出以上决定，系统安全管理员完成由机构作出的这些安全决定。］

用户帐户和注册特征的定义；这项定义可以包括：

• 用户标识符（这在系统的生命期内应该是唯一的）；初始用户口令；用户口令的更改；
• 用户的全名、地址和从属关系；
• 用户的组标识符（这些在系统生命期内也应该是唯一的）；
  用户的默认组。

组帐户和注册特征的定义；这项定义可以包括：

• 用户组标识符（这在系统的生命期内应该是唯一的）；
• 组名称、组管理员标识符、姓名和地址；
• 组磁盘配额；
• 组统计数据。

［注意，在一些环境中，注册用户的用户和组标识符可能不应透露给其它用户。也要注意，当TCB没有自动为用户和组创建唯一的标识符时，系统安全管理员在重用用户／组名字前应确认不会发生名字冲突。］

2. 安全管理员的强制访问控制功能可以包括以下内容：

安全标签映射的定义和维护；这包括如安全标签的内部表示和供人读取的表示之间的映射等功能。

系统、用户、用户组、系统设备和文件系统的安全级别限制和默认安全级别的设定。

标记未标记的输入数据和未标记的介质如磁盘堆。

对象保密级别的重新设定；这包括：

• 对象的升级和降级；
• 使用标签对用户输出进行标注；
• 受损标签的恢复（当系统程序员角色不提供此功能时）。

3. 安全管理员的任意访问控制功能可以包括以下内容：

对聚合目录和聚合设备的组管理员强制访问特权的初始化；以及对用户组存储配额的初始化。

组成员的定义和维护（当不支持特定组管理员时）。

［注意：因为任何组成员的更改都会影响到个人用户所作出的任意访问控制决定，所以这种更改在没有首先咨询可能受此影响的用户意见之前不应进行。］

文件系统任意特权的设定。

在支持所有权概念的系统中更改对象的所有权；以及更改那些特权被对象的创建者或拥有者意外删除的对象的任意特权。

对于不允许个人用户直接分配、检查和撤销特权的系统（即对象的共享控制是集中化的［9］），以对象创建者／拥有者的身份对特权进行任意分配、检查和撤销。

4. 安全管理员附加功能的清单如下。特别由安全管理员：

执行一致性检查以便验证：

• 用户和系统安全特征数据库满足系统安全需求并处于一致状态；
• TCB得到了正确的安装（如显示和检查安装表）；
• TCB不包含外来的无关程序（如拥有特权但不属于TCB配置的程序）。

确定当前系统配置符合配置管理和系统程序员所建立的约束。这包括验证：

• 设备和终端的注册信息；
• 最大存储容量；
• 文件（设备）系统名字表和文件（设备）装载表；
• 设备和终端连接数据库。

剥夺用户／组帐户的权力（当帐户管理员没有被定义为分离的角色时）。

删除用户／组帐户。

显示和更新各种系统表恒量。

启动和分析系统完整性测试。

监督维护规程（硬件等）。

响应实时警报消息（B3和以上级）。

清除错误的进程。

站点标识符、站点标识和网络中站点认证协议的定义。

建立和访问以下四种数据库：

• 用户和系统安全特征数据库；
• 安全标签映射；
• 文件系统等级序列；
• 系统配置数据库［这包括当前硬件配置和各种设备安全级别限制、终端连接、文件系统名字和装载数据库等。］。

安全管理员通过使用可信的数据库编辑器和系统受信路径的命令执行对这些数据库的所有修改。安全管理员的所有行为都得到审计。

5.2. 安全操作员的功能

操作员角色的安全相关功能可以运行于多个安全级别，并且有时调用需要系统特权的进程。所以，这些功能需要得到高度信任。执行安全相关操作的操作员被称为安全操作员。安全操作员的这些功能可以包括以下内容：

1. 引导和关闭系统；设定系统时钟；以及设定安全管理员数据库所允许级别范围内的单个系统设备的安全级别。

［注意：关闭系统需要操作员确保在系统不运行时有适当的物理和管理安全特性对信息进行保护。例如，因维护而关闭系统可能需要将数据移出并清理系统。］

2．定位受损的用户文件和卷。“拯救者”进程识别受损标签（如标签与所包含的目录和文件不一致）并在系统程序员和安全管理员完成修复前删除所有相关的对象访问权。

3．执行TCB数据库的常规维护。

操作员执行以下常规维护操作：

• 审计文件的备份（当这不包含在审计员角色中时）；
• 一些设备的安全级别更改（这些在系统安全管理员设定的限制范围内）；
• 用户数据库的备份；
• 安全映射的备份；
• TCB表的备份。

必须注意的是，操作员不应该具有修改文件备份中文件内容的特权。

4．执行在线终端和设备的测试（包括认证测试）。

5．响应用户的请求。

操作员应该能够响应以下用户请求：

• 物理地装载／卸载（外部的）得到标记的可移动介质（如磁带卷和磁盘堆）；
• 将其它得到标记的数据物理地输入到系统或从系统输出。

必须注意的是，操作员的所有行动必须是可审计的。不应装载未得到标记的存储设备。TCB需要标签信息以便正确作出访问控制决定。如果没有向操作员提供标签，系统将无法正确地执行政策。

5.3. 帐户管理员的功能

管理员角色安全相关功能的正确操作可能不需要特殊的特权，但是在大多数安装环境中，它们会是受信进程。而且帐户管理员的所有输出将被标记为最高级。否则会发生保密信息的泄漏（如用户帐单中的编码）。安全管理员的非安全相关角色被称为帐户管理员。

帐户管理员的（非安全相关）功能的清单如下。特别由帐户管理员：

1. 安装和维护记帐文件。
2. 关闭和开启记帐功能。
3. 运行记帐工具并创建记帐报告／帐单。
4. 应用户请求允许和禁止帐户（当此功能不由安全管理员提供时）；但是帐户管理员没有定义或更改用户安全特征的特权。
5. 建立费率、价格和政策。
6. 经常性地收集系统统计数据如：

• 系统可用性；
• 系统配置；
• 磁盘／CPU／内存的统计数据。

7. 发布利润／费用报告。

5.4. 审计员的功能

审计员调用使用系统特权的进程。所以，审计员的所有功能都需要得到高度信任。这些功能包括那些使审计具有选择性机制（如审计事件的建立和更改）、审计跟踪管理、隐蔽信道延迟和随机化变量、审计数据压缩和后加工分析的内容［7］。由审计员创建的数据必须被设定为系统最高级的保密级别，因为它们可能包含系统定义的所有安全级别上创建的信息。系统最高级被定义为安全标签支配系统中所有其它的安全标签。在某种意义上，它是最高级别标签。创建系统最高级别，如在等级序列中支配系统中所使用的所有的数据级别将是有益的，并可能是需要的。这种方法对为审计数据提供附加保护的强制访问控制是有益的，因为只有审计员才有这个级别的授权。

1．定义审计日志（或跟踪）中被记录事件的审计员功能可以包括：

开启和关闭应被记录在审计跟踪中的事件以确保审计员所选择的后续事件的一致性的功能。这些事件确保后加工工具功能的正确进行。例如，在由文件系统路径名表示对象唯一名字的系统中，应该对与路径名解释相关的工作目录的任何更改进行审计。（对象唯一名字是从系统中所有其它对象中识别和区分特定对象的唯一名字。在具有等级序列的文件系统中，对象唯一名字包括相关的目录名以便用户可以在不同目录中使用同样的对象名字）。否则，读取所记录的审计事件的审计分析工具在目录更改后就无法明确地识别对象了。因为类似的原因，记录进程创建或清除以及识别和认证行为的所有事件都应该在开启审计时予以选择。

显示所有可以被审计的安全相关事件的功能。

（在设计时进行系统中安全相关事件的确定，并基于系统中所选择的安全政策和职能模型。诸如用户的TCB启用或受信进程调用之类的任何事件，只要其造成了状态转换或其在模型的解释中拒绝了状态的转换，都是安全相关的。例如，进程地址空间对象的引入在被设计为支持Bell-LaPadula模型的系统中是安全相关的，因为在模型解释的当前访问集部件的解释中造成了状态转换［2］。类似地，访问特权的分配和撤销也造成了状态转换，因为它们修改了模型的访问矩阵部件；而且对象／主体安全级别的更改也会造成状态转换，因为它修改了模型的安全功能部件。其它也应被审计的状态转换可能修改了系统状态的多个部件；如对象的创建和清除修改了对象等级序列和访问矩阵。另外的安全相关事件可能在安全政策模型不包括受信设施管理模型时由受信设施管理模型的解释导出。另外的安全相关事件也可能由TCSEC的隐蔽信道处理需求导出）。

也包括在每个用户、每个进程、每个安全级别或每个对象基础上有选择性地开启或关闭审计的功能。这些事件可能由处理器、TCB或受信进程发起。也应该可以选择由审计员确定的这些事件的子集。

这里也包括开启或关闭表示其它可审计事件和警告累积的事件的功能（如多个连续的失败登录）。

2．帮助管理审计文件的审计员功能可以包括：

审计日志和后加工审计文件的创建和清除。

审计日志大小和警告点的更改。警告点可以被表示为特定的数值或比率或审计日志中的字节数。当这些警告点被事件记录机制超越时，系统可能会给出一个审计员警告。如果审计日志填满并且审计机制处于开启状态，系统可能会停止并延迟进一步的活动直到审计员采取矫正行为为止［7］。

用于清空被填满的审计文件的功能。

格式化和压缩审计日志及后加工审计文件的功能。格式化功能可以将二进制审计数据转换为文本格式，并将不完整的事件记录整合成所需的记录格式。格式化的后加工文件的存储可能需要使用压缩技术以提高存储器的使用率。

显示各种格式的审计日志和后加工审计文件的功能。

在系统崩溃后对整个审计员数据库进行一致性检查的功能。

3．为隐蔽信道的处理设置延迟或随机化值的功能也应被包括在审计员角色中。这是因为TCSEC的隐蔽信道处理指导方针将隐蔽信道审计需求与特定的隐蔽信道带宽值联系起来，因此也就与延迟值和随机化范围联系起来了。例如，依赖于为审计延迟设定值的不同，特定的信道可能或可能不需要被审计。这样，延迟值和随机化范围的设定就成了审计员的任务。这些功能可以包括：

为单一隐蔽信道或隐蔽信道组设定默认和当前延迟值。

为由TCB表索引的动态分配或释放引发的隐蔽信道设定随机化范围的默认和当前值。

4．执行审计数据后加工的功能对于任何审计日志的分析都是必要的，所以应该被包括在任何受信系统中。虽然这些功能中的一部分独立于所需的审计分析，如取回审计日志各种字段的功能，大部分这样的功能是特定于特定的应用所要求的后加工分析。

总之，审计员角色的功能可以建立、访问和修改以下类型的数据库：

• 审计日志文件，其中包含全部或部分二进制或文本格式的审计事件记录；
• 审计事件文件，包含系统中所有可审计事件的定义；
• 选择性事件文件，包含所有以每个用户、每个进程、每个安全级别、每个对象为基础所选择事件的定义；
• 格式化或压缩了的审计文件，包含后加工阶段的输入内容；
• 审计报告文件。

对审计数据库的访问可以只由担负审计员角色的人，使用该角色所定义的命令执行。审计员命令的使用必须得到审计。对于B3和以上级系统，必须通过受信路径机制使用审计员命令。

5.5. 操作员的功能

操作员角色安全相关功能的正确操作不需要所有的系统特权。但是，操作员应该能够在系统最低级和系统最高级之间更改其进程的授权，因为他可能需要在不同的安全级别进行操作。系统最低级是低于系统中所有其它安全级别的安全标签。在某种意义上，它是最低级的标签。

操作员的（安全相关）功能被定义如下。特别由操作员：

1．执行用户卷备份。这包括：

• 完整的卷转储；
• 完整的卷取回。

2．执行系统性能测量。

3．响应各种其它用户请求（用户级软件包的安装请求等。）。

4．调整用户可见资源的资源配额。

5.6. 系统程序员的功能

系统程序员角色的功能是系统中安全敏感性最强的功能。它们可以影响到TCB配置、分配和维护。这些功能不一定会得到审计，所以任何影响整个系统安全的错误、遗漏或恶意行为都可能无法被发现。（但是，一些可能是离线的审计形式在一些环境中还是必要的。在一些执行系统程序员功能的环境中要求多个系统程序员相互检查其他系统程序员的行为。另外，可以在登录规程中制定或建立除非有一个系统程序员也在登录，否则系统程序员不能成功登录的双人规则）。所以，系统程序员功能应该得到系统中最高级别的信任。系统程序员的功能可以包括以下内容：

1．受信系统分配；举例来说，这包括站点系统主复件的创建和处理。

2．系统配置参数的设置（根据站点的配置管理政策进行设定）；举例来说，这包括：

• 普通系统配置；
• TCB数据结构的初始化（在任何特征或审计特性定义以前）；
• TCB的加载。

3．非常规的TCB维护；举例来说，这包括：

• 转储的分析；
• TCB代码和数据“补丁”的安装（因此，操作员应该可以对修改后的源代码进行重新编译得到TCB代码，并且应该使用可信的加载器重新加载系统）；
• 系统崩溃后的受信恢复行为；例如操作员对文件系统结构、单一TCB文件、目录和表进行一致性检查，修复受损标签；
• 当安全管理员角色不提供修复受损安全标签的功能时，执行这项功能。（受损标签由安全操作员或用户识别）。

系统程序员数据库包括：

• 所有的TCB文件（如TCB代码、安全映射、审计文件）；
• 所有的TCB表（如中断向量、陷阱表、入口）。

5.7. 其他角色

可以在安全系统中定义其它管理角色。例如，在某些环境中可以定义分析员角色。分析员可能是另一种无特权用户，他得到信任在各种系统输入中对输入数据进行标记，在他认为合适时创建新文件并且对其进行标记。分析员不能将任何数据标记为比其自己的最高许可级别还要高的安全级别。所有分析员的行为都要像普通用户一样得到审计。

当系统与网络连接时，可能有必要定义附加的角色以确保网络政策执行的一致性和正确性。这样的角色可能涉及到附加的安全相关数据库。

5.8. 管理角色之间的关系

通过对以上所定义管理角色的精细分离可以基于“角色支配”概念建立起管理角色之间的等级序列关系（不要与安全或完整性级别之间的支配概念产生混淆）。这个概念意味着，在某一角色下的管理用户有能力在其它角色下更改对象和安全特征的属性，如果需要，还可以以那个角色登录和采取行动。

对象属性包括：

• 访问特权；
• 大小；
• 安全和完整性级别；以及
• 所有权。

特征属性包括：

• 用户和组标识符；
• 口令；
• 组成员；以及
• 对用户活动的时间限制。

以上角色支配概念可以很有用，因为它既提供了对角色应该赋予所需信任（基于技能、对管理用户背景和利益的调查等）的方法，也提供了与此角色相关缺陷的方法。最具有特权的角色是系统程序员的角色。它支配系统中的所有其它角色，因此也表现出最多的缺陷。应该严格地将审计员角色与系统中定义的所有其它剩余的角色相分离，因为其维护描述其它所有用户行为的敏感信息，包括管理用户。安全管理员支配安全操作员、帐户管理员、分析员和用户角色；虽然较低级的角色也是互相分离的。必须注意的是，同样角色的用户不互相支配。虽然他们共享同一角色的大多数功能、特权和数据库，但是他们的安全特征是相互分离的以便维护个人的职能。这帮助区分同一角色中个人用户的活动。图4描述了上面所定义的管理角色之间的关系。系统可以提供“扁平”的角色、功能和特权系列，角色的关系可以通过行政方法来管理。在管理角色中实施等级序列关系可以从强制安全的使用中得到好处，特别是完整性模型。强制完整性模型，如Biba模型［4］和Clark-Wilson模型［8］，可以被用于指导上面提的的角色和等级序列的设计，下面会讨论到。

6. 其它TCSEC需求对受信设施管理的影响

TCSEC需求的很多领域（安全政策、职能、保证和文档）对受信设施管理产生影响。各种管理角色功能的设计和实施可以使用底层系统的一些安全机制和政策来满足一些特殊的保护需求，也可以选择实施新的保护机制和策略。例如，安全管理员功能的实施者可以使用任意访问控制机制，也可以选择实施保护安全管理员数据库防止其它管理用户和一般用户访问的机制。本节考察了其它TCSEC需求与受信设施管理的关系。

6.1. 安全政策

为支持系统的安全政策，受信设施管理功能必须控制对管理数据的访问和共享。实施管理员和操作员安全功能的受信进程以各种方式共享管理数据库的文件。有些文件是每个角色私用的，不会与其它角色、同一角色的不同用户或非管理受信进程共享。例如，安全标签映射文件是安全管理员角色私用的，审计日志和后加工审计文件是审计员角色私用的，而记帐文件是帐户管理员角色私用的。所有这些文件在同一角色的所有用户之间共享。其它文件，如包含用户和组注册信息的文件，可以在不同角色的进程之间共享。这些文件可以被安全管理员进程读取和写入，可以被审计员、安全操作员和帐户管理员进程读取。帐户管理员和操作员可以执行特殊的任务，如收集用户和系统的统计数据和进行性能测量，这样它们就会创建和维护私用文件（不与同一角色的其它用户共享）。另外，其它文件在管理员角色的进程和非管理的受信进程之间共享。例如，用户口令文件由安全管理员角色读取和写入，由“登录”受信进程读取，由“更改口令”受信进程读取和写入，该进程可以被任何用户调用。

为了控制对管理数据的访问和实施上面提到的管理角色进程之间的共享关系，受信设施管理的设计和实施可以，也可以不依赖于底层系统的任意和强制访问控制。如果他们这样做了，实施需要在所有安全级别上读取和写入的角色功能的一些进程至少有时将需要绕过强制访问控制。一些其它进程（如记帐和审计进程）将在系统的最高级别上运行并在这个级别上维护数据文件（如审计日志和后加工文件、记帐文件）。

当管理角色的程序和进程之间的共享关系不能被现存机制支持时，就需要引入新的机制了。例如，实施管理功能的特定程序与角色的结合可能需要实施安全管理员无法修改的受限制的处理器或受限制的组，或者其它更复杂的完整性机制（在下面讨论）。所有这些情况中，受信设施管理功能的设计和实施都应遵循现有的指导方针（参见例子，［9］）。

6.2. 职能

TCSEC的职能性需求对受信设施管理的实施施加了除角色分离以外的几条约束。首先，所有管理用户的识别和认证必须是明确的，而且必须在个人的基础上执行，而不是每个角色的基础上。例如，如果一个角色的所有用户共享同一个口令，就会失去职能性，因为用户可以采用同一角色其它用户的身份，并把入侵行为归咎于其他用户。

其二，B3和以上级的受信路径机制必须确保管理用户与属于他们角色的命令或进程相连，这样就没有其它用户或进程可以介入到连接管理用户及其命令和进程的任意组合的路径中了。这可以通过提供由TCB硬件或软件认可的、并与其它终端相分离的管理控制台来实现，或者通过全（即B3-A1）受信路径机制的设计来实现。

其三，所有管理功能的使用，除了那些系统程序员在维护模式下使用的之外，都必须被审计。这意味着实施这些命令的受信程序和过程应该能够在其命令执行期间请求审计记录的写入。在职能的所有领域，受信设施管理功能的设计和实施都应该遵循现有的指导方针（参见例子，［7］）

6.3. 保证

TCSEC的保证需求无论在运作的还是生命周期领域都对受信设施管理有着很大影响。这些需求影响到受信设施管理功能的设计和实施。

6.3.1. 运作的保证

运作保证中只有系统体系和受信恢复领域是相关的领域。隐避信道分析领域在这里是不相关的，因为（1）安全相关管理员角色的所有用户都经过了职位的信任审查，所以预期不会以非受权方式泄漏信息，而且（2）要检查实施管理功能的所有代码以最大程度地确保其中没有木马存在。TCSEC的完整性需求在这里也是无关的，因为它们仅与硬件和固件正确运行的测试有关。

系统体系需求对受信设施管理的设计施加了主要约束。因为管理角色的所有安全和职能相关的功能都是系统TCB的一部分，TCB接口定义的所有需求适用于管理接口。类似地，内部TCB结构化的所有需求，诸如那些模块化、抽象、信息隐避和多层化需求都适用于实施受信设施管理的程序和进程代码的设计和实施。对此设计和实施部分的仔细分析和记录，以及由评测者进行仔细评审在这个领域是很需要的。

对受信进程应用最小特权原则也是TCB管理进程需要的。在这里我们考察几个特定的设计需求。首先，应该在单一文件（或数据段）和单一特权粒度上执行管理数据库的保护。（这里使用一般意义上的条目文件表示逻辑的小结构，这样的结构不包括与特定功能无关的信息）。其二，管理角色的程序和进程应该只具有TCB和用户文件以及具有特权的TCB调用的访问权，这是实施这些角色必需的，但不应有其它文件或调用的访问权。这个领域有几种可用的设计选择。例如，特定文件应该只与特定进程相连。具有特权的TCB调用，可以由环入口描述符［15，19］、域进入能力［13］或对应于特定调用的每个进程的特权向量表示，应该只在“需要时”与进程相连。这些关联可以通过仔细运用非任意标签和系统配置的授权或安装时间来加以控制。

对受信设施管理的设计和实施产生影响的特定受信恢复需求只包括在系统崩溃后对管理数据库进行一致性的维护。可以通过确保以下内容满足此需求：

• 这些数据库被存储在系统崩溃后能够使用的非易失存储器中；
• 对此存储器的更新是原子化的；
• 至少有一个管理角色可以使用命令检查管理文件的内容一致性。注意，这可能是无需管理员干预的全自动机制。

6.3.2. 生命周期保证

大多数生命周期保证需求按照规定适用于受信设施管理的进程和接口。例如，TCSEC的安全测试、配置管理和受信分配的需求适用于受信设施管理，并与被选择的评测级的要求高度一致。这是因为TCB代码和接口包括受信设施管理的安全相关代码和接口。

相反的，只有某些设计规格说明和验证领域的需求直接适用于受信设施管理。例如，对TCB接口准确的DTLS需求按照规定适用。但是，对于形式化模型、对于TCB受信设施管理部分的DTLS中此模型的解释，以及对于DTLS与模型一致性的论证需求在这里并不直接适用。这是因为目前在受信设施管理领域不存在被普遍接受的形式化模型。如果出现了被普遍接受的受信设施管理形式化模型，设计规格说明和验证领域的所有需求都将直接适用于受信设施管理。

6.4. 文档

与受信设施管理领域相关的TCSEC文档需求是第3节中的受信设施手册需求、测试文档需求和一些设计文档［8］。在设计文档领域，只有涉及到DTLS、TCB内部结构化和最小特权原则执行的需求是相关的。

术语表

访问

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

帐户管理员

被设定维护记帐文件、工具、用户帐户和系统统计数据的管理角色或用户。

管理用户

被设定监督全部或部分AIS的用户。

管理员

参见安全管理员。

批准／鉴定

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

审计

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

审计事件的选择

由受权人员对被记录在审计跟踪上的可审计事件的选择。

审计机制

用于收集、检查和／或检验系统活动的过程。

审计后加工

在受权人员的控制下，对被记录在审计跟踪上的特定事件的处理。

审计跟踪

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

可审计事件

可以被选择包括在审计跟踪里的任何事件。这些事件除了安全相关事件外还应包括故障后恢复系统的行动和事后可能被证明与安全相关的事件。

审计员

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

认证

（1）验证计算机系统中用户、设备或其它实体的身份，通常做为允许对系统资源访问的先决条件。
（2）验证被存储、传输数据的完整性，或其是否暴露给可能的非受权修改。

已认证用户

访问AIS并具有有效身份和认证组合的用户。

自动化信息系统（AIS）

被设计用于收集、创建、交流、计算、分发、处理、存储和／或控制数据或信息的计算机硬件、软件和／或固件的集合。

带宽

在给定的时间段内能够通过的信息量的信息通道特性，通常被表现为比特每秒。

类别

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

信道

信息在系统中的传输路径。也可以指影响路径的机制。

隐蔽信道

允许以违反系统安全政策的方式进行信息传输的通讯信道。还可参见：隐蔽存储信道、隐蔽时间信道。

隐蔽存储信道

涉及到通过一个进程对存储位置的直接或间接写入，通过另一个进程对该存储位置的直接或间接读取的隐蔽信道。隐蔽存储信道通常涉及到由不同安全级别主体共享的有限资源（如磁盘扇区）。

隐蔽时间信道

一个进程调整其对自己系统资源（如CPU时间）的使用，另一个进程观察到这种处理方式对真实响应时间的影响，一个进程以这种方式向另一个进程发送信息的隐蔽信道。

数据

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

数据的完整性

数据满足预先设定的质量预期的属性。

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

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

任意访问控制

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

形式化安全政策模型

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

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

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

功能测试

是安全测试的一部分，该测试在运作条件下对系统所宣称的特性进行测试以验证其运作的正确性。

最小特权

要求每个主体只被赋予执行受权任务的最严格特权序列的原则。应用此原则限制事故、错误或非受权使用所造成的损害。

强制访问控制

基于对象中所包含的信息的敏感性（以标签表示）和主体访问这些敏感性信息的正式授权（即许可证）限制对象方法的一种方法。

多级别设备

以允许其对两个或以上安全级别的数据进行同时处理而不会危及安全的方式使用的设备。为了达到这一点，敏感性标签通常被以相同的格式（即机器可读或人可读）存储在相同的物理介质上。

多级别安全

包含不同敏感性的信息，允许具有不同安全许可证和需知类型的用户同时访问，但防止用户能够访问未向其授权信息的一类系统。

对象

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

对象唯一名字

从系统中的其它所有对象中识别和区分特定对象的唯一名字。在具有等级序列的文件系统中，对象唯一名字包括相关的目录名以便用户可以在不同目录中使用同样的对象名字

操作员

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

输出

从TCB输出的信息。

口令

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

进程

执行中的程序。它完全以当前的单一执行点（由机器的状态表示）和地址空间来表现。

读取

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

读取访问权（读取特权）

读取信息的许可。

安全操作员

被设定执行操作员角色中对TCB用于执行其政策的安全相关数据产生影响的这一部分功能（如通知TCB新装载磁带的安全标签）的管理角色（或用户）。

安全管理员

负责自动化信息系统的安全并有权对所有其它访问自动化信息系统的人（可能审计员是个例外）执行安全防范措施的管理角色或用户。也被称为系统管理员。

安全标签映射

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

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

安全政策

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

安全政策模型

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

安全相关事件

试图更改系统安全状态的任何事件（如更改任意访问控制、更改主体的安全级别、更改用户口令等。）。也包括试图违反系统安全政策的任何事件（如太多的登录尝试、违反设备强制访问控制限制的尝试、降低文件安全级别的尝试等。）。

安全测试

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

敏感信息

由主管当局确定，由于其未受权泄漏、更改、遗失或损毁将至少对某人或某事造成可感知的损害所以必须得到保护的信息。

敏感性标签

表示对象安全级别并描述对象中数据的敏感性（如保密级别）的一段信息。TCB使用敏感性标签做为强制访问控制决策的基础。

特权分离

功能的分离，也就是实施这些功能的命令、程序和接口之间的分离，这样就可以防止一个功能中的恶意或错误代码影响其它功能中的代码或数据。

哄骗

佯装成受权用户获得系统访问权的尝试。也被称为冒充或伪装。

主体

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

主体安全级别

主体的安全级别等于其具有读取和写入访问权的对象的安全级别。主体的安全级别必须总是由其相关的用户的许可证支配。

系统管理员

参加安全管理员

系统最高级

支配系统中所有其它安全标签的安全标签。在某种意义上，它是最高级标签。

系统最低级

在特定时间或特定环境中系统支持的最低安全级别。

系统程序员

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

高级规格说明（TLS）

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

陷门

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

木马

具有表面上或实际上有用的功能但含有附加（隐藏）功能的程序，其中隐藏功能暗中破坏确定安全调用进程的合法授权。

受信计算机系统

使用了充足的硬件和软件保证措施使其可以用于同时处理一定范围的敏感或保密信息的系统。

受信计算基（TCB）

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

受信路径

使用终端的人可以与受信计算基直接通信的一种机制。这种机制只能由人或受信计算基激活，而不能由非受信软件效仿。

用户

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

验证

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

病毒

自我繁殖的木马，包括一个任务部件、一个触发部件和一个自我复制部件。

缺陷

可以被用来违反系统安全政策的系统安全规程、系统设计、实施、内部控制等的弱点。

写入

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

写入访问权（写入特权）

写入对象的许可。

参考资料

1. Baldwin, R. W., "Rule-Based Analysis of Computer Security," Technical Report MIT/LCS/TR-401, March 1988.

2. Bell, D.E., and L. J. LaPadula, "Secure Computer System: Unified Exposition and Multics Interpretation," MITRE Corp., Rep. No. MTR-2997, 1976 (available as NTIS AD-A023588).

3. Biba, K.J., "Integrity Considerations for Secure Computer Systems," Mitre Corp., MTR-3153, Bedford, Mass., June 1975.

4. Bishop, M., "How to Write a Setuid Program"; login, vol. 12, no. 1, January/February 1987.

5. Bishop M., "Managing Superuser Privileges under Unix," Research Institute for Advanced Computer Science, Technical Report, NASA Ames Research Center, Moffet Field, California, (June 1986).

6. Clark, D.D., and D. R. Wilson, "A Comparison of Commercial and Military Computer Security Policies," Proc. of the IEEE Symp. on Security and Privacy, Oakland, Calif., April 1987.

7. Department of Defense -- A Guide To Understanding Audit In Trusted Systems, NCSC-TG-001, version-1, July 1987.

8. Department of Defense -- A Guide To Understanding Design Documentation In Trusted Systems, NCSC-TG-007, version-1, October 1988.

9. Department of Defense, A Guide to Understanding Discretionary Access Control in Trusted Systems, NCSC-TG-003, version-1, September 1987. 10. Department of Defense, Password Manage*ment Guideline, CSC-STD-002-85, April 1985.

11. Department of Defense, Trusted Computer System Evaluation Criteria, DoD 5200.28-STD, December 1985.

12. Gligor V.D., C.S. Chandersekaran, R.S. Chapman, L.J. Dotterer, M.S. Hecht, W.D. Jiang, A. Johri, G.L. Luckenbaugh, and N. Vasudevan, "Design and Implementation of Secure Xenix," IEEE Trans. on Software Engineering, vol. SE-13, No. 2, February 1986.

13. Gligor V. D., J.C. Huskamp, S.R. Welke, C. J. Linn, and W.T. Mayfield, "Traditional Capability-Based Systems: An Analysis of their Ability to Meet the Trusted Computer Security Evaluation Criteria," Institute for Defense Analyses, IDA Paper P-1935, February 1987

14. Hecht M.S., M.E. Carson, C.S. Chandersekaran, R.S. Chapman, L.J. Dotterer, V.D. Gligor, W.D. Jiang, A. Johri, G.L. Luckenbaugh, and N. Vasudevan, "Unix Without the Superuser," Proc. of the Usenix Conference, Phoenix, Arizona, June 1987.

15. Intel Corp., iAPX 286 Programmers Reference Manual, Chapter 7, section 5, Intel Corp., 1983.

16. Knowles, F., and S. Bunch, "A Least Privilege Mechanism for Unix," Proc. of the 10th Na*tional Computer Security Conference, Baltimore, MD., September 1987.

17. Lee, T.M.P., "Using Mandatory Integrity to Enforce 'Commercial' Security," Proc. of the IEEE Symp. on Security and Privacy, Oakland, Calif., 1988.

18. Saltzer, J. H., and M. D. Schroeder, "The Protection and Control of Information Sharing in Computer Systems," Proc. of the IEEE, vol. 63, no. 9, September 1975.

19. Schroeder, M.D. and J.H. Saltzer, "A Hardware Architecture for Implementing Protection Rings," Communica*tions of the ACM, vol. 15, no. 3, March 1972.

20. Thompson, K., "Reflections on Trusting Trust," Turing Award Lecture,
Communications of the ACM, vol. 27, no. 8, August 1984.