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

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  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  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?  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  Use forwarding to revoke access…

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)

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

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

“Trusted” Operating Systems (Chapter 5)

Overview  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”  A “trusted” system meets the stated or expected security requirements –May or may not be “secure”…  May be degrees of trust…

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  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