Once a user has successfully passed authentication and is connected
to the specific compartment associated with that
A user ID on a KeyKOS/KeySAFE system can be up to 16 characters in
length. A password can also be up to 16 characters, and can include
embedded blanks.
The actual writing of KeySAFE audit records is performed by the
Audit Recorder component of the TCB. It is responsible for ensuring
that requested records are written to the audit file and that
sufficient space remains (or it obtaining more space) to record
records so that none are lost. The audit recorder also makes use of
the Journaling facility to ensure that no particularly significant
records are lost due to any system outages between KeyKOS
automatic system-wide checkpoints (e.g., a CPU power failure) by
migrating those records directly to non-volatile disk storage.
Valid users can review audit trail records in two ways: the on-line
review of recent activities and the "batch" generation of
audit trail reports. TCB code is used exclusively to "re-set" the audit file by deleting any "active" data as
appropriate when records are "archived" to backup disk
or tape files. The capability to read any of the original or backup
audit trail files should be granted to appropriate users with the need
to know. Standard report generation tools (non-TCB code) can be
used by the users authorized to view the audit data to then select,
sort, and/or prepare the records for display or reports (but never to
re-set or to update the audit files themselves).Trusted Path
Device drivers include trusted path support appropriate for the type
of input device to which they are related. For example, support is
incorporated within the R3270 device driver domains (for 3270
terminals) for the secure attention key. This is also
referred to as the SYS REQ (system request) key.
"Hitting" this key always returns the user to the standard
system entry screen (i.e., initial logon/logo screen), which is
displayed by the TCB receptionist. The user must be re-
authenticated in order to (re-)establish communication with the
system. This same process is necessary to switch compartments and
sensitivity levels.Audit
Each audit record contains the subject's user ID and current
sensitivity label for the session at the time of the request. Also
included are an indication as to what type of event is being recorded,
a CPU identifier indicating on which system it occurred, and a system
date/time stamp. Additional information is included which depends
on the type of event being audited. For system login attempts, the
input device name would be included. For exports, imports, and
audited accesses to named objects, the global directory name of the
named object and its sensitivity label will be included, as well as the
related access rights and/or access request (e.g, read-only) involved.
In all cases, the reason for the generation of the audit record (the
type of event and its outcome, success or failure) will also be
indicated within the record. The reason code information in the
audit record for denied or failed accesses will typically be at a level
of detail greater than that provided in any associated messages that
might have been generated to the user during the attempt. The user
may receive only a simple "access denied" message while
the audit record would indicate the specific reason for the system
denying the request.