In the Security Server hand-off, the current Security Server passes the receive capability for its security port to another Security Server that implements a new policy. In order to accomplish this, the new Security Server is initialized while the current Security Server is still in control of the policy decisions. The new Security Server uses the command get_special_port to obtain the send right to client port of the current Security Server and then issues the transfer_security_ports to the current server. The current Security Server packages the receive rights for its security port along with two other tables of information. One table contains the mapping between security contexts and SIDs that it uses to interpret incoming requests, and the other table lists the ports of processes that may be caching security permissions. The new Security Server needs the former to interpret requests that it receives regarding any processes or objects that exist prior to the hand-off. It needs the latter because it may eventually need to tell these other processes to flush their cached permissions. The last action of the current Security Server is to tell all processes with cached permissions to flush their caches. At this point the new Security Server can compute access permissions, and the microkernel and any other processes that enforce these permissions can enforce the new security policy.
In order to be able to process new requests for permission computations, the new Security Server must be able to interpret the requests. As mentioned above, the old Security Server sends the appropriate information for the new Security Server to match contexts to SIDs. However, the new Security Server has some knowledge of security contexts prior to receiving this information from the old Security Server; so it must reconcile its understanding of contexts with the mapping information received from the old Security Server. It also must create new SIDs for any new contexts which were not recognized by the old Security Server. For example, if the both the new Security Server and old Security Server are implementing Type Enforcement and there are new domains as part of the new policy, the new domain must receive a SID. Similarly, if the hand-off occurs in order to implement dynamic lattices as part of an adaptive MLS policy, any new levels must receive SIDs. Once the new Security Server has completed this reconciliation, the old Security Server can shut down.
The greatest strength of the hand-off method is that one can enforce a global, radical change of policy. The new Security Server can implement a very different policy from the one that is enforced before the hand-off. Not only can the new Security Server initialize from a new security database, it can implement an entirely different set of algorithms for making its security computations. This may be especially important for implementing dynamic lattices as part of an adaptive MLS policy.
As discussed in Section 5.2, the only impediment to changing the policy in a radical way is the labeling of objects and processes with the appropriate set of attributes which can be interpreted by both the new and old Security Servers. In other words, radically different policies may require essentially disjoint sets of attributes which the system designers glue together for the context of any single entity.
In essence this method is not different from reloading the database. Changes to the security policy are global and atomic. The same problems exist in this method as for reloading the databse for situations where a harsh change of policy is undesirable, as in the banking example.
Some of the same security advantages and concerns exist here as for the Reload Policy method. As with the Reload Policy method, the users always know exactly which policy is the current policy. However, if the new Security Server has to initialize from some static file or security database, there is always the risk that it could be subverted. Another possibility is that the code for a new Security Server could be subverted as well and that a malicious Security Server could end up in control of the permission decisions.
There remains the issue of who can authorize, authenticate, and execute the policy change. The Security Server will hand off the security port to the new server when it receives the command SSI_transfer_security_ports on its security port. Just as in the case of the authority to reload the policy, the permission to issue this command is restricted to subjects that have the permission ss_gen_load_policy. Authorization to operate subjects with this permission can be restricted to certain roles or to sets of individuals with other security mechanisms. The additional concern here is that the security port is transferred to the correct subject, the new Security Server.
The hand-off is a more complicated procedure than the preceding two methods from two points of view: of the operation itself and of the development of the system.
From the latter point of view, the handoff requires that a second, fully functioning Security Server be implemented, as well as a second security database. This solution should not be used for trivial changes to the policy.
Unfortunately, from the former point of view, the hand-off procedure on the DTOS prototype is relatively delicate, and this is its greatest weakness. While these type of problems are inherent in all four methods, they are more likely in this implementation. The unreliability is an artifact of the Lites server which provides the microkernel with services that allow one to use UNIX applications on DTOS. The combination of the microkernel, Lites server, and the Security Server is prone to paging errors and deadlocks. To avoid these errors, the microkernel must have a sufficient set of permissions hard-coded into its cache (these permissions are not flushed from the microkernel). Some of the permissions required by the new Security Server to complete the hand-off must be in the hard-coded cache before the transition is initiated.
For example, the Security Server has page-able memory. During the hand-off, the Security Server may start using new areas of memory while processing a security request from the microkernel. If a page fault occurs, then the Security Server itself will request service from the microkernel. If the microkernel has not cached the permission required by the Security Server, it must in turn request a security computation from the Security Server. However, the Security Server is blocked on the request to the microkernel for service, and the microkernel cannot complete its request without the security computation from the Security Server. What makes these types of events unpredictable is the existence of other processes on the system that may request services from the Lites server while the security port rights are in transit. The new Security Server depends on the Lites server for services, but a thread of execution in the Lites server can be waiting for a security computation creating the deadlock.
This is the slowest of the methods tested. During performance testing, a typical transition time (median) required 4.900 seconds, and all transitions fell with the range of 4.820 to 5.010 seconds. This might not be as fast as the Reload Policy method, but once again this would be more than satisfactory in systems such as the banking application mentioned in the introduction.