CAPABILITY SECURITY Operating Systerm Security

10.3. CHALLENGES IN SECURE CAPABILITY SYSTEMS 145

Figure 10.1: A problem with the enforcing the ⋆-property in capability systems clearance as the victim. Clearly, the attacker should not have access to this capability, but how does the kernel know that a capability stored by a program cannot be used in another context? Confinement is not achieved in the example above because the program P has the discretion to give the capability to the attacker. Like other mandatory access control systems, we want to define a mandatory policy that ensures that the program P cannot give the victim’s rights away.

10.3.3 CAPABILITIES AND POLICY CHANGES

The third problem is the revocation problem; capabilities are difficult to revoke. Recall Levy’s safe- deposit box example. When keys are distributed among the authorized people, the owner of the safe-deposit and the bank lose the ability to restrict who has access. Should the owner or bank try to change who can access the safe-deposit box after the keys have been distributed they have a couple of challenges in enforcing this change. First, they have to locate all of the keys that were given out. While they may know how many keys were created and to whom they were initially distributed, the keys may not longer be in the possession of those people and they may not remember what they did with them. Second, keys may have been copied, such that it may not be possible to determine 146 CHAPTER 10. SECURE CAPABILITY SYSTEMS whether all the keys have been revoked. In general, it may be easier to change the lock and start again. This analogy means that should we decide to change the security goals that we want to enforce in a capability system, we may not be able to determine whether we have accounted for all the capabilities necessary to prove that the new goal can be achieved. We not be able to find all of the capabilities to all objects or some unknown copies may have been made. Mechanisms to bring the set of capabilities back into some approved state may be expensive search all memory or disruptive delete all capabilities and start again.

10.4 BUILDING SECURE CAPABILITY SYSTEMS

Work in secure capability systems aims to address these problems to enable effective verification that the system enforces a well-defined set of security goals. While a variety of capability system designs have been modified to solve these problems, we focus on two capability systems: SCAP [ 157 ] and EROS [ 286 ]. Both SCAP and EROS are capability system designs based on existing designs, CAP [ 135 , 223 ] and KeyKOS [ 128 ], respectively, but extended to solve these fundamental problems. Table 10.1 shows a summary of how EROS and SCAP address the three problems in capability systems. We develop and compare these solutions below. Table 10.1: Summary of SCAP and EROS solutions to the major security issues in capability systems. Security Issue SCAP Solution EROS Solution ⋆ -Property Convert to read-only Define weak capabilities capabilities by MLS policy that transitively fetch only read-only capabilities Confinement Use Access Control List to Define safe environments for define confinement confined processes or test via authorize capabilities Revocation Revocation by eventcounts Indirect capabilities that single page entry or permit later revocation revocation by chaining of all descendants multiple page entries similar to Redell [ 252 ]

10.4.1 ENFORCING THE ⋆-PROPERTY

The SCAP design to ensure that the ⋆-property is not violated in capability systems leverages two key insights [ 157 ]: 1 capabilities must be loaded into a capability cache prior to use and 2 we simply need to remove unauthorized access from any capability loaded into the cache to prevent leakage. SCAP requires that a process must load a capability into its capability cache i.e., its capability list or C-list prior to using it. This load operation provides the operating system with a point of complete