1 / 15

Capability Myths in Computer and Network Security

This lecture explores common misconceptions about capabilities in computer and network security, such as equivalence, confinement, and irrevocability myths. It also discusses the advantages of capabilities in enforcing the principle of least privilege and avoiding the confused deputy problem. Additionally, the lecture touches on trusted operating systems and security policies/models.

rpoole
Download Presentation

Capability Myths in Computer and Network Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related