中华人民共和国国家军用标准军用计算机安全评估准则
GJB2646－96
Militarycomputersecurityevaluationcriteria
（国防科学技术工业委员会1996年6月4日发布1996年12月1日实施）
一范围
1.1主题内容
本标准规定了评估计算机安全的准则，等级划分及每个等级的安全要求。
1.2适用范围
本标准适用于军用计算机安全评估，主要面向操作系统，也适用于其他需要进行安全评估的
计算机。
二引用文件
GJB2255-95军用计算机安全术语
三定义
3.1术语
本章未列入的术语,见GJB2255。
3.1.1自主保护discretionaryprotection
辨识用户身份和他们的需求,限制用户使用信息的访问控制的方法。
3.1.2强制访问控制mandatoryaccesscontrol
根据客体所包含信息的敏感性以及主体访问此类敏感信息的权限,限制主体访问客体的方法。
3.1.3安全等级securitylevel
为表示信息的不同敏感度,按保密程度不同对信息进行层次划分的组合或集合。
3.1.4审计audit
对影响系统安全的各种活动进行记录并为系统安全员提供安全管理依据的程序。
3.1.5隔离isolation
为防止其他用户或程序的非授权访问,把操作系统、用户程序、数据文件加以彼此独立存储
的行为。
3.1.6可信计算基(TCB)trustedcomputingbase
计算机系统内保护装置的总体,包括硬件、固体、软件和负责执行安全策略的组合体。它建
立了一个基本的保护环境并提供一个可信计算系统所要求的附加用户服务。
3.1.7敏感标号sensitivitylabel
表示客体安全级别并描述客体数据敏感性的一组信息,可信计算基中把敏感标号作为强制访
问控制决策的依据。
3.1.8系统完整性systemintegrity
系统不能以非授权手段被破坏或修改的性质。
3.1.9描述性顶层规格说明(DTLS)descriptivetop-levelspecification
用自然语言、形式化程序设计符号,或两者结合写在的一种最高层的设计规格说明书。
3.1.10形式化顶层规格说明(FILS)formaltop-levelspecification
用形式化数学语言写成的一种高层规格说明书。使用这种规格,可以从理论上证明假定的形
式化要求与系统规格的一致性。
3.1.11最小特权原则principleofleastprivilege
为完成特定任务,授予主体所需要的最小访问特权的过程、策略。
3.1.12分层密级hierarchicalclassification
用层次结构的方式将主体和客体分成不同的保密等级。
3.1.13粒度granularity
一次访问操作所涉及到的访问对象的大小。
四一般要求
计算机系统安全将通过使用特定的安全特性控制对信息的访问,只有被授权的人或为人服务
的操作过程可以对信息进行访问。在本准则中提出了以下六条要求。
4.1安全策略
必须有一种由系统实施的、明确的和定义好的安全策略。对于主体和客体,必须有一个由系
统使用的规则集合。利用这个规则合来决定是否允许一个给定的主体对一特定客体访问。对于处理敏感信息的计算机系统必须施加一种强制安全策略来有效地实现访问规则。这些规则要求包括:任何人如果缺少适当的安全许可证都不能获得对敏感信息的访问;同时也要求有自主的安全控制,以保证只有指定的用户或用户组才可以获得对数据的访问。
4.4.2标号
客体应当按敏感程度加以标号,访问控制标号必须与客体联系起来。为了控制对存储在计算机内的信息进行访问,根据强制安全策略规则,每个客体必须有一个标号,这个标号表示客体的敏感级别并记录哪些主体可以对特定的客体进行访问的方式。
4.3标识
每个主体都必须在验明身份(身份标识)后才能对客体进行访问。每次对信息的访问都应标识谁要求访问,他有权访问什么信息？标识和授权信息必须由计算机系统在秘密情况下进行维护并与完成某些与安全有关动作的每个活动元素结合起来。
4.4责任
对审计信息应有选择地保存并妥善加以保护,以便以后对影响安全的动作进行跟踪,查清责
任。一个可信系统应将与安全有关的事件记录在一个审计日志中,为了降低审计费用并提高分析效率,必须具有选择审计事件的能力。审计信息必须很好地保护,以防修改和未经授权的毁坏。
4.5保证
计算机系统应包括能使上述各条要求实现所必须的硬件和软件机制,必须有一批硬件和软件
控制,这些机制可嵌入操作系统内,并用秘密方法执行指定的任务。这些机制应在文件中写
清楚并能独立检验其结果,以便能独立地考评它们是否充分。
4.6连续保护
对实现上述基本要求的可信机制必须能连续地提供保护,以对抗未授权的篡改。如果实现上
述策略的硬件和软件机制本身遭到未授权的修改或破坏,那么这个计算机系统是做不到真正
安全的。连续保护要求与计算机系统的整个生存周期有着直接的关系。
5详细要求
本准则根据上述六条要求,按处理的信息等级和采取的相应措施,将计算机系统的安全分为
四等八级别。D为最低等级,随着等级的提高,系统可信度也随之增加,风险逐渐减少。
注:在本标准中,凡是使用黑体字的部分均表示在较低等级中不包含那些要求,或表示对已
定义要求的变动和增加;凡是不使用黑体字的部分均表示这些要求与较低等级的那些对应要求相同。
5.1D等:最小保护
本等只含一级,它是为那些已作评估,但不能满足较高评估等级要求的系统而准备的。
5.2C等:自主保护
本等分为C1和C1两个级别,它主要提供自主访问控制保护,并具有对主体责任和他们的初始
动作审计的能力。
5.2.1C1级:自主安全保护
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.2C2级:可控制访问保护
这一级实施一种比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应通过提供极好的保护计算机系统各个单个用户的能力来实现其责任。CB还应当提供把这种身份与该单个用户发生的所有可审计动作相联系的能力。
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.3B等:强制保护
本等分为B1,B2和B3三个级别,它主要要求客体必须保留敏感标号,TCB利用它去施加强制访
问控制保护。在本等级中,对于计算机系统中大多数数据结构都必须带有敏感标号;系统开
发者要提供安全策略模型,根据此模型生成TCB。同时系统开发者也要提供TCB的技术规范说明并提供基准监控器概念已被实现的证据。
5.3.1B1级:有标号的安全保护
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.2B2级:结构化保护
在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.3B3级:安全域
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.4A等:验证保护
本等级的特征是使用形式化安全验证方法,以保证系统采用的强制和自主安全控制能有效地保护该系统存储或处理的保密或其它敏感信息。为了证明TCB满足设计、开发和实现各方面的安全要求,需要扩展文件。该等分为A1和超A1两级。
5.4.1A1级:验证设计
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安全测试指南(补充件)
如同在详细要求中一样,黑体字用于强调说明该指南与下一个较低等级的不同。
C1C等测试
C1.1人员
安全测试小组至少应由两名具有计算机科学学士学位或同等学历的人员组成。小组成员应能
领会系统开发人员准备的计划并提出建议,应该熟悉缺陷假设或相当的安全测试方法,应该
具有汇编语言级程序设计的经验。开始测试前,小组成员应该具有待评估系统的功能知识,并完成开发人员的评估系统的内部课程。
C1.2测试
测试小组应独立操纵系统开发人员所使用的测试。小组应独立设计和完成至少5个系统特定的测试,以绕过系统的安全机制。用于测试的时间为一个月,但不要超过三个月。执行系统开发者规定的测试和测试小组所规定的测试所花时间应多于20小时。
C2B等测试
C2.1人员
测试小组的组成成员至少应包括两名具有计算机科学学士学位或同等学历的人员和至少一名具有计算机科学硕士学位和同等学历的人员。小组成员应能领会系统开发人员准备的计划并提出建议,应该精通缺陷假设或相当的安全测试方法,应熟悉TCB实施语言,并且有汇编语言级程序设计的经验。开始测试前,小组成员应了解待评估系统的功能,完成系统开发人员的待评估系统的内部课程。至少有一名小组成员在此之前已完成过对另一个系统的安全测试。
C2.2测试
测试小组应独立操作系统开发人员所用的测试包,以测试与安全有关的硬件和软件。小组应
独立设计和完成至少15个系统专用的测试,以绕过系统的安全机制。用于测试的时间至少要
2个月,但不超过4个月。每个小组成员执行系统开发人员规定的测试和测试小组规定的测试
所花的时间应多于30小时。
C3A等测试
C3.1人员
测试小组的组成成员至少应包括一名具有计算机科学学士学位或同等学历的人员和至少两名具有计算机科学硕士学位或同等学历的人员。小组成员应能领会系统开发人员准备的计划并提出建议,应该精通缺陷假设或相当的安全测试方法,应该熟悉TCB实现语言,并且有汇编语言级程序设计的经验。开始测试前,小组成员应了解待评估系统的功能,完成系统开发人员的待评估系统的内部课程。至少有2名小组成员在此前已完成过另外一个系统的安全测试。至少有一名小组成员应具有在测试系统进行系统级程序设计的能力,并达到能够给系统增加一个设备驱动程序这样的水平。至少有一个成员要相当熟悉系统硬件,并达到懂得维护诊断程序和支持硬件文档编制的程度。
C3.2测试
测试小组应独立操作系统开发人员所用的测试包,以测试与安全有关的硬件和软件。小组应独立设计和完成至少25个系统专用的测试,以绕过系统的安全机制。用于测试的时间至少要3个月,但不超过6个月。每个小组成员为执行系统开发人员规定的测试和测试小组规定的测试所花的时间应多于50小时。
