The KeyKOS kernel and a number of unprivileged but trusted KeyKOS and KeySAFE objects make up the software elements of the TCB. The major software components of the TCB are discussed below.
The heart of the KeyKOS operating system is its kernel. The KeyKOS kernel is the only code in an entire KeyKOS system which can execute in the hardware privileged state. The kernel manages all of the physical resources of the system and completely controls CPU allocation, main and secondary (disk) storage, communications between objects, and the use of all privileged instructions. The kernel supports all other programs in non-privileged mode, including all the other components of the TCB. Such programs execute in individual, isolated objects called "domains".
Domains are fundamental objects supported by and understood by the kernel. Domains are "execution objects"; each one can be separately scheduled. Domains have their own address space and obey the instructions of a program in that address space. The program can invoke keys held by the domain. Most of the TCB components described in the following sections are implemented by domains.
Space banks are domains which allocate and reclaim pages and nodes and provide administrative controls for space allocation. Space banks ensure that requestors always receive "clean" (empty) pages and nodes, and that the key provided for the page or node is unique. The space bank will not provide that key to any other requestor and no other valid key to that page or node exists. These safeguards ensure protection against TCSEC "object reuse".
There are many space banks in a typical installation. Space banks may differ from one another in the amount of space that they can allocate, the life span of the space they allocate, the speed of the devices on which the space is stored, the number of copies maintained, and other attributes and limits. Space banks belong to one of two categories: prime and non-prime space banks. Prime space banks hold range keys and non-prime space banks do not. Range keys give prime space banks the authority to allocate and de-allocate real pages on disk.
Space banks are established in hierarchical trees. Each space bank is limited to distributing only those pages and nodes that it controls directly. Those resources are also available to all of the space bank's "parents", allowing for additional administrative controls over the placement and allocation of storage resources. Space bank transformers are TCB domains which can create a new space bank identical in form (or with "sub-set" limits) to an existing space bank. A space bank transformer can also be used to test a key to a space bank to verify or determine certain rights associated with it.
Factories are a Key Logic patented facility and provide the standard mechanism through which new domains are be requested and built. Factories are the source of new KeyKOS objects of known discretion and initial state. A factory is itself a domain. Each factory may produce one and only one new domain per request. However, the newly created domain can itself then call upon other factories, assuming it has been given keys to other factories. In this way a complex object of many KeyKOS objects can be built from a single factory call. Factories can also be used to ascertain whether the discretion of the resulting domain is acceptable to the requestor/user of the domain.
Factories produce and start execution of sealed domains that have algorithms, address segments, and specific keys already installed. The security facility supported for factory-built domains allows communication channels to other objects to be compared against reference sets to ensure that no unacceptable, unknown or hidden communication channels exist . These channels are also called "holes" and are identified as such by the discretion checking mechanism. Factory discretion checking, which is available to importers and users, can also be performed by the reference monitor to ensure that no inappropriate (unsafe or "leaky") factories are exported.
A factory creator is a special domain which can be used to create new, empty factories. The use of a factory creator results in the requestor being provided with a builder's key with which to appropriately tailor the new factory. "Raw materials", in the form of space bank keys, code segments, and keys to other domains or factories can then be provided to the factory via the builder's key. When the new factory is completed (all raw materials have been defined), the builder's key can then be used to request that the factory be "sealed". Once a factory is sealed, a requestor's key is created. This can then be provided to authorized users who wish to make requests of that factory to produce new instances of discrete domains as described in the preceding paragraph. Access to requestor keys is provided to other users via the standard export facilities and reference monitor controls of KeySAFE.
Domain creators are themselves domains which provide the basic utilities for creating other domains. For usability reasons, domain creators also allow certain kinds of rights amplification, but perform no actions which could not be performed by more obscure but less efficient techniques. Domain creator creators are domains which create domain creators. A domain creator creator also provides a facility to verify whether a particular key leads to a domain creator that it built. The system initializes with a single, built-in domain creator creator. Note that users and user processes (TCSEC subjects) will normally use the factory mechanism to request new domains. The factory mechanism then makes use of domain creators as part of its standard process.
The reference monitor mediates all imports to and all exports from any compartment. The reference monitor is where the appropriate "sharing" rules and policies are defined, and thus where the discretionary and mandatory rules (e.g., the ACLs and the Bell and LaPadula policies) are checked and enforced. The reference monitor also ensures that appropriate audit records are generated for all import/export requests. It also updates the global directory that maintains the reference matrix of all currently valid export/import associations. The reference monitor is tightly associated with the compartment guards. It is actually implemented as a common domain which is front-ended by individually "branded" guard portals. Thus, it is always explicitly invoked upon the invocation of any guard key.
The reference monitor is actually a collection of associated domains. This is true of the implementation of many KeyKOS objects. The reference monitor includes domains which are used to initiate or perform further actions which are required to ensure that proper communication channels are established when exports and imports occur. For example, granting an authorized subject access to a previously exported ("named TCSEC") object includes creating a unique intervening KeyKOS object between the TCSEC subject and TCSEC object. These intermediary KeyKOS objects are established to provide for auditing and revocation controls on each subject/object pair.
The receptionist is a domain that is invoked by a particular device driver and provides authentication services for access through that device. In the case of a user logging onto KeyKOS via a terminal (such as a 3270), the receptionist is responsible for querying the user for his user name and password, validating the login via a local user directory (LUD), and invoking whatever key is associated in the LUD with that user name and sensitivity label combination. When authenticated, the user is automatically connected to (and only to) the appropriate, pre-authorized domain in the correct compartment. Basically, the receptionist passes the related device driver key to the designated domain within the identified compartment, establishing a communication channel between the human user and the compartment. The receptionist then removes itself from the communication path. Appropriate auditing, policies, and rules for login security are also implemented by the receptionist.
Device drivers are domains which manage and control access to physical I/O devices. There are different types of device drivers for each different type of physical I/O device, as well as individual instances of each device driver type for each individual physical device. Each device driver holds a device key to the particular physical device which it services. For example, there exists a unique printer driver domain for each individual printer device defined to the system. Printer device drivers are responsible for controlling the printer and properly labeling the printer output. Tape device drivers are responsible for driving tape devices. They interface with tape operator domains, which require the accessors to be responsible for making sure that the tape label is correct before access to the contents of the tape are allowed. Terminal drivers, such as for the 3270 terminal devices, implement a "secure attention" function to provide a trusted path facility.
All device drivers initially obtain their device key via requests to a device allocator (see the next section). Device drivers also help provide for the secure re-establishment of any physical connections after any system outage. In such a case, new device driver instances with new valid device keys are created via the device allocator.
A device allocator is a domain which maintains the device keys associated with the real physical devices and provides those keys to the appropriate individual instances of device drivers built at its request by device driver factories. This provides another level of abstraction between physical resources and users, and also concentrates knowledge of the authorized physical system configuration in one place. Special administrators who are authorized to change the system's physical configuration (such as by defining a new terminal or tape drive) do so via the device allocators. There can be different administrators authorized to define different device types (i.e., who hold keys to different device allocators).
To define any new device to KeyKOS, an administrator must invoke the appropriate device allocator, indicating the assigned minimum and maximum security levels for the new device, and providing keys to a <device driver factory,receptionist> pair which is suitable for the type of device being defined. The device allocator uses the indicated device driver factory to then build an instance of the correct device driver type for that device, simultaneously associating it with the designated receptionist. Any "connection" of any "subject" to the physical device can then only occur through the device driver after successfully passing through the TCB receptionist and its associated authentication process.
The kernel automatically invalidates all device keys when any outage occurs. The device allocators then ensure that there is a device driver instance with a new valid device key for each system- defined device. This is accomplished by requests on the appropriate device driver factory. This process occurs after each IPL, and at any other time when a connection (e.g., bringing a new device on-line) or re-connection (e.g., reestablishing a dropped communication line) is required. The device allocator also ensures the uniqueness of any key provided. Not only is that key "unique", but it is the only one currently existing in any capacity for that device. As prior keys have always first been invalidated by the kernel or the device allocator, there can never be multiple keys valid to any one device at one time.
The audit recorder component of the TCB writes and manages the audit trail of security-relevant records. This domain is invoked by a number of other components (such as the receptionist and the reference monitor) which provide the data to be audited/recorded. The audit recorder is responsible for ensuring that adequate space is available to maintain the information and also utilizes the KeyKOS "journaling facility" to ensure preservation of critical information should an outage occur.
The KeyKOS journaling facility provides for the secure recording of interim logging or audit records from volatile memory to disk. While the standard KeyKOS checkpoint facilities provide for the periodic migration of all data to disk, short periods of "amnesia" could occur for transactions processed during the period between the last system-wide checkpoint and a subsequent system outage, such as a CPU power failure. Therefore, the journaling facility is utilized to ensure that critical audit records produced due to security relevant transactions are immediately written to non-volatile storage. These audit records are automatically incorporated into the standard audit files during the standard checkpoint processes. The interim recording area is then purged and reused during the next checkpoint interval.
One of the security relevant benefits of a capability-based system such as KeyKOS is that each individual "privilege" (authority to invoke any special process or function) can be separately identified and selectively granted to only those individuals with the valid need to have that privilege. Therefore there is no pre-defined set of privileges that is automatically conferred on any user due to any global designation such as a SECURITY or SPECIAL attribute in that user's record. Privileges can thus be combined or segregated with fine granularity in ways that make the most sense for the organizational structure and the security policies of each installation. This also allows for the granting of some privileges on a broad basis to many users where appropriate, while being able to restrict other privileges to very few users. Furthermore, since the granting of a privilege involves giving a user the appropriate capability or key, no user can ever (accidentally or explicitly) create or bestow any privilege to any other user greater than any that the original user already holds.
The joinuser domain provides user administration functions such as allowing authorized system administrators or security officers to define new users to the system or to change an existing user's attributes. Very precise control can be exercised over the authorities and capabilities given to each user. The privileged user invoking joinuser must explicitly designate which capabilities and privileges the new user is to be given. New users can never be given any capabilities or privileges beyond those held by the joinuser invoker. New users are also automatically restricted to operating on the system within individual labeled compartments of predetermined discretion.
The tape operator domains provide common tools and utilities for users authorized to process tapes. This includes interfaces with the tape device drivers and the tape cataloging facilities.
Printer operator domains are used for authorized printer operators to securely communicate with or manage printer devices, such as being able to designate which items are to be printed next.