一 范围

1.1 主题内容

本标准规定了评估计算机安全的准则，等级划分及每个等级的安全要求。

1.2 适用范围

本标准适用于军用计算机安全评估，主要面向操作系统，也适用于其他需要进行安全评估的计算机。

二 引用文件

GJB 2255-95 军用计算机安全术语

三 定义

3.1 术语

本章未列入的术语 , 见 GJB2255 。

3.1.1 自主保护 discretionary protection

辨识用户身份和他们的需求 , 限制用户使用信息的访问控制的方法。

3.1.2 强制访问控制 mandatory access control

根据客体所包含信息的敏感性以及主体访问此类敏感信息的权限 , 限制主体访问客体的方法。

3.1.3 安全等级 security level

为表示信息的不同敏感度 , 按保密程度不同对信息进行层次划分的组合或集合。

3.1.4 审计 audit

对影响系统安全的各种活动进行记录并为系统安全员提供安全管理依据的程序。

3.1.5 隔离 isolation

为防止其他用户或程序的非授权访问 , 把操作系统、用户程序、数据文件加以彼此独立存储的行为。

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

计算机系统内保护装置的总体 , 包括硬件、固体、软件和负责执行安全策略的组合体。它建立了一个基本的保护环境并提供一个可信计算系统所要求的附加用户服务。

3.1.7 敏感标号 sensitivity label

表示客体安全级别并描述客体数据敏感性的一组信息 , 可信计算基中把敏感标号作为强制访问控制决策的依据。

3.1.8 系统完整性 system integrity

系统不能以非授权手段被破坏或修改的性质。

3.1.9 描述性顶层规格说明 (DTLS)descriptive top-level specification

用自然语言、形式化程序设计符号 , 或两者结合写在的一种最高层的设计规格说明书。

3.1.10 形式化顶层规格说明 (FILS)formal top-level specification

用形式化数学语言写成的一种高层规格说明书。使用这种规格 , 可以从理论上证明假定的形式化要求与系统规格的一致性。

3.1.11 最小特权原则 principle of least privilege

为完成特定任务 , 授予主体所需要的最小访问特权的过程、策略。

3.1.12 分层密级 hierarchical classification

用层次结构的方式将主体和客体分成不同的保密等级。

3.1.13 粒度 granularity

一次访问操作所涉及到的访问对象的大小。

四 一般要求

计算机系统安全将通过使用特定的安全特性控制对信息的访问 , 只有被授权的人或为人服务的操作过程可以对信息进行访问。在本准则中提出了以下六条要求。 4.1 安全策略

必须有一种由系统实施的、明确的和定义好的安全策略。对于主体和客体 , 必须有一个由系统使用的规则集合。利用这个规则合来决定是否允许一个给定的主体对一特定客体访问。对于处理敏感信息的计算机系统必须施加一种强制安全策略来有效地实现访问规则。这些规则要求包括 : 任何人如果缺少适当的安全许可证都不能获得对敏感信息的访问 ; 同时也要求有自主的安全控制 , 以保证只有指定的用户或用户组才可以获得对数据的访问。

4.4.2 标号

客体应当按敏感程度加以标号 , 访问控制标号必须与客体联系起来。为了控制对存储在计算机内的信息进行访问 , 根据强制安全策略规则 , 每个客体必须有一个标号 , 这个标号表示客体的敏感级别并记录哪些主体可以对特定的客体进行访问的方式。

4.3 标识

每个主体都必须在验明身份 ( 身份标识 ) 后才能对客体进行访问。每次对信息的访问都应标识谁在要求访问 , 他有权访问什么信息？标识和授权信息必须由计算机系统在秘密情况下进行维护并与完成某些与安全有关动作的每个活动元素结合起来。

4.4 责任

对审计信息应有选择地保存并妥善加以保护 , 以便以后对影响安全的动作进行跟踪 , 查清责任。一个可信系统应将与安全有关的事件记录在一个审计日志中 , 为了降低审计费用并提高分析效率 , 必须具有选择审计事件的能力。审计信息必须很好地保护 , 以防修改和未经授权的毁坏。

4.5 保证

计算机系统应包括能使上述各条要求实现所必须的硬件和软件机制 , 必须有一批硬件和软件控制 , 这些机制可嵌入操作系统内 , 并用秘密方法执行指定的任务。这些机制应在文件中写清楚并能独立检验其结果 , 以便能独立地考评它们是否充分。

4.6 连续保护

对实现上述基本要求的可信机制必须能连续地提供保护 , 以对抗未授权的篡改。如果实现上述策略的硬件和软件机制本身遭到未授权的修改或破坏 , 那么这个计算机系统是做不到真正安全的。连续保护要求与计算机系统的整个生存周期有着直接的关系。

五 详细要求

本准则根据上述六条要求 , 按处理的信息等级和采取的相应措施 , 将计算机系统的安全分为四等八级别。 D 为最低等级 , 随着等级的提高 , 系统可信度也随之增加 , 风险逐渐减少。

注 : 在本标准中 , 凡是使用黑体字的部分均表示在较低等级中不包含那些要求 , 或表示对已定义要求的变动和增加 ; 凡是不使用黑体字的部分均表示这些要求与较低等级的那些对应要求相同。

5.1 D 等 : 最小保护

本等只含一级 , 它是为那些已作评估 , 但不能满足较高评估等级要求的系统而准备的。

5.2 C 等 : 自主保护

本等分为 C1 和 C1 两个级别 , 它主要提供自主访问控制保护 , 并具有对主体责任和他们的初始动作审计的能力。

5.2.1 C1 级 : 自主安全保护

C1 级的可信计算基 (TCB) 通过提供用户与数据的分离来标称满足无条件安全要求。它包括某种形式的可信控制 , 以便能在个体基础上执行访问限制 , 即外表上允许用户保护项目和保护私有数据 , 并阻止其他用户意外地读取或破坏他们的数据。 C1 级环境是在同一敏感等级上处理数据的那些协同用户所要求的。下述是 C1 级的最低要求。

5.2.1.1 安全策略

5.2.1.1.1 自主访问控制

TCB 应在计算机系统已命名的用户和已命名的客体 ( 如文件和程序 ) 之间进行定义和控制访问。实施机制 ( 如自身 / 组 / 公共控制 , 访问控制表 ) 应允许用户通过已命名的单个用户或已定义的组或两者来规定和控制这些客体的共享。

5.2.1.2 责任

5.2.1.2.1 标识和鉴别

在开始执行 TCB 仲裁的任何其他动作之前 , TCB 要求用户自己向 TCB 作出标识。因此 , TCB 应使用一种受保护的机制 ( 如口令 ) 来鉴别用户的身份。 TCB 应保护鉴别数据 , 以使它不能被任何未授权用户访问。

5.2.1.3 保证

5.2.1.3.1 操作保证

5.2.1.3.1.1 系统体系结构

TCB 应维持它自己执行的区域 , 以保护它免受外部干预或篡改 ( 如对它代码或数据结构的修改 ) 。由 TCB 控制的资源可以是计算机系统中已定义的主体和客体的子集。

5.2.1.3.1.2 系统完整性

应提供硬件特性或软件特性或同时提供两者 , 用于定期地验证 TCB 硬件和固件单元的运行正确性。

5.2.1.3.2 生存周期保证

5.2.1.3.2.1 安全测试

应对计算机系统的安全机制进行测试 , 并按系统文档的要求工作。测试应当保证 : 没有明显的让未授权用户旁越的途径 , 或没有其他击败 TCB 安全保护机制的方法 , 见附录 C( 补充件 ) 。

5.2.1.4 文档

5.2.1.4.1 安全特性的用户指南

用户文档中的摘要、章节或手册应描述由 TCB 提供的保护机制 , 有关它们使用的指南以及它们如何相互作用。

5.2.1.4.2 可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告 , 这种特权在一个安全设施运行时应受到控制。

5.2.1.4.3 测试文档

系统开发者应向评估者提供一个文档 , 该文档描述测试计划 , 怎样测试安全机制的测试过程 , 以及安全机制的功能测试结果。

5.2.1.4.4 设计文档

设计文档应当具有描述制造厂家的保护宗旨以及怎样把这种宗旨转换成 TCB 的解释。如果 TCB 是由不同的模块组成 , 则应描述这些模块之间的接口。

5.2.2 C2 级 : 可控制访问保护

这一级实施一种比 C1 级粒度更细的自主访问控制。可通过注册过程、与安全相关事件的审计以及资源隔离等措施 , 使用户对它们的活动分别负责。下述是 C2 级的最低要求。

5.2.2.1 安全策略

5.2.2.1.1 自主访问控制

TCB 应在计算机系统已命名的用户和已命名的客体 ( 如文件和程序 ) 之间进行定义和控制访问。实施机制 ( 如自身 / 组 / 公共控制 , 访问控制表 ) 应允许用户通过已命名的单个用户或已定义的单个用户组或两者来规定和控制这些客体的共享 , 同时应提供控制 , 以限制访问权利的扩散。自主访问控制机制应当按明确的用户动作或按默认值向客体提供保护 , 避免无授权的访问。这些访问控制应既能包括或又能排除单用户粒度的访问。如已不具有访问许可的用户要得到对一个客体的访问许可 , 只应当由授权用户分配。

5.2.2.1.2 客体重用

在向一个主体初始转让、分配或重分配 TCB 的未使用存储器客体池之前 , 应废除所有包含在存储器客体内的信息授权。对已释放回系统的客体 , 有访问权的任何主体都不能使用任何先前主体动作产生的信息 , 包括已加密表示的信息。

5.2.2.2 责任

5.2.2.2.1 标识和鉴别

在开始执行 TCB 仲裁的任何其他动作之前 , TCB 要求用户自己向 TCB 作出标识。因此 , TCB 应使用一种受保护的机制 ( 如口令 ) 来鉴别用户的身份 , TCB 应保护鉴别数据 , 以使它不能被任何未授权用户访问。 TCB 应通过提供极好的保护计算机系统各个单个用户的能力来实现其责任。 TCB 还应当提供把这种身份与该单个用户发生的所有可审计动作相联系的能力。

