TCB receptionists are associated with collections of instances of related device drivers. The receptionist associated with a particular external input device performs authentication appropriate for that device before completing service requests. For example, at user login time the receptionist associated with 3270 terminals (via instances of the R3270 device driver) prompts for the user ID, password, and an optional sensitivity level for that session. The receptionist verifies this information against the Local User Directory (LUD) of current pre-authorized user/level combinations and valid passwords. Additional checking takes place to ensure that the sensitivity level requested is not only valid for that user ID, but is also accessible from the physical device being used. That is, the request must be within the pre-authorized range of valid security levels for that individual device. Password changing facilities are also handled by the receptionist. Extended user authentication processes, such as the addition of biometric or token/hand-held devices, could also be incorporated into the system at this point; none are provided in the native system.
Once a user has successfully passed authentication and is connected to
the specific compartment associated with that [user,label] combination, both the user ID and the sensitivity label are securely
maintained by the system via the compartment and guard facilities, and outside
of any influence by the user's domains. Any request to export or import a named
object, or to perform any accesses or functions identified as requiring
auditing, will cause an appropriate audit record to be produced with the
subject's user ID and sensitivity label inserted into the audit record by
trusted system code. This allows for complete accountability back to the
initiating user, even for functions/processes “spun off” or continued on the
user's behalf when the user is not directly or currently “attached” to the
system.
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.
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.
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.
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).