cmsc 414 computer and network security lecture 12 n.
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

Download Now 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