5.2.2.2.2 审计

TCB 应能建立、维持和保护对它所保护的客体访问的审计跟踪 , 防止修改、未授权访问或破坏。审计数据应受 TCB 保护 , 以便对它的读访问被限制在对审计数据已授权的那些用户上。 TCB 应能记录下述类型的事件 : 标识和鉴别机制的使用 ; 把客体引入到一个用户的地址空间 ( 如打开文件 , 起动程序 ); 删除客体 ; 计算机操作员、系统管理员或系统安全员或后两者同时所发生的动作 ; 以及其他有关的安全事件。对每个已记录的事件 , 审计记录应标出 : 事件发生的日期和时间 ; 用户、事件的类型 ; 事件的成功或失败。对于标识和鉴别事件 , 请求源 ( 如终端 ID) 也应包括在审计记录中。对于把客体引入用户地址空间的事件和客体删除事件 , 审计记录也应包括客体名。计算机系统管理员应能基于单个用户身份有选择地审计任一或多个用户的活动。

5.2.2.3 保证

5.2.2.3.1 操作保证

5.2.2.3.1.1 系统体系结构

TCB 应维持它自己执行的区域 , 以保护它免受外部干预或篡改 ( 如对它的代码或数据结构进行修改 ) 。由 TCB 控制的资源可以是计算机系统中已定义的主体和客体的子集。 TCB 应隔离被保护的资源 , 以使它们易受访问控制 , 并达到审计要求。

5.2.2.3.1.2 系统完整性

应提供硬件特性或软件特性或同时提供两者 , 用于定期地验证 TCB 硬件和固件单元的运行正确性。

5.2.2.3.2 生存周期保证

5.2.2.3.2.1 安全测试

应对计算机系统的安全机制进行测试 , 并按系统文档的要求工作 , 测试应当保证 ; 没有明显的让未授权用户旁越的途径 , 或没有其他击败 TCB 安全保护机制的方法。测试还应包括搜索明显的缺陷 , 这些缺陷会使资源隔离破坏或会允许对审计或鉴别数据的未授权访问 , 见附录 C( 补充件 ) 。

5.2.2.4 文档

5.2.2.4.1 安全特性的用户指南

用户文档中的摘要 , 章节或手册应描述由 TCB 提供的保护机制 , 有关它们使用的指南以及它们如何相互作用。

5.2.2.4.2 可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告 , 这种特权在一个安全设施运行时应受到控制。对各类审计事件 , 应给出供检查和维护审计文件以及详细审计记录结构用的规程。

5.2.2.4.3 测试文档

系统开发者应向评估者提供一个文档 , 该文档描述测试计划、如何测试安全机制的测试过程以及安全机制的功能测试结果。

5.2.2.4.4 设计文档

设计文档应当具有描述制造厂家的保护宗旨以及怎样把这种宗旨转换成 TCB 的解释。如果 TCB 是由不同的模块组成 , 则应描述这些模块之间的接口。

5.3 B 等 : 强制保护

本等分为 B1, B2 和 B3 三个级别 , 它主要要求客体必须保留敏感标号 ,TCB 利用它去施加强制访问控制保护。在本等级中 , 对于计算机系统中大多数数据结构都必须带有敏感标号 ; 系统开发者要提供安全策略模型 , 根据此模型生成 TCB 。同时系统开发者也要提供 TCB 的技术规范说明并提供基准监控器概念已被实现的证据。

5.3.1 B1 级 : 有标号的安全保护

B1 级要求具有 C2 级的全部特征。另外 , 必须提出安全策略模型的非形式化说明、数据标号以及已命名主体对客体的强制访问控制。对输出信息必须有正确的标号能力 ; 必须排除任何经测试而标识的缺陷。下述是 B1 级的最低要求。

5.3.1.1 安全策略

5.3.1.1.1 自主访问控制

TCB 应在计算机系统已命名的用户和已命名的客体 ( 如文件和程序 ) 之间进行定义和控制访问。实施机制 ( 如自身 / 组 / 公共控制 , 访问控制表 ) 应允许用户通过已命名的单个用户或已定义的单个用户组或两者来规定和控制这些客体的共享 , 同时应提供控制 , 以限制访问权利的扩散。自主访问控制应既能包括或又能排除单用户粒度的访问。如已不具有访问许可的用户要得到对一个客体的访问许可 , 只应当由授权用户分配。

5.3.1.1.2 客体重用

在向一个主体初始转让、分配或重分配 TCB 的未使用存储器客体池之前 , 应废除所有包含在存储器客体内的信息授权。对已释放回系统的客体 , 有访问权的任何主体都不能使用任何先前主体动作产生的信息 , 包括已加密表示的信息。

5.3.1.1.3 标号

与每个主体及在其控制下的存储器客体 ( 如进程、文件、段、设备 ) 有关的敏感标号应由 TCB 维护。这些标号应被用作强制访问控制判断的依据。为了输入无标号的数据 , TCB 应提出要求 , 并从授权用户那里接受该数据的安全等级 , 而且 TCB 应对主体的所有这类活动都能

进行审计。

5.3.1.1.3.1 标号完整性

敏感标号应能准确地表示特定主体或客体的安全等级 , 主体和客体应以此发生关联。当 TCB 输出时 , 敏感标号应能准确地和明确地表示内部标号 , 而且应与正在输出的信息发生联系。

5.3.1.1.3.2 有标号信息的输出

TCB 应对每个通信信道和 I/O 设备标明单级或多级。这个标志的任何变化都应由人工实现 , 并可由 TCB 审计。 TCB 应维持并且能够对安全等级的任何变化进行审定 , 或对与通信信道或 I/O 设备有关的等级进行审计。

5.3.1.1.3.2.1 向多级设备的输出

当 TCB 将一客体输出到一个多级 I/O 设备时 , 与该客体有关的敏感标号也应输出。应与输出信息相同的形式 ( 如机器可读或人可读形式 ) 驻留在同一物理媒体上。当 TCB 在多级通信信道上输出或输入一客体时 , 该信道使用的协议应在敏感标号和被发送或被接收的有关信息之间提供明确的配对关系。

5.3.1.1.3.2.2 向单级设备的输出

单级 I/O 设备和单级通信信道不需要维持其处理信息的敏感标号。但是 TCB 应包含一种机制 , TCB 和一个授权用户按该机制可靠地与指定的单安全级的信息通信。这种信息经由单级通信信道或 I/O 设备输入 / 输出。

5.3.1.1.3.2.3 人可读标记的输出

计算机系统管理员应能规定与输出敏感标号有关的可打印标号名。 TCB 应标记所有人可读的、编页的、具有人可读的敏感标号的硬拷贝输出 ( 如行打印机输出 ) 的开始和结束 , 它适当地 1) 表示输出敏感性。 TCB 应按默认值标记人可读的、编页的、具有人可读的敏感标号的硬拷贝输出 ( 如行打印机输出 ) 每页的顶部和底部 , 它适当地 1) 表示该输出总的敏感性 , 或适当地 1) 表示该页信息的敏感性。 TCB 应该按默认值，并以一种适当方法标记具有人可读的敏感标号的其他形式的人可读的输出 ( 如图、图形 ), 它适当地 1) 表示该输出的敏感性。这些标记默认值的任何滥用都应由 TCB 审计。

注 : 1) 人可读敏感标号的分层密级应等于与该标号输出有关的任何信息的最大分层密级 ; 非分层等级应包括与该标号输出有关信息的全部非分层等级 , 但不包括其他非分层等级。

5.3.1.1.4 强制访问控制

TCB 应对全部主体及在其控制下的存储器客体 ( 如进程、文件、段、设备 ) 实施强制访问控制策略。这些主体和客体 , 应给予敏感标号 , 这些标号是分层密级和非分层等级的结合 , 而且应作为强制访问控制判断的依据。 TCB 应能支持两种或两种以上安全等级 , 见附录 B( 补充件 ) 。对于在受 TCB 控制的主体和客体之间的全部访问应遵循下列要求 : 仅当主体安全级中的分层密级大于或等于客体安全级中的分层密级 , 而且主体安全级中非分层等级包括了客体安全级中全部非分层等级时 , 主体才能读一个客体。仅当主体安全级中分层密级小于等于客体安全级中分层密级 , 而且主体安全级中非分层等级被包含在客体安全级中非分层等级时 , 主体才能写一个客体。 TCB 应该用标识和鉴别数据来鉴别用户的身份 , 并用来保证那些相对于 TCB 外部的可代表单个用户建立动作的主体的安全等级和授权 , 并且受批准和授权的那个用户支配。

5.3.1.2 责任

5.3.1.2.1 标识和鉴别

在开始执行 TCB 仲裁的任何其他动作之前 , TCB 要求用户自己向 TCB 作出标识。因此 , TCB 应维持鉴别数据 , 该数据包括用于验证单个用户身份的信息以及用于确定批准和授权单个用户的信息 , 这种数据应被 TCB 用来鉴别用户身份 , 以及保证那些相对于 TCB 外部的可代表单个用户建立动作的主体的安全等级和授权 , 并且受批准和授权那个用户支配 .TCB 应保护鉴别数据 , 以使它不能被任何未授权用户访问 .TCB 应通过提供极好的标识计算机系统各个单个用户的能力来实现其责任。 TCB 还应具有把这种身份与该单个用户发生的所有可审计动作相联系的能力。

5.3.1.2.2 审计

