KeyKOS Compartments
A KeyKOS compartment is a collection of KeyKOS objects (domains, nodes, segments) which is associated with an individual user ID and a sensitivity label. Compartments are the TCSEC subjects in a KeySAFE system. When a user logs in and specifies an authorized sensitivity label (either explicitly or implicitly), the user is connected to the appropriate compartment. Usually a compartment will contain tools such as command interpreters, editors, and other facilities which make the computer useful to the user, as appropriate for the user's job function. To the user, the compartment will appear much like a virtual machine.When a compartment is created, there is typically only a single key leading into the compartment and a single key leading out of the compartment. The key leading into the compartment is normally accessible only by the TCB receptionist facility. After authenticating the user at the terminal and determining that the user is authorized to have access to a particular compartment, then the receptionist connects the terminal to an appropriate KeyKOS object within the compartment. Usually, the key leading into the compartment will lead to a command interpreter (or a simple application specific menu appropriate for that user, classification, and job function) which will allow the user to make use of the other facilities available in the compartment. In some circumstances, such as when a user's access to a compartment is rescinded, the key leading into the compartment may be made available to a designated security administrator.
When a compartment is initially created, the single key leading out of the compartment leads to a guard. Each compartment has its own unique guard, which enables the user to export labelled objects from the compartment and to import labelled objects. Figure 1.1
Figure 1.1
shows a compartment. The "fence" around a compartment does not correspond to a physical boundary. Rather, the isolation of a compartment exists due to the fundamental KeyKOS principle that authority to perform any function must be explicitly granted. Thus, without the key into the compartment (which can be obtained only via the TCB receptionist) no one can access the compartment or anything in it. Without the guard key, no object outside of the compartment can be accessed, and no objects can be exported (exchanged or shared) with any other user or compartment.
When any KeyKOS object is exported from a compartment, it automatically becomes a named, labelled TCSEC object with the same sensitivity label as the compartment from which it is exported. Exportation requires explicit action on behalf of the user associated with the compartment from which the object is exported. The user designates the "name" for the new TCSEC object and any appropriate discretionary access control information, such as an access control list. Alternatively, the Reference Monitor could assign the name to the object. KeySAFE ensures the identity of the subject and the sensitivity label of the object are securely determined and recorded.
Access to a labelled object is also controlled by the reference monitor, which implements both the mandatory access control policy of the Bell and LaPadula model, as well as any specified discretionary access control. The KeySAFE architecture makes it easy to implement any other security policy. Thus, an implementation of KeySAFE for commercial applications might incorporate a different security policy.
To import the key to a labelled object into a compartment, the requesting user invokes the guard key for the compartment. This actually invokes the reference monitor on behalf of that particular compartment and guard combination (i.e., for that user id and sensitivity level). The reference monitor denies access to a labelled object unless the access is consistent with both the mandatory and discretionary access controls established by the security policy. The importation process supported by KeySAFE also ensures that any access to a labelled object is individually auditable and/or may be immediately rescinded at any future time.
Once the key to a KeyKOS object is exported from a compartment and becomes a named, TCSEC object, its original key and all copies are invalidated. Future access to the object by the originating compartment must also occur through an auditable, rescindable path which must be established for that compartment in the same manner as any other "importing" compartment. This is generally transparent in most cases, such as for factory requestor keys and read-only segments. It becomes significant for cases involving read/write segments where "write" rights are to be granted, either to another user or just retained by the originator. Special procedures must be explicitly utilized in such instances. These issues and all related procedures and tools are described more fully in the KeySAFE Security Features Users' Guide (SEC010).
Subjects and Objects
Subjects in the TCSEC sense are the individual compartments described above. Each compartment represents a uniqueObjects in the TCSEC sense are those KeyKOS objects which meet the requirements for sharing between compartments. TCSEC objects belong to a subset of all KeyKOS objects. They must be named (have an identifier, assigned at export time, which may be referenced externally) and must be of one of a specific class of KeyKOS object types. Types permissible for sharing (i.e., for exporting) include: pure storage objects, such as KeyKOS segments, and stateless providers of some service, such as KeyKOS factories.
Other types of KeyKOS objects (e.g., node keys, or start keys for arbitrary domains) are not valid for exporting from one compartment to another. These restrictions ensure that there can be no propagation of keys without the desired auditable, rescindable assurance facilities in place, and that no implicit accesses are granted, either intentionally or accidentally. Processes and data created by a user, used totally within a single compartment, and never shared or exported to other users, never become "named" or TCSEC objects.