PREVIOUS
Trusted Computer Base Components
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.
NEXT