TCB 应能建立、维持和保护对它所保护的客体访问的审计跟踪 , 防止修改、未授权访问或破坏。审计数据应受 TCB 保护 , 以便对它的读访问被限制在对审计数据已授权的那些用户上。 TCB 应能记录下述类型的事件 : 标识和鉴别机制的作用 ; 把客体引入到一个用户的地址空间 ( 如打开文件 , 起动程序 ); 删除客体 ; 计算机操作员、系统管理员或系统安全员或后两者同时所发生的动作 ; 以及其他有关的安全事件。 TCB 还应能审计人可读标记的输出的任何滥用。对每个记录的事件 , 审计记录应标出 : 事件发生的日期和时间 ; 用户事件的类型 ; 事件的成功或失败。对于标识和鉴别事件 , 请求源 ( 如终端 ID) 应包括在审计记录中。对于把客体引入用户地址空间的事件和客体删除事件 , 审计记录应包括客体名和客体的安全等级。计算机系统管理员应能基于每个用户身份或客体安全级或同时基于两者有选择地审计任一或多个用户的活动。

5.3.1.3 保证

5.3.1.3.1 操作保证

5.3.1.3.1.1 系统体系结构

TCB 应维持它自己执行的区域 , 以保护它免受外部干预或篡改 ( 如对它的代码或数据结构进行修改 ) 。由 TCB 控制的资源可以是计算机系统中已定义的主体和客体的子集。 TCB 应在其控制下通过提供不同的地址空间来维护进程隔离。 TCB 应隔离被保护的资源 , 以使它们易受访问控制 , 并达到审计要求。

5.3.1.3.1.2 系统完整性

应提供硬件特性或软件特性或同时提供两者 , 用于定期地验证 TCB 硬件和固件单元的运行正确性。

5.3.1.3.2 生存周期保证

5.3.1.3.2.1 安全测试

应对计算机系统的安全机制进行测试 , 并按系统文档的要求工作。一个充分熟悉 TCB 特定实现的小组应详细分析和测试它的设计文档、源代码和目标代码。他们的目标应是 : 暴露全部设计和实现的缺陷 , 这些缺陷将允许一个 TCB 外的主体去读、更改或删除通常在 TCB 执行强制或自主安全策略时拒绝的数据 , 并且保证没有主体 ( 尚未授权 ) 能使 TCB 进入一种对其它用户发起的通信作出响应的状态。所有已发现的缺陷应被纠正 , 或者其无效 , 而且 TCB 应重新测试 , 以验证已缺陷 , 并证明没有产生新的缺陷 , 见附录 C( 补充件 ) 。

5.3.1.3.2.2 设计规格说明和验证

应在计算机系统的整个生命周期内维持由 TCB 支撑的安全策略的非形式化或形式化模型 , 并应证实与它的原理相一致。

5.3.1.4 文档

5.3.1.4.1 安全特性的用户指南

用户文档中的摘要、章节或手册应描述由 TCB 提供的保护机制、有关它们使用的指南以及它们如何相互作用。

5.3.1.4.2 可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告 , 这种特权在一个安全设施运行时应受到控制。对各类审计事件 , 应给出供检查和维护审计文件以及详细审计记录结构用的规程。手册应描述操作员和管理员有关安全功能和用户安全特征的变化。它应提供有关系统保护特性的一致和有效的用法。如他们怎样互相作用 , 怎样安全地生成一个新的 TCB; 提供设施规程、警告和需要受控的特权 , 以便安全地操作该设施。

5.3.1.4.3 测试文档

系统开发者应向评估者提供一个文档 , 该文档描述测试计划 , 如何测试安全机制的测试过程 , 以及安全机制的功能测试结果。

5.3.1.4.4 设计文档

设计文档应当具有制造厂家的保护宗旨说明以及怎样把这种宗旨转换成 TCB 的解释。如果 TCB 是由不同的模块组成 , 则应描述这些模块之间的接口。由 TCB 实施的安全策略模型的非形式化或形式化描述应是可用的 , 而且提供一种解释来表示实施安全策略是足够的。应当标识特定的 TCB 保护机制 , 而且给出一种解释表示它们满足该模型。

5.3.2 B2 级 : 结构化保护

在 B2 级中 , TCB 是建立在对形式化安全策略模型清晰定义和提供文档的基础之上的。该模型要求执行 B1 级所建立的自主和强制访问控制 , 并扩展到计算机系统的全部主体和客体。另外 , 提出了隐蔽信道。 TCB 必须是仔细地构成严格保护和非严格保护的单元。 TCB 接口应定义恰当 , 而且 TCB 设计和实现能使它经受比较彻底的测试和比较安全的检查。要加强鉴别机制 , 以支撑系统管理员和操作员功能的方式提供可信设施管理 , 而且要加强严格的配置管理控制。该系统有相对的抗渗透能力。下述是 B2 级的最低要求。

5.3.2.1 安全策略

5.3.2.1.1 自主访问控制

TCB 应在计算机系统已命名的用户和已命名的客体 ( 如文件和程序 ) 之间进行定义和控制访问。实施机制 ( 如自身 / 组 / 公共控制 , 访问控制表 ) 应允许用户通过已命名的单个用户或已定义的单个用户组或两者来规定和控制这些客体的共享 , 同时应提供控制 , 以限制访问权利的扩散。自主访问控制机制应当按明确的用户动作或按默认值向客体提供保护 , 避免无授权的访问。这些访问控制应既能包括或又能排除单用户粒度的访问。如已不具有访问许可的用户要得到对一个客体的访问许可 , 只应当由授权用户分配。

5.3.2.1.2 客体重用

在向一个主体初始转让、分配或重分配 TCB 的未使用存储器客体池之前 , 应废除所有包含在存储器客体内的信息授权。对已释放回系统的客体 , 有访问权的任何主体都不能使用任何先前主体动作产生的信息 , 包括已加密表示的信息。

5.3.2.1.3 标号

与每个由 TCB 外部主体直接或间接访问的计算机系统资源 ( 如主体、存储器客体、 ROM) 有关的敏感标号应由 TCB 维护。这些标号应被用作强制访问控制判断的依据。为了输入无标号的数据 , TCB 应提出请求 , 并从授权用户那里接受该数据的安全等级 , 而且 TCB 应对所有这类活动进行审计。

5.3.2.1.3.1 标号完整性

敏感标号应能准确地表示特定主体或客体的安全等级 , 主体和客体应以此发生关联 , 当 TCB 输出时 , 敏感标号应能准确地和明确地表示内部标号 , 而且应与正在输出的信息发生联系。

5.3.2.1.3.2 有标号信息的输出

TCB 应对每一个通信信道和 I/O 设备标明单级或多级。这个标志的任何变化都应由人工实现 , 并可由 TCB 审计。 TCB 应维持并且能够地安全等级的任何变化进行审计 , 或对与通信信道或 I/O 设备有关的等级进行审计。

5.3.2.1.3.2.1 向多级设备的输出

当 TCB 将一客体输出到一个多级 I/O 设备时 , 与该客体有关的敏感标号也应输出。应与输出信息相同的形式 ( 如机器可读或人可读形式 ) 驻留在同一物理媒体上。当 TCB 在多级通信信道上输出或输入一客体时 , 该信道使用的协议应在敏感标号和被发送或被接收的有关信息之间提供明确的配对关系。

5.3.2.1.3.2.2 向单级设备的输出

单级 I/O 设备和单级通信信道不需要维持其处理信息的敏感标号。但是 TCB 应包含一种机制 , TCB 和一个授权用户按该机制可靠地与指定的单安全级的信息通信。这种信息经由单级通信信道或 I/O 设备输入 / 输出。

5.3.2.1.3.2.3 人可读标记的输出

计算机系统管理员应能指定与输出敏感标号有关的可打印标号名。 TCB 应标记所有人可读的、编页的、具有人可读敏感标号的硬拷贝输出 ( 如行打印机输出 ) 的开始和结束 , 它适当地 1) 表示输出敏感性。 TCB 应按默认值标记人可读的、编页的、具有人可读的敏感度标记的硬拷贝输出 ( 如行打印机输出 ) 每页的顶部和底部 , 它适当地 1) 表示该输出总的敏感性 , 或适当地 1) 表示该页信息的敏感性。 TCB 应该按默认值 , 并以一种适当方法标记具有人可读的敏感标号的其他形式的人可读输出 ( 如图、图形 ), 它适当地 1) 表示该输出的敏感性。这些标记默认值的任何滥用都应由 TCB 审计。

注 : 1) 人可读敏感标号的分层密级应等于与该标号输出有关的任何信息的最大分层密级 ; 非分层等级应包括与该标号输出有关信息的全部非分层等级 , 但不包括其他非分层等级。

5.3.2.1.3.3 主体敏感标号

在终端用户交互对话期内 , 与该用户有关的安全等级的各种变化 , TCB 应立即通知该用户。当需要显示完整的主体敏感标号时 , 终端用户应能向 TCB 提出询问。

5.3.2.1.3.4 设备标号

对各种附加物理设备 , TCB 应能支持最小和最大安全等级的分配。 TCB 应利用这些安全等级来实施由该设备安放的物理环境的强加的约速。

5.3.2.1.4 强制访问控制

TCB 应对所有被 TCB 外部主体直接或间接存取的资源 ( 如主体、存储器客体以及 I/O 设备 ) 实施强制访问控制策略。这些主体和客体应给予敏感标号。这些标号是分层密级和非分层等级的结合 , 而且应作为强制访问控制判断的依据。 TCB 应能支持两种或两种以上安全等级 , 见附录 B( 补充件 ) 。对 TCB 外部的全部主体和由这些主体直接或间接存取的全部客体之间的所有访问应遵循下列要求 : 仅当主体安全级中的分层密级大于等于客体安全级中的分层密级 , 而且主体安全级中非分层等级包括了客体安全级中全部非分层等级时 , 主体才能读一个客体 . 仅当主体安全级中分层密级小于等于客体安全级中分层密级 , 而且主体安全级中非分层等级被包括在客体安全级中非分层等级时 , 主体才能写一个客体。 TCB 应该用标识和鉴别数据来鉴别用户的身份 , 并用来保证那些相对于 TCB 外部可代表单个用户建立动作的主体的安全等级和授权 , 并且受批准和授权的那个用户支配。

5.3.2.2 责任

5.3.2.2.1 标识和鉴别

