In this method of transition between policies, when the Security Server loads its initial security database, all of the permissions allowed under all modes of operation are initialized in the Security Server's internal memory. A mechanism internal to the Security Server allows it to change policy without having to read a new security database. Thus policy changes could be triggered by a variety of events. The policy could change based on several events: the time of day, when a process completes a certain task or invokes a certain permission, or when an alarm is set off (e.g., by a possible intrusion event). This method is similar to the mechanism described in Section 5.2; however, because of the ability to change policies based on triggering event it has a number of advantages which are listed below.
This method has the same restrictions that loading a new database has. It is easiest for the Security Server to alternate among policies which are similar. For initial policies based on Type Enforcement or MLS access rules, the new policy must also be based on Type Enforcement or MLS access rules. However, the mechanisms for changing policy definition give this method greater flexibility than the previous method.
For example, for policies which change on a regular periodic basis (recall the banking example in which a more stringent policy is enforced for after-hours operation), a timing mechanism that triggers the change of policy could be added to the Security Server.
Another adaptation mechanism could be triggered by the use of particular permissions. For example, when a particular permission is requested and returned to the requesting process, that permission could be removed from the Security Server's notion of the allowed permissions. This would render the permission as a one-time only permission. For example, in a commercial application a one-time permission to issue payment for a purchase order would prevent double payment.
Similarly, when a particular permission is requested and returned to the requesting process, that permission could be removed from the Security Server's notion of the allowed permissions, and one or more could be added. Such adaptations could be chained together. For example, if the Security Server were applying Type Enforcement, a process operating in one domain might be granted access to a new type and denied access to an old one. Thus a set of operations could be performed by a single process in a secure pipeline. Such secure pipelines are already possible with Type Enforcement, but each operation is performed by a separate process, each running in a unique domain (see [BK85] and [GHS97] for more details). This type of mechanism would also be ideal for enforcing the security policy known as Chinese Wall (see [Pfl97] for a definition).
Since the transition between policies during the loading of new policy is the most atomic, this implementation could be as harsh on running applications as reloading the database. However, the database could be expanded to include several policies so that a policy transition could take place with several intermediate policies during the transition. A phased transition of this sort might allow some tasks to complete processing within fixed time limits.
The security concerns here are the same as in Section 5.2 with the exception that the security database is read once and only once at initialization, and thus the possibility that an untrusted user or process has been able to corrupt it is removed from concern.
With the expanded state of the Security Server, changes of policy may be regulated automatically by the time of day, as in the banking example, or by events, as in the Chinese Wall policy. By moving the authority for changing the policy from subjects to events, the methods by which hostile users could alter the enforced policy change. If a hostile user tampers with the system clock, or forces a triggering event, or counterfeits a triggering event, then he could control changes of policy.
The ability to ``harden'' system defenses automatically in the event of a possible intrusion also seems to be a particular advantage not present in reloading the database.
This method is more reliable than reloading the policy because we are not concerned about the second policy being corrupted after boot-time. However, like the previous method, changes to the policy are limited in their granularity by practical concerns. This method makes the coding of the Security Server more complex, which may cause unforeseen problems; so small policy changes, this method would be superior to specifying and reloading an entirely new database. However, one should not be tempted into making too many changes to the policy using this method because of the potential complexity.
Explicit performance numbers are not available for this method. However, since it avoids the time-consuming step of reading a new database, it is anticipated to be faster than reloading the database, and expected transition times should be less than one second. Thus, it is expected to be the fastest of the four methods under discussion.
The microkernel and other processes can cache permissions to improve performance; so changing policy and flushing the cache frequently could cause a minor performance drag. However, permissions in the database can be flagged as non-cachable. Thus, transient permissions as described above could be flagged in that way so that the microkernel would not have to flush its entire cache as it does for reloading the database. Similarly, permissions in the database can be flagged as those which cannot be flushed. Thus, persistent permissions could be flagged so that the microkernel would not have to flush those permissions from its cache at all, and performance would not be adversely affected by the adaptation of policies.