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