在开始执行 TCB 仲裁任何其他动作之前 , TCB 要求用户自己向 TCB 作出标识。因此 , TCB 应维持鉴别数据 , 该数据包括用于验证单个用户身份的信息以及用于确定批准和授权单个用户的信息。这种数据应被 TCB 用来鉴别用户身份 , 以及保证那些相对于 TCB 外部可代表单个用户建立动作的主体的安全等级和授权 , 并且受批准和授权的那个用户支配。 TCB 应保护鉴别数据 , 以使它不能被任何未授权用户访问。 TCB 应通过提供极好的标识计算机系统每个单个用户的能力来实现其责任。 TCB 还应具有把这种身份与该单个用户发生的所有可审计动作相联系的能力。

5.3.2.2.1.1 可信路径

TCB 应在它自身与初始注册及鉴别用户之间支持一个可信的通信路径 , 经由这种路径的通信应由一个用户独占地启动。

5.3.2.2.2 审计

TCB 应能建立、维护和保护对它所保护的客体访问的审计跟踪 , 防止修改、未授权访问或破坏。审计数据应受 TCB 保护 , 以便对它的读访问被限制在对审计数据已授权的那些用户上。 TCB 应能记当下述类型的事件 : 标识和鉴别机制的使用 ; 把客体引入到一个用户的地址空间 ( 如打开文件、启动程序 ); 删除客体 ; 计算机操作员、系统管理员或系统安全员或后两者同时所发生的动作 ; 以及其他有关的安全事件。 TCB 还应能审计人可读标记输出的任何滥用。对每个已记录的事件 , 审计记录应标出 : 事件发生的日期和时间 ; 用户、事件的类型 ; 事件的成功或失败。对于标识和鉴别事件 , 请求源 ( 如终端 ID) 应包括在审计记录中。对于把客体引入用户地址空间的事件和客体删除事件 , 审计记录应包括客体名和客体的安全等级。计算机系统管理员应能基于单个用户身份或客体安全级或同时基于两者有选择地审计任一或多个用户的活动。 TCB 应能审计利用隐蔽存储信道的标识事件。

5.3.2.3 保证

5.3.2.3.1 操作保证

5.3.2.3.1.1 系统体系结构

TCB 应维护它自己执行的区域 , 以保护它免受外来干预或篡改 ( 如对它代码或数据结构修改 ) 。 TCB 应在其控制下 , 通过提供不同的地址空间来维护进行隔离。 TCB 内部应由定义恰当的、基本上独立的模块构成。它应有效地使用可获得的硬件 , 把那些严格保护的单元与那些不严格保护的单元分离开来。 TCB 模块应如此设计 , 以便它能实施最小特权原则。硬件中诸如分段的特性 , 应被用来支持逻辑上截然不同的存储器客体 , 这些客体具有分离的属性 ( 如 : 可读、可写 ) 。应完整地定义用户与 TCB 的接口 , 并标识所有 TCB 的单元。

5.3.2.3.1.2 系统完整性

应提供硬件特性或软件特性或同时提供两者 , 用于定期地验证 TCB 硬件和固件单元的运行正确性。

5.3.2.3.1.3 隐蔽信道分析

系统开发者应对隐蔽存储信道作彻底地搜查 , 并且通过实际测量或通过工程估计确定每个已标识信道的最大带宽 , 见附录 A( 补充件 ) 。

5.3.2.1.4 可信设施管理

TCB 应支持操作员和管理员的职能分隔。

5.3.2.3.2 生存周期保证

5.3.2.3.2.1 安全测试

应对计算机系统的安全机制进行测试 , 并按系统文档的要求工作。一个充分熟悉 TCB 特定实现的小组应详细分析和测试它的设计文档、源代码和目标代码。它们的目标应是 : 暴露全部设计和实现的缺陷 , 这些缺陷将允许一个 TCB 外的主体去读、更改或删除通常在 TCB 实施强制或自主安全策略时拒绝的数据 , 并且保证没有主体 ( 尚未授权 ) 能使 TCB 进入一种对其它用户启动的通信作出响应的状态。 TCB 应建立相对的抗渗透能力。所有已发现的缺陷应被纠正 , 而且 TCB 应重新测试 , 以验证已排除缺陷 , 并证明没有产生新的缺陷。测试应证明 TCB 的实现与描述性顶层规格说明相一致 , 见附录 C( 补充件 ) 。

5.3.2.3.2.2 设计规格说明和验证

应在计算机系统的整个生命周期内维持由 TCB 支撑的安全策略形式化模型、并证明与它的原理相一致。应维持 TCB 的描述性顶层规格说明 (DTLS), 以使用异常、出错消息和影响等方面来完整地和准确地描述 TCB, 还应说明描述性顶层规格说明是 TCB 接口的准确描述。

5.3.2.3.2.3 配置管理

在 TCB 开发和维护期间 , 应把配置管理系统放在适当的位置 , 以维持对描述性顶层规格说明、其他设计数据、实现文档、源代码、目标代码的运行版本以及测试夹具和文档等方面改变的控制。配置管理系统应保证与当前 TCB 版本相关联的所有文档和代码之间的一致的映射。应提供由源代码生成新的 TCB 版本的工具。另外 , 还应获得 TCB 新旧版本比较的工具 , 以便查明实际用作新版本的 TCB 的代码只发生了所需的改动。

5.3.2.4 文档

5.3.2.4.1 安全特性的用户指南

用户文档中的摘要、章节或手册应描述由 TCB 提供的保护机制、有关它们使用的指南以及它们如何相互作用。

5.3.2.4.2 可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告 , 这种特权在一个安全设施运行时应受到控制。对各类审计事件 , 应给出供检查和维护审计文件以及详细审计记录结构用的规程。手册应描述操作员和管理员有关安全功能和用户

安全特征的变化。它应提供有关系统保护特性的一致和有效的用法。如它们怎样互相作用 , 怎样安全地生成一个新的 TCB; 提供设施规程、警告和需要受控的特权 , 以便安全地操作该设施。应标识基准确认机制的 TCB 模块。 TCB 的任何模块修改后 , 应描述由源代码安全生成新 TCB 过程。

5.3.2.4.3 测试文档

系统开发者应向评估者提供一个文档。该文档描述测试计划 , 怎样测试安全机制的测试过程 , 以及安全机制的功能测试结果 ; 它应包括用来减少隐蔽信道带宽方法的有效性测试结果。

5.3.2.4.4 设计文档

设计文档应当具有制造厂家的保护宗旨说明以及怎样把这种宗旨转换成 TCB 的解释。也应描述 TCB 模块之间的接口。由 TCB 实施的安全策略模型形式化描述应是可用的 , 并且证明它对于实施安全策略是足够的。应当标识特定的 TCB 保护机制 , 而且给出一种解释表示它们满足该模型。描述性顶层规格说明应当表明 TCB 接口的准确描述。文档应描述 TCB 怎样实现基准监控器概念 , 并解释它为什么能防篡改 , 为什么不能被旁越 , 以及为什么它能被正确地实现。文档应描述如何构造 TCB 才便于测试和实施最小特权。该文档还应给出隐蔽信道分析的结果和与限定该信道有关的折衷方案。应当标识可用来利用已知隐蔽存储信道的所有可审计事件。由于已知隐蔽存储信道的使用不是用审计机制可检测的 , 所以应提供已知隐蔽存储信道的带宽 , 见附录 A( 补充件 ) 。

5.3.3 B3 级 : 安全域

B3 级 TCB 必须满足基准监控器的要求 , 以便它能仲裁所有主体向客体的访问。它必须是防篡改的 , 而且是小到足以提供分析和测试。为此 , 在 TCB 设计及实现期间 , 要用有效的系统工程方法 , 使构造的 TCB 能排除与安全策略实施无关的代码 , 从而使其复杂性达到最小。要支持安全管理员 ; 要把审计机制扩展到用信号报知与安全有关的事件 ; 并且要提供系统恢复过程。该系统有高度的抗渗透能力。下述是 B3 级的最低要求 :

5.3.3.1 安全策略

5.3.3.1.1 自主访问控制

TCB 应在计算机系统已命名的用户和已命名的客体 ( 如文件和程序 ) 之间进行定义和控制访问。实施机制 ( 如访问控制表 ) 应允许用户通过已命名的单个用户或已定义的单个用户组或两者来规定和控制这些客体的共享 , 同时应提供控制 , 以限制访问权利的扩散。自主访问控制机制应当按明确的用户动作或按默认值向客体提供保护 , 避免无授权的访问。对于每个已命名的客体 , 这些访问控制应能规定一份已命名的单个用户表和一份已命名的单个用户组表 , 以表示它们对该客体相应的访问方式。此外 , 对于每个已如此命名的客体 , 应能规定不能访问该客体的已命名单个用户表和已命名单个用户组表。如已不拥有访问许可的用户要得到对一个客体的访问许可 , 只应当由授权用户分配。

5.3.3.1.2 客体重用

在向一个主体初始转让、分配或重分析 TCB 的未使用存储器客体池之前 , 应废除所有包含在存储器客体内的信息授权。对已释放回系统的客体 , 有访问权的任何主体都不能使用任何先前主体动作产生的信息 , 包括已加密表示的信息。

5.3.3.1.3 标号

与每个由 TCB 外部主体直接或间接访问的计算机系统资源 ( 如主体、存储器客体、 ROM) 有关的敏感标号应由 TCB 维护。这些标号应被用作强制访问控制判断的依据。为了输入无标号的数据。 TCB 应提出请求 , 并从授权用户那里接受该数据的安全等级 , 而且 TCB 应对所有这类活动进行审计。

5.3.3.1.3.1 标号完整性

敏感标号应能准确地表示特定主体或客体的安全等级 , 主体和客体应以此发生关联。当 TCB 输出时 , 敏感标号应能准确地和明确地表示内部标号 , 而且应与正在输出的信息发生联系。

5.3.3.1.3.2 有标号信息的输出

