Capability Myths in Computer and Network Security

1. CMSC 414Computer and Network SecurityLecture 12 Jonathan Katz

2. “Capability myths…” • Equivalence myth: ACLs and capabilities are “just” two views of the AC matrix • Confinement myth: Capability systems cannot enforce confinement • Irrevocability myth: Capabilities cannot be revoked

3. Equivalence myth • Capabilities allow for finer-grained listing of subjects • Processes rather than user accounts • Capabilities allow greater flexibility to edit permissions • In ACLs, usually all-or-nothing • In capability-based systems, can delegate exactly those rights you have

4. Confinement myth • Myth: Capabilities can be delegated “at will” and therefore cannot be confined • But…can be set up so that A can delegate a capability to B only if A is authorized to pass capabilities to B • If B is untrusted, then the latter capability will not exist

5. Origin of confinement myth • Mistaken assumption that the ability to write/read files translates into the ability to read/write capabilities • E.g., “read-down/write-up” example which allows transfer of “write-low” capability • Capabilities should not be viewed as “just” bitstrings; they are typed by the OS

6. Revocation of capabilities? • Capabilities may expire with time…or can remove all access by changing random number associated with file • Does not allow fine-grained revocation by subject • If OS stores capabilities, can simply delete the capability • Could move capability to new location and reveal the location only to subjects which still have access rights • Requires OS to keep track of which capabilities have been issued to whom

7. More generally • Use forwarding to revoke access…

8. Advantages of capabilities • Better at enforcing “principle of least privilege” • Provide access to minimal resources, to the minimal set of subjects • We have seen already that capabilities allow much finer-grained control over subjects (process-level instead of user-level)

9. Advantages… • Avoiding “confused deputy” problem • “Deputy” = program managing authorities from multiple sources • In the example we have seen, the problem was not the compiler having the wrong authority, but of exercising its authority for the wrong purpose

10. Confused deputy… • Capabilities give the ability to identify the authority a subject is using • Can then designate use of the authority for a specific purpose • Capabilities also tie together designation and authority • Don’t “know” about a resource if you don’t have the capability to access it! • Any request to access a resource must include the necessary authority to do so --- “deputy” can now examine the context of the request

11. “Trusted” Operating Systems (Chapter 5)

12. Overview • A trusted OS must provide (minimally) memory protection, file protection, access control, and user authentication • Authentication deferred to later… • Policies/models, design, assurance

13. “Trust” vs. “Security” • A “trusted” system meets the stated or expected security requirements • May or may not be “secure”… • May be degrees of trust…

14. Security policies/models • What model to use? • “Military security policy” • Primarily concerned with secrecy • Information ranked at sensitivity level within a hierarchy (e.g.: unclassified, secret, top secret), and also placed within (one or multiple) “compartments” • “Classification” of data = (rank; compartments) • Compartments no longer hierarchical…

15. Military policy • Subjects given “clearance” • Expressed as (rank; compartments) • “Need to know” basis • Subject with clearance (r, C) can access object with classification (r’, C’) only if r  r’ and C’  C • Assumes a central “security officer” controlling designations