Cmsc 414 computer and network security lecture 12
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
Cmsc 414 computer and network security lecture 12

CMSC 414Computer and Network SecurityLecture 12

Jonathan Katz

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