This section provides an overview of DTOS, the operating system used to implement the four methods discussed in this paper.
DTOS was designed around a security architecture that separates enforcement from the definition of the policy that is enforced. This architecture allows the system security policy to be changed without altering the enforcement mechanisms. The policy is defined as a function that maps a pair of security contexts to a set of permissions. Each pair of security contexts represents the security context of a subject and the security context of an object that the subject attempts to access. Currently, DTOS implements security contexts consisting of level, domain, user, and group, but the set of attributes that form a security context is configurable. Enforcement consists of determining whether the permissions specified by the policy are adequate for an access being attempted. The generality of the DTOS security architecture has been studied as part of the DTOS program [Sec97]. The conclusion of this study is that a large variety of security policies, useful for both military and commercial systems, can be implemented.
The basic DTOS design consists of a microkernel and a collection of servers. The microkernel implements several primitive object types and provides InterProcess Communication (IPC), while the servers provide various operating system services such as files, authentication, and a user interface [FM93, Min95]. Of particular interest is a Security Server that defines the policy enforced by the microkernel and also possibly by other servers. When a request is made for a service provided by the microkernel, the microkernel sends identifiers for the security contexts of the subject and object to the Security Server. These identifiers are referred to as security identifiers or SID's. A context contains attributes about a subject or object that are necessary for making security decisions. For example, the context may contain the domain of a subject or the type of an object, or the level of a subject or object. The information that makes up the context is dependent on the policy. The actual contexts are local to the Security Server and are not available to the microkernel. The Security Server then computes permissions for the context pair, as defined by the policy that it represents, and replies to the microkernel. The microkernel is ignorant of the context of each entity since it only enforces the permissions that the ß computes on its behalf. Finally, the microkernel determines if the permissions required for the request were present in the reply. Other servers can communicate with the Security Server in a similar fashion.
For example, a Security Server implementing an MLS policy might maintain subject and object contexts consisting of a level. For the microkernel to enforce the simple security and *-property of the Bell and LaPadula model [BL73], the Security Server will grant a write permission only if the level for the object security identifier dominates that of the level for the subject security identifier, and it will grant read permission only if the level for the subject identifier dominates that for the object identifier. Both permissions may be granted if the levels are equal. A file server would check for write permission before allowing a request to alter a file. An alternative Security Server might provide UNIX-like access controls by maintaining a user and a group for each subject context and an owner, group, and access control bits for each object context. This type of Security Server will grant permissions based on the access control bits depending on whether the user in the subject context matches that of the owner and whether the groups match.
A prototype DTOS microkernel and Security Server has been built by Secure Computing. The microkernel is based on Mach, developed at Carnegie Mellon University [Loe93, Ras91]. A version of the Lites UNIX emulator, modified by the government, provides secured UNIX functionality.
The object types implemented by the microkernel include task, thread, and port. Tasks and threads represent the active subjects, or processes, in the system. Each task has a security context that is used for security decisions involving that task. The state of each task includes virtual memory consisting of a set of disjoint memory regions, each of which is backed by a server that is used to swap pages of the region in and out of physical memory. Each task contains a collection of threads, each of which is a sequential execution, that share the task's virtual memory and other resources. A server is implemented as one or more tasks.
The ports are unidirectional communication channels that the tasks use to pass messages. Tasks use capabilities to name ports, and these are kept in an IPC name space on a per task basis. Each capability specifies the right to either receive from or send to a particular port. These capabilities may be transferred to another task by sending a message. For each port there is exactly one receive capability. Therefore, at most one task can receive messages from the port. IPC is asynchronous in that messages are queued in the port and the sending task does not wait until its message has been received. An exception is when the microkernel is the receiving task, in which case the sender waits until the microkernel finishes processing the message.
Sending or receiving a message is a Mach microkernel operation to which DTOS has added security controls that enforce the security policy. Thus, possession of the appropriate capability for a port is necessary but not sufficient in order to send or receive a message from that port. The security contexts of the task and the port must also permit the operation. The policy also constrains what capabilities may be passed in a message sent or received by a task.
The Security Server receives requests from the microkernel through the microkernel security port and from other servers through a general security port. Requests contain four elements:
Not shown in this figure is the fact that the Security Server both defines and enforces a policy for the requests that it receives. It might allow security determination requests from some subjects, but not from others. Similarly, it might allow security determination requests from a particular subject only for certain (SSI,OSI) pairs.
Security enforcement as described above would be very expensive due to the large number of messages that must be exchanged between the microkernel and the Security Server. The solution in DTOS is to cache (SSI,OSI) pairs with their permissions in the microkernel [Min95]. When the microkernel receives a request, it first looks in the cache for the appropriate (SSI,OSI) pair. If that pair is in the cache, the microkernel uses the cached entries. Otherwise, it sends the pair to the Security Server to determine the permissions, usually also caching the reply. (Part of the permission set returned is permission to cache the reply -- caching would not be permitted for permissions granted for a single operation by a dynamic policy.) Since sending to and receiving from a port are microkernel operations controlled by the policy, the cache must be preloaded with permission for the Security Server to send and receive from the designated ports.
In order to implement a different policy (either by changing the current ß or by referring to a new ß) there must be a mechanism for flushing permissions from the microkernel's cache. Otherwise, if the new policy removes permissions from the system for a specific (SSI, OSI) pair, and the microkernel has already cached the permissions for that pair, then the microkernel would continue to enforce the old policy rather than consult the ß defining the new policy. Therefore, the ß must issue a command to the microkernel, and any other servers registered as caching permissions determined by the ß, telling it to flush its cache. However, it would be impractical for the microkernel to flush every permission in its cache; if it did, then the entire system would come to a halt. Therefore, some permissions are hard coded. These include some of the basic permission required for IPC between the subjects comprising the operating system itself.
The separation between policy and enforcement in the DTOS prototype make it attractive for studying adaptive security. The work described in this report discusses refinements to the design that are important for these policies.