PREVIOUS
Assurance
Operational Assurance
A tremendous amount of structure, layering, and isolation is
provided in KeyKOS via its architecture, particularly in the areas of
object-orientation, the use of capabilities, and in its small software
kernel. Refer to the "Fundamental Architectural Design
Concepts" discussions in the first section of this document.
Most traditional operating system functions have been isolated into
individual (non-privileged code) domains outside of the KeyKOS
kernel, providing a very robust system structure yet allowing the
KeyKOS kernel to be extremely compact. Within the kernel itself
individual routines are grouped into modules of related function,
which are then logically structured into major functional components,
such as device independent I/O, device dependent I/O, and memory
management. Abstract data types, type managers, and storage
protection keys are also employed within the kernel.
Software testing of the kernel and other TCB software components is
included in the system test suites, which cover functional testing and
integrity testing. Hardware integrity tests must be obtained through
cooperation with a System/370 hardware vendor.
The object-orientation and capability-based design, along with the
absence of default sharing of such things as directories and program
libraries eliminate many of the covert channel problems common in
traditional systems. The only global files or directories are those
created for and only accessible by TCB facilities. These include: the
global directory used by the reference monitor, the local user
directory used by the receptionist, and the device configuration
directory used by the device allocator. The complete system covert
channel analysis for KeyKOS/KeySAFE, for both storage and timing
channels, and the results of the analysis and any actions required or
taken, are being documented in a separate KeySAFE Covert
Channel Analysis Report (SEC015).
Detailed information on the proper installation, maintenance, and
operation of a KeyKOS system is documented primarily in the
KeyKOS System Administrator's Reference Manual
(KL085). Additional information to utilize the KeySAFE
security and audit features are being documented in the
KeySAFE Trusted Facility Manual (SEC011), and the
KeySAFE Security Features User's Guide (SEC010).
KeyKOS provides an efficient, complete, and trusted recovery
mechanism via its system-wide checkpoint/restart facilities. Due
also to the single-level store implementation, backup, recovery, and
restart are all much simpler on KeyKOS than on conventional
systems. There is no state information required by KeyKOS/KeySAFE
that is not maintained in or which cannot be directly derived from
the system set of pages and nodes. This includes all system and user
process state and control information such as might be found in
traditional system control blocks and system tables. Therefore, the
entire state of the system, captured and written to non-volatile
storage via the checkpoint process, is recovered intact from the
checkpoint image. This automatic process also ensures that any
necessary tables or queues utilized for performance or other
purposes are rebuilt as required.
This entire recovery/restart process occurs automatically from the
latest checkpoint after a CPU power failure with no human
intervention or related security or integrity exposures. Checkpoints
and restarts can also be manually initiated by system administrator
or operations personnel with the appropriate authority. The
capability to manually initiate one of these activities still does not
grant that user the capability to intervene in the process, to change
system configurations, or to invoke any other special privileges
unless that user also specifically holds the appropriate keys for these
functions. Thus, the checkpoint process ensures a complete picture
of an internally consistent (secure) system state and the
recovery/restart process ensures the return to the exact same secure
state.
The restart process also automatically replays the
"journal" which has been maintained by the TCB
journaling facility to ensure no loss of important security-relevant
events occurs between checkpoints. Thus user password changes,
audit records identifying invalid logon requests, etc. can also be fully
recovered and accounted for even if they occurred between a
checkpoint and a subsequent system outage.
As part of the overall system evaluation process, Key Logic is
implementing new configuration management and testing
documentation and procedures. Details will be documented in the
KeySAFE Configuration Management Plan (SEC014), the
KeySAFE Test Plan (SEC016), and the various related test suites and
results.
The formal model for the KeyKOS/KeySAFE system will be
documented in the KeySAFE Security Model (SEC013).
The Introduction to KeySAFE (SEC009) and additional
design documentation, such as the KeySAFE System Design
Specifications (SEC012), provide the relevant design
specifications supporting the security model and the TCSEC
requirements.
Configuration management issues for KeyKOS and KeySAFE will be
covered in the KeySAFE Configuration Management Plan
(SEC014).
NEXT