TCB 应对每个通信信道和 I/O 设备标明单级或多级。这个标志的任何变化都应由人工实现 , 并可由 TCB 审计。 TCB 应维持并且能够对安全等级的任何变化进行审计 , 或对与通信信道或 I/O 设备有在的等级进行审计。

5.3.3.1.3.2.1 向多级设备的输出

当 TCB 将一客体输出到一个多级 I/O 设备时，与该客体有关的敏感标号也应输出。应与输出信息相同的形式（如机器可读或人可读形式）驻留在同一物理媒体上。当 TCB 在多级通信信道上输出或输入一客体时，该信道使用的协议应在敏感标号和被发送或被接收的有关信息之间提供明确的配对关系。

5.3.3.1.3.2.2 向单级设备的输出

单级 I/O 设备和单级通信信道不需要维持其处理信息的敏感标号。但是 TCB 应包含一种机制 , TCB 和一个授权用户应按该机制可靠地与指定的单安全级的信息通信。这种信息经由单级通信信道或 I/O 设备输入 / 输出。

5.3.3.1.3.2.3 人可读标记的输出

计算机系统管理员应能指定与输出敏感标号有关的可打印标号名。 TCB 应标记所有人可读的、编页的、具有人可读敏感标号的硬拷贝输出 ( 如行打印机输出 ) 的开始和结束 , 它适当地 1) 表示输出敏感性。 TCB 应按默认值标记人可读的、编页的 , 具有人可读的敏感标记的硬拷贝输出 ( 如行打印机输出 ) 每页的顶部和底部 , 它适当地 1) 表示该输出总的敏感性 , 或适当地 1) 表示该页信息的敏感性。 TCB 应该按默认值 , 并以一种适当方法标记具有人可读敏感标号的其他形式的人可读输出 ( 如图、图形 ), 它适当地 1) 表示该输出敏感性。这些默认值的任何滥用都应由 TCB 审计。

注 : 1) 人可读敏感标号的分层密级应等于与该标号输出有关的任何信息的最大分层密级 ; 非分层等级应包括与该标号输出有关信息的全部非分层等级 , 但不包括其他非分层等级。

5.3.3.1.3.3 主体敏感标号

在终端用户交互对话期内 , 与该用户有关的安全等级的各种变化 TCB 应立即通知该用户。当需要显示完整的主体敏感标号时 , 终端用户应能向 TCB 提出询问。

5.3.3.1.3.4 设备标号

对各种附加物理设备 , TCB 应能支持最小和最大安全等级的分配。 TCB 应利用这些安全等级来实施由该设备安放的物理环境所强加的约束。

5.3.3.1.4 强制访问控制

TCB 应对所有被 TCB 外部主体直接或间接访问的资源 ( 如主体、存储器客体以及 I/O 设备 ) 实施强制访问控制策略 , 这些主体和客体应给予敏感标号。这些标号是分层密级和非分层等级的结合 , 而且应作为强制访问控制判断的依据。 TCB 应能支持两种或两种以上安全等级 , 见附录 B( 补充件 ) 。对 TCB 外部的全部主体和由这些主体直接或间接存取的全部客体之间的所有访问应遵循下列要求 : 仅当主体安全级中的分层密级大于等于客体安全级中的分层密级 , 而且主体安全级中非分层等级包括了客体安全级中全部非分层等级时 , 主体才能读一个客全。仅当主体安全级中分层密级小于等于客体安全级中分层密级 , 而且主体安全级中非分层等级被包含在客体安全级中非分层等级时 , 主体才能写一个客体。 TCB 应该用标识和鉴别数据来鉴别用户的身份 , 并用来保证那些相对于 TCB 外部可代表单个用户建立动作的主体的安全等级和授权 , 并且受批准和授权的那个用户支配。

5.3.3.2 责任

5.3.3.2.1 标识和鉴别

在开始执行 TCB 仲裁任何其他动作之前 , 应要求用户自己向 TCB 作出标识。因此 , TCB 应维护鉴别数据 , 该数据包括用于验证单个用户身份的信息以及为确定批准和授权单个用户的信息。这种数据应被 TCB 用来鉴别用户身份 , 以及保证那些相对于 TCB 外部的可代表单个用户建立动作的主体的安全等级和授权 , 并且受批准和授权那个用户支配。 TCB 应保护鉴别数据 , 以使它不能被任何未授权用户访问。 TCB 应通过提供极好的标识计算机系统每个单个用户的能力来实现其责任。 TCB 还应具有把这种身份与该单个用户所发生的所有可审计动作相联系的能力。

5.3.3.2.1.1 可信路径

TCB 应支持自身与诸用户之间的可信通信路径 , 以供 TCB 与用户需要可靠连接 ( 如注册、改变主体安全等级 ) 时使用。经由这种可信路径的通信安全由一个用户或 TCB 独占地激活。这种路径逻辑上应与其他路径隔离 , 并与其他路径截然地区分开来。

5.3.3.2.2 审计

TCB 应能建立、维持和保护对它所保护的客体访问的审计跟踪 , 防止修改、未授权访问或破坏。审计数据应受 TCB 保护 , 对便对它的读访问被限制在对审计数据已授权的那些用户上。 TCB 应能记录下述类型的事件 : 标识和鉴别机制的使用 ; 把客体引入到一个用户地址空

间 ( 如打开文件 , 启动程序 ); 删除客体 ; 计算机操作员、系统管理员或系统安全员或后两者同时所发生的动作 ; 以及其他有关的安全事件。 TCB 还应能审计人可读标记输出的任何滥用。对每个已记录的事件 , 审计记录应标出 : 事件发生的日期和时间 ; 用户、事件的类型 ; 理件的成功或失败。对于标识和鉴别事件 , 请求源 ( 如终端 ID) 应包括在审计记录中。对于把客体引入用户地址空间的事件和客体删除事件 , 审计记录应包括客体名和客体的安全等级。计算机系统管理员应能基于单个用户身份或客体安全级或同时基于两者有选择地审计任一或多个用户的活动。 TCB 应能审计利用隐蔽存储通道的标识事件。 TCB 应包含一种机制 , 它能监控安全可审计事件的发生或累积 , 从而可以指出安全策略迫在眉睫的破坏。当阈值超过时 , 这种机制应能立即通知安全管理员 , 而且当这些有关安全事件的发生或积累再继续下去时 , 则系统应采取最小破坏的操作终止该事件。

5.3.3.3 保证

5.3.3.3.1 操作保证

5.3.3.3.1.1 系统体系结构

TCB 应维持它自己执行的区域 , 以保护它免受外来干预或篡改 ( 如对它代码或数据结构修改 ) 。 TCB 应在其控制下 , 通过提供不同的地址空间来维护进程隔离 , TCB 内部应由定义恰当的、基本上独立的模块构成。它应有效地使用可获得的硬件 , 把那些严格保护的单元与那些不严格保护的单元分离开来。 TCB 模块应如此设计 , 以便它能执行最小特权原则。硬件中诸如分段的特性 , 应被用来支持逻辑上截然不同的存储器客体 , 这些客体具有分离的属性 ( 如可读、可写 ) 。应完整地定义用户与 TCB 的接口 , 并标识所有 TCB 的单元。 TCB 的设计和构造应使用一种完整的、原理简单的、具有精确定义语义的保护机制 , 这种机制在实现 TCB 和系统内部结构时将起中心的作用。 TCB 应把分层、抽象和数据隐蔽等方面的有效使用结合起来。有效的系统工程应以 TCB 的复杂度极小化为目标 , 而且应排除没有严格保护的 TCB 模块。

5.3.3.3.1.2 系统完整性

应提供硬件特性或软件特性或同时提供两者 , 用于定期地验证 TCB 硬件和固件单元的运行正确性。

5.3.3.3.1.3 隐蔽信道分析

系统开发者应对隐蔽信道作彻底的搜查 , 并且通过实际测量或通过工程估计确定每个已标识信道的最大带宽 , 见附录 A( 补充件 ) 。

5.3.3.3.1.4 可信设施管理

TCB 应支持操作员和管理员的职能分隔。应标识在安全管理员任务中所执行的职能。只有在计算机系统上发生了与安全管理员任务截然不同的可审计活动后 , 计算机系统管理员才能执行安全管理员职能。在安全管理任务中所能执行的非安全职能应严格限制在那些对有效执行完全任务必不可少的职能。

5.3.3.3.1.5 可信恢复

在计算机系统故障或其它间断后 , 应提供规程或机制或同时提供两者 , 以保证在不危及保护情况下 , 使系统得到恢复。

5.3.3.3.2 生存周期保证

5.3.3.3.2.1 安全测试

应对计算机系统的安全机制进行测试 , 并按系统文档的要求工作。一个充分熟悉 TCB 特定实现的小组应详细分析和测试它的设计文档、源代码和目标代码。它们的自然应是 : 暴露全部设计和实现的缺陷 , 这些缺陷将允许一个 TCB 外的主体去读、更改或删除通常由 TCB 实施强制或自主安全策略时拒绝的数据 , 并且保证没有主体 ( 尚未授权 ) 能使 TCB 进入一种对其它用户启动的通信作出响应的状态。 TCB 应建立相对的抗渗透能力 . 所有已发现的缺陷应被纠正 , 而且 TCB 应重新测试 , 以验证 TCB 已排除缺陷 , 并证明没有产生新的缺陷。测试应证明 TCB 的实现与描述性顶层规格说明相一致 , 见附录 C( 补充件 ) 。在测试中 , 没有发现设计缺陷 , 也许发现少量可校正的实现缺陷 , 而应该确信这少量缺陷的存在是合理的。

5.3.3.3.2.2 设计规格说明和验证

应在计算机系统的整个生命周期内维持由 TCB 支撑的安全策略的形式化模型 , 并证明与它的原理是一致的。应维持 TCB 的描述性顶层规格说明 , 以便用异常、出错消息和影响等方面来完整地和准确地描述 TCB, 还应说明描述性顶层规格说明是 TCB 接口的准确描述。应给出有说服力的证据 , 以表明描述性顶层规格说明与该模型的一致性。

