PREVIOUS

KeyKOS/KeySAFE and TCSEC B-level Requirements

Security Policy

Discretionary Access Control

The KeyKOS architecture ensures excellent isolation and default protection by implementing the Principle of Least Privilege for access to any data, devices, processes, or other "named" objects. The TCB Reference Monitor component provides for the implementation of controlled sharing rules appropriate to the installation. At the time a named object is first defined to the system (i.e., originally named or exported on that system), the subject identifying that object can also specify an access control list (ACL) to be associated with the object. "Negative" ACL information and "null" access specifications can also be indicated within ACLs. To assist users, existing ACLs can be used as models or exact duplicates, where appropriate, to create ACLs for new objects. Entries in ACLs consist of the user IDs or user groups affected and optionally, where appropriate, the type of access allowed or disallowed. For instance, some users may be granted read/write access to a storage segment to which other users on the list are only granted read-only access. The handling of ACLs, their storage, and reference is performed by the Reference Monitor.

Some other systems require "program pathing"-type controls to explicitly define limitations on the conditions under which access will be allowed. For instance, they may designate which program must be executing at "file open" time. This is not required in KeyKOS due to the inherent "path controls" of an object oriented, capability based system.

Object Reuse

No new or additional storage objects can be obtained by any user without requesting them from user-associated "space banks". Space banks are part of the TCB. They ensure that all provided pages and nodes are "clean" when delivered to any requestor, and that the requestor is given the single existing valid key to that page or node. No direct access to memory or secondary storage is possible except through the kernel and keys, so that no "indirect" or other access to any information (residual or otherwise) is possible. For tape media, the (TCB) Tape Operator facility is the only process holding capabilities to actual tape device drivers and is therefore the only mechanism providing access to any data stored on tape.

Labels

The general system design for the support of multilevel security labels, with hierarchical classifications and non-hierarchical categories, is discussed in the "Multilevel Security Implementation Overview" section, earlier in this document. Support for this implementation is provided through a number of KeyKOS/KeySAFE facilities, including: compartment creators, factories, guards, the reference monitor, receptionists, and the audit recorder. These facilities are components of the TCB and are described individually in more detail elsewhere in this document.

Label Integrity
Each subject (a KeyKOS compartment) and each named object have a complete sensitivity label associated with them. The label itself is never "stored" with the object. The "tagged data" approach is not employed, either in memory or on external storage media. Nor is the sensitivity label stored within any subject's address space. For objects, the label itself is stored only in the TCB global directory and is accessible only via the reference monitor. For subjects, the label is stored within the guard associated with (but outside of) each compartment, and within the local user directory (LUD) where that pair is defined to the system as valid. The data within a guard can be seen only via the reference monitor, and cannot be examined or changed through any other facility. Similarly, the LUD is only accessible via its associated receptionist or via the joinuser facility. All these facilities (reference monitor, receptionist, joinuser) are components of the TCB. No access to any data stored in the guards, LUD, global directory, or related repository of security control data is possible via any code outside of TCB code.

Exportation of Labeled Information
KeySAFE supports the implementation of single-level and multilevel I/O devices. Any export of an object from a subject's compartment automatically results in the compartment's specific (accurate and unambiguous) sensitivity label being "associated with" the object/information. The label is recorded in the global directory by the reference monitor at export time, and recorded in the audit trail record for the export event.

Requests to export information which make the information visible external to the computer system (to a tape or printer, for example) are a special subset of exports. They are also referred to in some cases as output, to help differentiate from all other exports. In these cases, the subject initiating the output request must designate a device type attribute as part of the export process. This means it must cite an additional attribute when invoking the compartment's guard key with an export request/order code. The TCB reference monitor is explicitly invoked on behalf of the guard and checks the validity of the export request. If valid, it will recognize the output designation and invoke the TCB output process which is appropriate for the designated device. In this process it will ensure that the correct sensitivity label is obtained from the guard and specified to the output process, and ensure that appropriate audit trail records are created. Each trusted output process is maintained in its separate compartment, associated with different output attributes, and is known only to the reference monitor. The compartment for the trusted output process contains the device driver, spooling facility, human operator interface, and other objects necessary to effectively and securely manage the associated output device type.

Exportation to Multilevel Devices
The reference monitor guards, export controls, and the individual trusted output processes ensure that information cannot be exported to any physical output device whose security level or range of minimum to maximum security levels is not valid for the specific sensitivity label of the information. For output of information to a multilevel I/O device, the trusted output process and trusted device driver instance associated with that physical device ensure that the appropriate specific machine-readable or human-readable label is also designated with the output.

.

Exportation to Single-Level Devices
As noted above for multilevel devices, the enforcement mechanisms associated with the export process and the output process ensures that information can only be exported/output to an I/O device which has been defined to the system with the appropriate security level. Facilities are provided whereby the user can inquire as to the security level of the current session.

Labeling Human-Readable Output
For the exportation of information to any I/O device producing human-readable output (e.g., printers), the output process and device driver instance for that device ensure that the appropriate specific human-readable label is designated with the output (e.g., printed on the beginning and ending banner pages of listings produced on high speed printer devices).

Subject Sensitivity Labels
Terminal users can only change the sensitivity level of a session via the explicit action of invoking the trusted path, reentering their user ID and password, designating the sensitivity level they desire for the subsequent communications, and being re-authenticated. The SYS REQ key on a 3270 terminal invokes the trusted path and re- connects the terminal to the receptionist, which then informs user authentication and connects the user to the appropriately labeled compartment for the designated sensitivity level. All actions taken while connected to the system (exports, imports, etc.) are done under the identity and sensitivity label of the subject's current compartment (i.e., the compartment is the subject). The terminal user can also query the system for an indication (display) of the current session sensitivity level.

Device Labels
The definition or introduction of each new physical device to the KeyKOS/KeySAFE system involves the identification of the specific device type and the designation of the minimum and maximum security levels authorized for that individual device. Any subsequent changes to the physical configuration of the system requires similar specifications by the systems administrator or operations personnel who are authorized to define devices of that type. Different administrators can be authorized to define different types of devices. These controls are related to the relationships described earlier in the "TCB Components" sections on Device Drivers and Device Allocators. All device definition actions are auditable.

Mandatory Access Control

The KeySAFE reference monitor submitted to the NCSC for evaluation implements the Bell and LaPadula model for mandatory access control policy (i.e., simple security and *-properties) as well as discretionary ACLs. The underlying isolation and Principle of Least Privilege policies are extended to provide controlled sharing between objects as long as all relevant discretionary and mandatory access control policies are satisfied. No mandatory access control policies can be overridden at access request time by any user. However, designated special users (e.g., selected security officers) can be granted the specific capability to change sensitivity labels on existing named objects, and thereby providing different accessibility. These actions are, of course, audited.

NEXT