One possible method for implementing a new security policy is to change the way that the Security Server defines it by creating a second database and re-initializing the Security Server. A method for doing this existed on the DTOS prototype. During the boot process, the microkernel operates on a hard-coded cache of permissions until the Security Server is ready for operation. Once the Security Server has initialized, the microkernel places the command SSI_load_security_policy on the security port of the Security Server. This command causes the Security Server to read the security database to construct a table in its internal memory that maps SSIs and OSIs to permissions. The Security Server then tells the microkernel to flush its cache of permissions, and from that point onward, the policy defined by the Security Server is the policy enforced by the microkernel. The same command can be used to replace one table with another. Once the Security Server has loaded the new policy, it tells the microkernel to flush its cache, and the new policy is enforced by the microkernel.
The command to reload the policy can be encapsulated in a user-invoked program or in some automated process which changes the policy at the triggering of some event. Thus, the policy can be changed at regular intervals using a process like the UNIX utility cron, or by a background process which monitors the system for intrusion events.
This method relies heavily on the tables that can be loaded into the Security Server from the security database. Since the tables are indexed by the SSI and OSI, the management of the system is easiest if the Security Server loads a new policy which is similar to the old one; thus limiting the granularity of the allowable policy changes. A radical change of policy requires that each entity in the system have a security context which can be recognized by the active Security Server both before and after the policy change.
For initial policies based on Type Enforcement
(see [BK85]) or MLS access
rules, it would be difficult to make radical changes in the policy.
Every entity that has a type or domain associated with it must also
have the attributes necessary for enforcing the different policy.
Thus, to change from a Type Enforcement policy to a UNIX-like security
policy, it would be necessary for objects and processes to have
attributes necessary for both security mechanisms. For objects it is
necessary to maintain contexts for the sensitivity level of the object
as well as the users and groups which may have access to the object.
For subjects, it is necessary to maintain the clearance level of the
subject as well as the user of the subject. It is also necessary to
maintain a database listing the group membership.
Since the transition between policies during the loading of a new policy is nearly atomic, this implementation is quite harsh on running applications. Any application which ceases to have permission to perform any task under the new rules is essentially orphaned. This abrupt change of behavior is probably acceptable, and may even be desirable in some contexts (e.g., military emergencies). However, in some contexts this abruptness would cause considerable difficulty. In the banking example presented in Section 1, there may be occasions when a particular user must complete a specific transaction before the end of the day. However, if the policy transition time occurs at 5:00 PM sharp and the user needs an additional fifteen to twenty minutes to complete the task, then the policy may hinder bank employees from completing vital tasks. This would doubtlessly be unacceptable under this scenario.
The immediacy of the transition of this method provides for the greatest security; the users always know exactly which policy is the current policy. As will be shown below, this is not always the case with other methods.
Although the security database is a critical object that should be protected from unauthorized modification, the security database could be changed while the system is in operational mode. Assuming that the system is fielded with adequate physical and procedural security constraints, the security database is more susceptible to replacement or modification during operation than the database (and system) would be to attacks conducted between successive boots of the system. If subverted software could replace the intended database with a different file, the system would enforce the wrong policy.
The issue of who can authorize, authenticate, and execute the policy change is a clear security concern. In the DTOS prototype, authority to reload the security policy is restricted to subjects that have the permission ss_gen_load_policy. Authorization to operate subjects with this permission can be restricted to certain processes, to roles, or to sets of individuals with other security mechanisms.
As for the assurance of such a system, there would be some concerns about the flow of information across transitions. Consider the following example: Suppose that under one policy a subject in domain D_1 has no permission to observe data in objects of type T_1 but does have permission to observe data in objects of type T_2. Furthermore, no domain that may observe objects of type T_1 may write to any object of a type that D_1 may observe (e.g., T_2). Under this policy alone, there is no possible flow of information from type T_1 to domain D_1. Under a second policy, subjects in domain D_2 may observe data in T_1 and write to objects of type T_2, but D_1 is no longer authorized to observe objects of type T_1. Under the second policy, no information may flow from T_1 to D_1. However, after a transition from the second policy to the first, it would be possible for a subject in domain D_2 to pass information from objects of type T_1 to a subject in domain D_2.
Similarly, when dealing with MLS policies and dynamic security lattices, one is necessarily concerned about loss of confidentiality and potential contamination of files during periods of relaxed security. Returning to a more stringent MLS policy or changing a policy using Type Enforcement requires extensive audit to effect such ``roll backs.'' Unfortunately, these concerns exist for all methods.
While there do not appear to be any theoretical frameworks nor any tool support for conducting covert channel analyses (and simialr analyses) for adaptive security policies, some of the formal modeling and proofs might be relatively easier for a policy in which the database is simply reloaded than for more complex policy transitions.
A tangible concern is that if the database file has become corrupted, then the Security Server will not be able to read it. The effect of this is that the Security Server dies, and the system is left without any Security Server at all. Not only would the system not be able to enforce the new, intended policy, but the system would have difficulty running at all. The microkernel and other processes that can cache permissions computed by the Security Server would rely solely on the permissions that had been cached up to the time that the Security Server went down.
Both the security and reliability concerns could be ameliorated by placing a checksum (or a digital signature) over the security database. The Security Server would not read in the new database unless the checksum can be verified.
Of course the discussion in the previous two paragraphs assumes that the specification of the new database is correct. Even if the policy changes are small, an entirely new database must be constructed, and it must be correct to avoid problems (e.g., either a corrupt file or deadlock conditions between the Security Server and microkernel). Since it can be difficult to specify one database correctly, attempting to make more extensive changes reduces the reliability of this method.
This is the second fastest method for changing policies. During performance testing, a typical transition time (median) required 2.985 seconds, and no transition required more than 3.970 seconds. Although this might not be as fast as necessary in a real-time embedded system, this would be more than satisfactory in systems such as the banking application mentioned in the introduction.