cmsc 414 computer and network security lecture 12
Skip this Video
Download Presentation
CMSC 414 Computer and Network Security Lecture 12

Loading in 2 Seconds...

play fullscreen
1 / 15

CMSC 414 Computer and Network Security Lecture 12 - PowerPoint PPT Presentation

  • Uploaded on

CMSC 414 Computer and Network Security Lecture 12. Jonathan Katz. “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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' CMSC 414 Computer and Network Security Lecture 12' - nizana

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
capability myths
“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
equivalence myth
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
confinement myth
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
origin of confinement myth
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
revocation of capabilities
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
more generally
More generally
  • Use forwarding to revoke access…
advantages of capabilities
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)
  • 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
confused deputy
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
  • A trusted OS must provide (minimally) memory protection, file protection, access control, and user authentication
    • Authentication deferred to later…
  • Policies/models, design, assurance
trust vs security
“Trust” vs. “Security”
  • A “trusted” system meets the stated or expected security requirements
    • May or may not be “secure”…
  • May be degrees of trust…
security policies models
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…
military policy
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