<< Previous <<         [Session1 Index]            >> Next >>

One interesting security problem is granting an exclusive right to use an object, such that the object granted the right can be sure that no one else has access to the object. The slightly more general case is management of a scarce resource, such as pages of memory, where the number of objects in the pool is fixed or limited (in the simplest exclusive right case, the size of the pool is 1).

In the example we find Object A has the exclusive right to use the Page, and desires to transfer this right to Object B. The Trusted "Title Company" is the object, trusted by both A and B, that manages the exclusivity of the capability on the Page. Lines and objects in black exist at the beginning of the example; lines and objects in green come into existence during the transfer of the authority.

The steps involved are:

  1. A hands a reference to PF1 to B.
  2. B can now simply use  PF1 if B trusts A never to use the PF1 again, but B does not have to trust A: B may ensure exclusivity by requesting a replacement facade from the Title Company, passing B's valid reference to  PF1 as a parameter.
  3. The Title Company determines B has truly sent it PF1, then revokes PF1;
  4. The Title Company creates PF2, thus guaranteeing that no one has a reference to the one and only Page Facade;
  5. The Title Company hands B the reference to PF2.

This example may seem wildly over-complex at first glance. One value to this example comes out when exploring simpler solutions, with fewer objects, that seem alluring at first, but which fail. For example, you might think of making the Page be its own Title Company. But this would require A and B to have direct capabilities on the Page, making the Page Facades exercises in futility. You might consider making the Page Facade act as the Title Company, asking this Facade to hand you a new version of itself and revoking its own reference. But for that to work, B would have to trust the Facade which was handed to it by A, who is not trusted. Squirm as we might, a reliable third party in the shape of the Trusted Title Company is critical to the success of this capability-passing event. You will see objects like this Title Company periodically in the design of truly secure systems.

This example also highlights an important technique for visualizing secure operations. Because security involves changes of state, it is alluring to try to visualize all the possible end states of the system right off the bat. If the problem is complex, avoid this. Instead, establish a single concrete starting situation. Develop an intimate understanding of the starting conditions. Then evolve the pattern through the transition, testing/checking off alternate branches as you go, until you reach the desired final state. If any alternate branches become long and complex and difficult to test, there's a real chance you have a security risk.