5.3.3.3.2.3 配置管理 在 TCB 开发和维护期间 , 应把配置管理系统放在适当的位置 , 以维护对描述性顶层规格说明、其他设计数据、实现文档、源代码、目标代码的运行版本以及测试夹具和文档等方面改变的控制。配置管理系统应保证与当前 TCB 版本相关联的所有文档和代码之间一致的映射 , 应提供由源代码生成新的 TCB 版本的工具。另外 , 还应获得 TCB 新旧版本比较的工具 , 以便查明实际用作新版本的 TCB 的代码只发生了所需的改动。

5.3.3.4 文档

5.3.3.4.1 安全特性的用户指南

用户文档中的摘要、章节或手册应描述由 TCB 提供的保护机制 , 有关它们使用的指南以及它们如何相互作用。

5.3.3.4.2 可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告 , 这种特权在一个安全设施运行时应受到控制。对各类审计事件 , 应给出供检查和维护审计文件以及详细审计记录结构用的规程。手册应描述操作员和管理员有关安全功能和用户安全特性的变化。它应提供有关系统保护特性的一致和有效的用法。如它们怎样互相作用 , 怎样安全地生成一个新的 TCB, 提供设施规程 , 警告和需要受控的特权 , 以便安全地操作该设施。应标识基准确认机制的 TCB 模块 , TCB 的任何模块修改后 , 应描述由源代码安全生成新 TCB 的过程。它应包括保证系统以安全方式启动的过程 , 还应包括那些在系统运行间断后 , 重新开始安全运行的过程。

5.3.3.4.3 测试文档

系统开发者应向评估者提供一个文档 , 该文档描述测试计划 , 怎样测试安全机制的测试过程以及安全机制的功能测试结果。它应包括用来减少隐蔽信道带宽方法的有效性测试结果。

5.3.3.4.4 设计文档

设计文档应当具有制造厂家的保护宗旨说明以及怎样把这种宗旨转换成 TCB 的解释。也应描述 TCB 模块之间的接口。由 TCB 实施的安全策略模型形式化描述应是可用的 , 并且证明它对实施安全策略是足够的。应当标识特定的 TCB 保护机制 , 而且给出一种解释表示它们满足该模型。应当表明描述性顶层规格说明是 TCB 接口的准确描述。文档应描述 TCB 怎样实施基准监控器概念 , 并解释它为什么能防篡改 , 为什么不能被旁越 , 以及为什么它能被正确地实现。 TCB 的实现 ( 如硬件、固件和软件方式 ) 应非形式化地表明与描述性顶层规格说明相一致。应使用非形式化技术表明描述性顶层规格说明的要素与 TCB 单元相一致。文档应描述如何构造 TCB 才便于测试和实施最小特权。该文档还应给出隐蔽信道分析的结果和与限定该信道有关的折衷方案。应当标识可用来利用已知隐蔽存储信道的所有可审计事件。由于已知隐蔽存储信道的使用不是用审计机制可检测的 , 所以应提供已知隐蔽存储信道的带宽 , 见附录 A( 补充件 ) 。

5.4 A 等 : 验证保护

本等级的特征是使用形式化安全验证方法 , 以保证系统采用的强制和自主安全控制能有效地保护该系统存储或处理的保密或其它敏感信息。为了证明 TCB 满足设计、开发和实现各方面的安全要求 , 需要扩展文件。该等分为 A1 和超 A1 两级。

5.4.1 A1 级 : 验证设计

A1 级在功能上与 B3 级相同 , 不必增加任何关于策略或结构特性的要求。本等级的显著特点是用形式化顶层规范说明 (FTLS0 和验证技术来进行分析 , 以确保 TCB 完全正确地实现。实际上 , 由于这种保证是开始于安全策略的形式化模型和设计形式化顶层规格说明 , 所以它是不断发展的。

在这里 , 无论使用何种特殊规格语言或验证系统 , 对该级的设计验证必须遵循以下五条原则 :

a. 必须能对安全策略的形式化模型进行清晰地验证和文件化 , 包括要求用数学方法证明模型与公理的一致性，模型对安全策略支持的有效性。

b. 形式化顶层规格说明必须提出包括 TCB 完成功能的同象定义和用于支持隔离执行区域的硬件或固件机制或硬件和固件机制的抽象定义。

c. 如有验证工具 , 应使用形式化技术证明 TCB 的形式化顶层规格说明和模型的一致性 , 否则可采用非形式化技术。

d. 必须能用非形式化技术证明 TCB 的工具 ( 如 : 硬件、固件和软件 ) 与形式化顶层规格说明的一致性。还能用非形式化技术证明形式化顶层规格说明的各要素对应于 TCB 的各单位。形式化顶层规格说明必须能表示符合安全策略要求的统一的保护机制 , 而且 TCB 各单元的映射正是保护机制的要素。

e. 必须使用形式化分析技术去标识和分析隐蔽信道 , 非形式化技术可用于标识隐蔽定时信道 , 在系统中 , 必须对被标识的隐蔽信道的连续存在加以说明。

为了配合 A1 级所要求的 TCB 扩展设计和开发分析 , 需要更严格的配置管理 , 并建立把该级安全地分配到现场的过程。要支持系统安全管理员。

下述是 A1 级的最低要求

5.4.1.1 安全策略

5.4.1.1.1 自主访问控制

TCB 应在计算机系统已命名的用户和已命名的客体 ( 如事件和程序 ) 之间进行定义和控制访问。实施机制 ( 如访问控制表 ) 应允许用户通过已命名的单个用户或已定义的单个用户组或两者来规定和控制这些客体的共享 , 同时应提供控制 , 以限制访问权利的扩散。自主访问控制机制应当按明确的用户动作或按默认值向客体提供保护 , 避免无授权的访问。对于每个命名的客体 , 这些访问控制应能指定一份已命名的单个用户表和一份已命名的单个用户组表 , 以表示它们对该客体相应的访问方式。此外 , 对于每个已如此命名的客体 , 应能规定不能访问该客体的已命名单个用户表和已命名单个用户组表。如已不拥有访问许可的用户要得到对一个客体的访问许可 , 只应当由授权用户分配。

5.4.1.1.2 客体重用

在向一个主体初次转让、分配或重分配 TCB 的未使用存储器客体池之前 , 应废除所有包含在存储器客体内的信息授权。对已释放回系统的客体 , 有访问权的任何主体都不能使用任何先前主体动作产生的信息 , 包括已加密表示的信息。

5.4.1.1.3 标号

与每个由 TCB 外部主体直接或间接访问的计算机系统资源 ( 如主体 , 存储器客体、 ROM) 有关的敏感标号应由 TCB 维护。这些标号应被用作强制访问控制判断的依据。为了输入无标号的数据 , TCB 应提出请求 , 并从授权用户那里接受该数据的安全等级 , 而且 TCB 应对所有这类活动进行审计。

5.4.1.1.3.1 标号完整性

敏感标号应能准确地表示特定主体或客体的安全等级 , 主体和客体应以此发生关联。当 TCB 输出时 , 敏感标号应能准确地和明确地表示内部标号 , 而且与正在输出的信息发生联系。

5.4.1.1.3.2 有标号信息的输出

TCB 应对每个通信信道和 I/O 设备标明单级或多级。这个标志的任何变化都应由人工实现 , 并可由 TCB 审计。 TCB 应维持并且能够对安全等级的任何变化进行审计 , 或对与通信信道或 I/O 设备有关的等级进行审计。

5.4.1.1.3.2.1 向多级设备的输出

当 TCB 将一客体输出到一个多级 I/O 设备时 , 与该客体有关的敏感标号也应输出。应与输出信息相同的形式 ( 如机器可读或人可读形式 ) 驻留在同一物理媒体上。当 TCB 在多级通信信道上输出或输入一客体时 , 该信道使用的协议应在敏感标号和被发送或被接收的有关信息之间提供明确的配对关系。

5.4.1.1.3.2.2 向单级设备的输出

单级 I/O 设备和单级通信信道不需要维持其处理信息的敏感标号。但是 TCB 应包含一种机制 , TCB 和一个授权用户应按该机制可靠地与指定的单安全级的信息通信。这种信息经由单级通信信道 I/O 设备输入 / 输出。

5.4.1.1.3.2.3 人可读标记的输出

计算机系统管理员应能指定与输出敏感标号有关的可打印标号名。 TCB 应标记的有人可读的、编页的、具有人可读的敏感标号的硬拷贝输出 ( 如行打印机输出 ) 的开始和结束 , 它适当地 1) 表示输出敏感性。 TCB 应按默认值标记人可读的、编页的、具有人可读的敏感标记的硬拷贝输出 ( 如行打印机输出 ) 每页的顶部和底部 , 它适当地 1) 表示该输出总的敏感性。或适当地 1) 表示该页信息的敏感性。 TCB 应该按默认值 , 并以一个适当方法标记具有人可读的敏感标号的其他形式的人可读的输出 ( 如图、图形 ), 它适当地 1) 表示该输出敏感性。这些标记默认值的任何滥有都应由 TCB 审计。

注 : 1) 人可读的敏感标号的分层密级应等于与该标号输出有关的任何信息的最大分层密级 , 非分层等级应包括与该标号输出有关信息的全部非分层等级 , 但不包括其他非分层等级。

5.4.1.1.3.3 主体敏感标号

在终端用户交互对话期内 , 与该用户有关的安全等级的各种变化 TCB 应立即通知该用户。当需要显示完整的主体敏感标号时 , 终端用户应能向 TCB 提出询问。

5.4.1.1.3.4 设备标号

对各种附加物理设备 , TCB 应能支持最小和最大安全等级的分配。 TCB 应利用这些安全等级来执行由该设备安放的物理环境所强加的约束。

5.4.1.1.4 强制访问控制

