CMSC 414 Computer and Network Security Lecture 12

1
CMSC 414Computer and Network SecurityLecture 12

• Jonathan Katz

2
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

3
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

4
Confinement myth

• Myth Capabilities can be delegated at will and
  therefore cannot be confined
• Butcan 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

5
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

6
Revocation of capabilities?

• Capabilities may expire with timeor 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

7
More generally

• Use forwarding to revoke access

8
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)

9
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

10
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
• Dont know about a resource if you dont 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

11
Trusted Operating Systems (Chapter 5)
12
Overview

• A trusted OS must provide (minimally) memory
  protection, file protection, access control, and
  user authentication
• Authentication deferred to later
• Policies/models, design, assurance

13
Trust vs. Security

• A trusted system meets the stated or expected
  security requirements
• May or may not be secure
• May be degrees of trust

14
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

15
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