TCB 应对所有被 TCB 外部主体直接或间接访问的资源 ( 如主体、存储器客体以及 I/O 设备 ) 实施强制访问控制策略 , 这些主体和客体应给予敏感标号。这些标号是分层密级和非分层等级的结合 , 而且应作为强制访问控制判断的依据。 TCB 应能支持两种或两种以上安全等级 , 见附录 B( 补充件 ) 。对 TCB 外部的全部主体和由这些主体直接或间接访问的全部客体之间的所有存取应遵循下列要求 : 仅当主体安全级中的分层密级大于等于客体安全级中的分层密级 , 而且主体安全级中非分层等级包括了客体安全级中全部非分层等级时 , 主体才能读一个客体。仅当主体安全级中分层密级小于等于客体安全级中分层密级 , 而且主体安全级中非分层等级被包含在客体安全级中非分层等级时 , 主体才能写一个名称。 TCB 应该用标识和鉴别数据来鉴别用户的身份 , 并用来保证那些相对于 TCB 外部可代表单个用户建立动作的主体的安全等级和授权 , 并且受批准和授权的那个用户支配。

5.4.1.2 责任

5.4.1.2.1 标识和鉴别

在开始执行 TCB 仲裁的任何其他动作之前 , 应要求用户自己向 TCB 作出标识。因此 , TCB 应维持鉴别数据 , 该数据包括用于检验单个用户身份的信息和为确定批准和授权单个用户的信息。这种数据应被 TCB 用来鉴别用户身份 , 以及保证那些相对于 TCB 外部可代表单个用户建立动作的主体的安全等级和授权 , 并且受批准和授权那个用户支配。 TCB 应保护鉴别数据 , 以使它不能被任何未授权用户访问。 TCB 应通过提供极好的标识计算机系统每个单个用户的能力来实现其责任。 TCB 还应具有把这种身份与该单个用户发生的所有可审计动用相联系的能力。

5.4.1.2.1.1 可信路径

TCB 应支持自身与诸用户之间的可信通信路径 , 以供 TCB 与用户需要可靠连接 ( 如注册、改变主体安全等级 ) 时使用 , 经由这种可信路径的通信安全由一个用户或 TCB 独占地激活。这种路径逻辑上应与其他路径隔离 , 并与其他路径截然区分开来。

5.4.1.2.2 审计

TCB 应能建立、维持和保护对它所保护的客体访问的审计跟踪 , 防止修改、未授权访问或破坏。审计数据应受 TCB 保护 , 以便对它的读访问被限制在对审计数据已授权的那些用户上。 TCB 应能记录下述类型的事件 : 标识和鉴别机制的使用 ; 把客体引入到一个用户地址空间 ( 如打开文件、启动程序 ); 删除客体 ; 计算机操作员、系统管理员或系统安全员或后两者同时所发生的动作 ; 以及其他有关的安全事件 , TCB 还应能审计人可读标记输出的任何滥用。对每个已记录的事件 , 审计记录应标出 ; 事件发生的日期和时间 ; 用户、事件的类型 ; 事件的成功或失败。对于标识和鉴别事件。请求源 ( 如终端 ID) 应包括在审计记录中。对于把客体引入用户地址空间的事件和客体删除事件 , 审计记录应包括客体名和客体的安全等级。计算机系统管理员应能基于单个用户身份或客体安全级或同时基于两者有选择地审计任一或多个用户的活动。 TCB 应能审计利用隐蔽存储通道的标识事件。 TCB 应包含一种机制 , 它能监控安全可审计事件的发生或累积 , 从而可以指出安全策略迫在眉睫的破坏。当阈值超过时 , 这种机制应能立即通知安全管理员 , 而且当这些有关安全事件的发生或积累再继续下去时 , 则系统应采以最小破坏的操作来终止该事件。

5.4.1.3 保证

5.4.1.3.1 操作保证

5.4.1.3.1.1 系统体系结构

TCB 应维持它自己执行的区域 , 以保护它免受外来干预或篡改 ( 如对它代码或数据结构修改 ) 。 TCB 应在其控制下 , 通过提供不同的地址空间来维护进程隔离。 TCB 内部应由定义恰当的、基本上独立的模块构成。它应有效地使用可获得的硬件 , 把那些严格保护的单元与那些不严格保护的单元分离开来。 TCB 模块应如此设计 , 以便它能执行最小特权原则。硬件中诸如分段的特性 , 应被用来支持逻辑上截然不同的存储器客体 , 这些客体具有分离的属性 ( 如可读、可写 ) 。应完整地定义用户与 TCB 的接口 , 并标识所有 TCB 的单元 ,TCB 的设计和结构应使用一种完整的、原理简单的、具有精确定义语义的保护机制 , 这种机制在实现 TCB 和系统内部结构时将起中心的作用。 TCB 应把分层、抽象和数据隐蔽等方面的有效使用结合起来 , 有效的系统工程应以 TCB 的复杂度极小化为目标 , 而且应排除没有严格保护的 TCB 模块。

5.4.1.3.1.2 系统完整性

应提供硬件特性或软件特性或同时提供两者 , 用于定期地验证 TCB 硬件和固件单元的运行正确性。

5.4.1.3.1.3 隐蔽信道分析

系统开发者都应对隐蔽信道作彻底的搜查 , 并且通过实际测量或通过工程估计确定每个已标识信道的最大带宽 , 见附录 A( 补充件 ) 。应当将形式化方法用于分析。

5.4.1.3.1.4 可信设施管理

TCB 应支持操作员和管理员的职能分隔。应标识在安全管理员任务中所执行的职能 , 只有在计算机系统上发生了与安全管理员任务截然不同的可审计活动后 , 计算机系统管理员才能执行安全管理员职能。在安全管理任务中所能执行的非安全职能应严格限制在那些对有效执行安全任务必不可少的职能。

5.4.1.3.1.5 可信恢复

在计算机系统故障或其它间断后 , 应提供规程或机制或同时提供两者 , 以保证在不危及保护情况下 , 使系统获得恢复。

5.4.1.3.2 生存周期保证

5.4.1.3.2.1 安全测试

应对计算机系统的安全机制进行测试 , 并按系统文档的要求工作。一个充分熟悉 TCB 特定实现的小组应详细分析和测试它的设计文档、源代码和目标代码。它们的目标应是 : 暴露全部设计和实现的缺陷。这些缺陷将允许一个 TCB 外的主体去读 , 更改或删除通常由 TCB 实施强制或自主安全策略时拒绝的数据 , 并且保证没有主体 ( 尚未授权 ) 能使 TCB 进入一种对其它用户启动的通信作出响应的状态。 TCB 应建立相对的抗渗透能力。所有已发现的缺陷应被纠正 , 而且 TCB 应重新测试 , 以验证已排除缺陷 , 并证明没有产生新的缺陷。测试应证明 TCB 的实现与形式化顶层规格说明相一致 , 见附录 C( 补充件 ) 。在测试中 , 没有发现设计缺陷 , 也许发现少量可校正的实现缺陷 , 而应该确信这少量缺陷的存在是合理的。形式化顶层规格说明到源代码的人工的或其他的映射 , 可形成渗透测试的依据。

5.4.1.3.2.2 设计规格说明和验证

应在计算机系统的整个生存周期内维持由 TCB 支撑的安全策略的形式化模型 , 并证明与它的原理是一致的。应维持 TCB 的描述性顶层规格说明 , 以便用异常、出错信息和影响等方面来完整地和准确地描述 TCB 。还应维持 TCB 的形式化顶层规格说明 , 以便用异常、出错信息和影响等方面来准确地描述 TCB 。要是描述性顶层规格说明和形式化顶层规格说明的特性在 TCB 接口上是可见的 , 则它们应包括 TCB 按硬件或固件或硬件和固件实现的那些组成部分。应说明形式化顶层规格说明是 TCB 接口的准确描述。应给出有说服力的证据 , 以表明描述性顶层规格说明与该模型的一致性 , 而且应把形式化和非形式化技术结合起来使用 , 以表明形式化顶层规格说明与该模型的一致性。这种验证证据应与形式化规格说明和已用的验证系统所提供的证据相一致 , 形式化规格说明及验证系统是经国家相应机构在现代技术范围内认可的 , 应执行形式化顶层规格说明到 TCB 源代码的人工的或其他的映射 , 以提供正确实现的证据。

5.4.1.3.2.3 配置管理

在整个生存周期中 , 即在 TCB 设计、开发和维护期间 , 应把配置管理系统放在适当的位置 , 供所有与安全相关的硬件、固件和软件来维护对下列各项改变的控制 : 形式化模型 , 描述性或形式化的顶层规格说明 , 其它设计数据、实现文档、源代码、目标代码的运行版本以及测试夹具和文档等。配置管理系统应保证与当前 TCB 版本相关联的所有文档和代码之间的一致映射。应提供由源代码生成新的 TCB 版本的工具。另外 , 还应在严格的配置控制下 , 获得 TCB 新旧版本比较的工具 , 以便查明实际用作新版本的 TCB 的代码只发生了所需的改动。应把技术上、物理上和过程化的安全措施结合起来 , 用于保护所有用来生成 TCB 的主资料拷贝或所有资料的拷贝免遭非授权修改或破坏。

5.4.1.3.2.4 可信分配

应提供可信的计算机系统控制和分配设备 , 用来维护描述当前 TCB 版本的主数据和适合当前版本的现场的主拷贝代码之间映射的完整性。还应有一些过程 ( 如现场安全验收测试 ) 以保证分配给客户的 TCB 软件 , 固件和硬件的更新完全是由主拷贝限定的。

5.4.1.4 文档

5.4.1.4.1 安全特性的用户指南

用户文档中的摘要 , 章节或手册应描述由 TCB 提供的保护机制 , 有关它们使用的指南以及它们如何相互作用。

5.4.1.4.2 可信设施手册

向计算机系统管理员提供的手册应提出有关功能和特权的警告 , 这种特权在一个安全设施运行时应受到控制。对各类审计事件 , 应给出供检查和维护审计文件以及详细审计记录结构用的规程。手册应描述操作员和管理员有关安全功能和用户安全特性的变化 , 它应提供有

关系统保护特性的一致和有效的用法。如它们怎样互相作用 , 怎样安全地生成一个新的 TCB, 提供设施规程、警告和需要受控的特权 , 以便安全地操作该设施。应标识基准确认机制的 TCB 模块。 TCB 的任何模块修改后 , 应描述由源代码安全生成新 TCB 的过程 , 它应包括保证系统以安全方式启动的过程 , 还应包括那些在系统运行间断后 , 重新开始安全运行的过程。

5.4.1.4.3 测试文档

系统开发者应向评估者提供一个文档 , 该文档描述测试计划 , 怎样测试安全机制的测试过程 , 以及安全机制的功能测试结果。它应包括用来减少隐蔽信道带宽方法的有效性测试结果。

还应给出形式化顶层规格说明与 TCB 源代码之间映射的结果。

5.4.1.4.4 设计文档

设计文档应当具有描述说明制造厂家的保护宗旨以及怎样把这种宗旨转换成 TCB 的解释。也应描述 TCB 模块之间的接口。由 TCB 实施的安全策略模型形式化描述应是可用的 , 且证明它对实施安全策略是足够的。应当标识特定的 TCB 保护机制 , 而且给出一种解释表示它们满足该模型。应当表明描述性顶层规格说明是 TCB 接口的准确描述。文档应描述 TCB 怎样实现基准监控器概念 , 并解释它为什么能防篡改、为什么不能被旁越、以及为什么它能被正确地实现。 TCB 的实现 ( 如硬件、固件和软件方式 ) 应非形式化地表明与形式化顶层规格说明相一致。应使用非形式化技术表明形式化顶层规范说明的要素与 TCB 的单元相一致。文档应描述如何构造 TCB 才便于测试和实施最小特权。该文档还应给出隐蔽信道分析的结果和与限定该信道有关的折衷方案。应当标识要用来利用已知隐蔽存储信道的所有可审计事件。由于已知隐蔽存储信道的使用不是用审计机制可检测的 , 所以应提供已知隐蔽存储信道的带宽 , 见附录 A( 补充件 ) 。应清晰地描述在形式化顶层规格说明中没有涉及而是严格地限于 TCB 内的硬件、固件和软件机制 ( 如映像寄存器 ,I/O 直接存储访问 ) 。

5.4.2 超 A1 级

除了 A1 级所提供的特征和保证之外 , 对系统期望的大部分安全改进要求都已超出了当前技术。下面的讨论旨在指导将来的工作。随着更多更好的分析技术的开发 , 对这些系统的要求将变理更加明确。将来 , 形式验证的使用将被扩展到资源级 , 并且隐蔽定时信道将得到更彻底地解决。在这个等级上 , 设计环境将变得重要 , 而且测试将会借助于形式化顶层规格说明的分析。还将考虑在 TCB 开发中所使用的工具 ( 如编译程序、汇编程序、加载程序 ) 的正确性 , 并且考虑硬件 / 固件的正确功能 , TCB 将在此硬件 / 固件上运行。超 A1 级的要求如下 :

5.4.2.1 系统体系结构

必须给出一种形式化的 ( 或非形式化的 ) 证明 , 以表明在 TCB 中对基准监控器的自身保护和完备性确实已经实现。

5.4.2.2 安全测试

对此虽然已经超出了现代技术 , 然而人们还是期望形式化顶层规格说明或形式化底层规格说明中自动实现某些测试实例的生成。

5.4.2.3 形式化规格说明和验证

必须在可行的场合使用形式化验证方法 , 使对 TCB 的验证向下扩展到源代码级。已经证明对操作系统有关安全部分源代码的形式化验证是一项困难的任务。有两项重要的考虑 : 一是选择一种能完全形式化表达语义的高级语言 ; 二是对于底层规格说明经过一系列的步骤 , 仔细地将抽象的形式化设计映射成可实现的公式形式。经验表明 , 只有当最底层规格说明是密地与实际代码一致时 , 才能成功地实现代码证明。

5.4.2.4 可信设计环境

只有可信赖的人使用可信的设施 , 才能设计 TCB 。

附录 A 隐蔽信道指南 ( 补充件 )

A1 隐蔽信道是这样一种信道 : 一个进程可用违反系统安全策略的方式传输信息。隐蔽信道有两种类型 : 存储信道和定时信道。隐蔽存储信道包含所有允许一个进程直接或间接对一个存储单元写 , 而另一个进程或直接或间接对存储单元读的载体。隐蔽定时信道包括所有允许一个进程通过调整它自已使用的系统资源把信息发给另一进程的载体 , 并按第二个进程所观察到的响应时间变化的方式提供信息。

A2 从安全的观点看 , 低频带隐蔽信道的威胁小于高频带隐蔽信道。但对好多类型的隐蔽信道 , 如果使用把带宽减少到一定等级以下的技术就会降低合法系统用户所能得到的性能。带宽的等级取决于特定的通道机制和系统体系结构。因此 , 需要在系统性能与隐蔽信道带宽之间加以权衡。由于泄露的威胁可能出现在含有秘密或敏感信息的任何多级计算机系统上 , 所以这种系统不应该包含高带宽的隐蔽信道。本指南旨在向系统开发者提供一种设想 , 即隐蔽信道的带宽那么 " 高 " 为好。

A3 隐蔽信道带宽超过每秒 100 比特被认为是 “ 高 ” 的 , 因为许多计算机终端的运行速率都在每秒 100 比特左右。如果信息能以相当于某些计算机常用设备的一般输出速率受到泄露 , 那个计算机系统就不能说是安全的。

A4 在任何多级计算机系统上都有一些比较低带宽的隐蔽信道 , 它们的存在是系统设计固有的。由于减少这种隐蔽信道带宽的成本可能很高 , 所以可以认为最大带宽在每秒 1 比特以下的隐蔽信道在大部分应用环境下是可以接受的。尽管在某些系统上保持可接受的性能使得不可能取消带宽在每秒 1 比特以上的所有隐蔽信道 , 但可以在不影响系统性能的情况下审计它们的使用。这种审计能力向系统管理人员提供了一个检测和纠正重大泄露的方法。因此 , 在有可能的情况下 , TCB 应能对带宽在 10s 内超过 1 比特的隐蔽信道机制的使用进行审计。

附录 B 配置强制访问控制特性指南 ( 补充件 )

B1 强制访问控制的要求包括支持分层密级的未指定数目的能力和支持各个分层等级上非分层等级的未指定数目的能力。为了鼓励设计和开发具有一致性和可移植性的可信计算机系统 , 最好希望这些系统都能支持最少的级别和等别。为此特提供下列建议 :

a. 分层密级的数目大于或等于 16;

b. 非分层等级的数目应大于或等于 64 。

附录 C 安全测试指南 ( 补充件 )

如同在详细要求中一样 , 黑体字用于强调说明该指南与下一个较低等级的不同。

C1 C 等测试

C1.1 人员

安全测试小组至少应由两名具有计算机科学学士学位或同等学历的人员组成。小组成员应能领会系统开发人员准备的计划并提出建议 , 应该熟悉缺陷假设或相当的安全测试方法 , 应该具有汇编语言级程序设计的经验。开始测试前 , 小组成员应该具有待评估系统的功能知识 , 并完成开发人员的评估系统的内部课程。

C1.2 测试

测试小组应独立操纵系统开发人员所使用的测试。小组应独立设计和完成至少 5 个系统特定的测试 , 以绕过系统的安全机制。用于测试的时间为一个月 , 但不要超过三个月。执行系统开发者规定的测试和测试小组所规定的测试所花时间应多于 20 小时。

C2 B 等测试

C2.1 人员

测试小组的组成成员至少应包括两名具有计算机科学学士学位或同等学历的人员和至少一名具有计算机科学硕士学位和同等学历的人员。小组成员应能领会系统开发人员准备的计划并提出建议 , 应该精通缺陷假设或相当的安全测试方法 , 应熟悉 TCB 实施语言 , 并且有汇编语言级程序设计的经验。开始测试前 , 小组成员应了解待评估系统的功能 , 完成系统开发人员的待评估系统的内部课程。至少有一名小组成员在此之前已完成过对另一个系统的安全测试。

C2.2 测试

测试小组应独立操作系统开发人员所用的测试包 , 以测试与安全有关的硬件和软件。小组应独立设计和完成至少 15 个系统专用的测试 , 以绕过系统的安全机制。用于测试的时间至少要 2 个月 , 但不超过 4 个月。每个小组成员执行系统开发人员规定的测试和测试小组规定的测试所花的时间应多于 30 小时。

C3 A 等测试

C3.1 人员

测试小组的组成成员至少应包括一名具有计算机科学学士学位或同等学历的人员和至少两名具有计算机科学硕士学位或同等学历的人员。小组成员应能领会系统开发人员准备的计划并提出建议 , 应该精通缺陷假设或相当的安全测试方法 , 应该熟悉 TCB 实现语言 , 并且有汇编语言级程序设计的经验。开始测试前 , 小组成员应了解待评估系统的功能 , 完成系统开发人员的待评估系统的内部课程。至少有 2 名小组成员在此前已完成过另外一个系统的安全测试。至少有一名小组成员应具有在测试系统进行系统级程序设计的能力 , 并达到能够给系统增加一个设备驱动程序这样的水平。至少有一个成员要相当熟悉系统硬件 , 并达到懂得维护诊断程序和支持硬件文档编制的程度。

C3.2 测试

测试小组应独立操作系统开发人员所用的测试包 , 以测试与安全有关的硬件和软件。小组应独立设计和完成至少 25 个系统专用的测试 , 以绕过系统的安全机制。用于测试的时间至少要 3 个月 , 但不超过 6 个月。每个小组成员为执行系统开发人员规定的测试和测试小组规定的测试所花的时间应多于 50 小时。