<body><pre>
Access Control
Martin Abadi UCSC

The access control model
  -- Elements
     - Objects or resources
     - Requests
     - Principals (sources for requests)
     - Reference monitor (to make decision on requests)
  -- Access control matrix (Lampson, 1971)

Authentication vs. Access Control
  -- Who says S (Authentication)
  -- Is A trusted on S; If A request s on S is it authorized.
     (Access Control)

Implementation (a pair of Dual, and often combined)
  -- ACL : a column of matrix
     - Easy to review.
     - Can be compact.
     - Negative entries (order-dependent evaluation)
     - Revoking a subject can be painful.
  -- Capabilities : a pair of an object and an operation 
     <file1, r>
     - a row of access control matrix
     - easy to pass around
     - hard to revoke
     - stored in protected space, with special hardware protected
       tags, referenced in a typed language, with a secret, with
       certs, so it's difficult to forge a capability

Principle of complete mediation:
  Every access to every object is checked.
  OS, hardware, software wrapper/interpreter can catch sets
  of these requests.

Conjunctions
  -- A request be granted only if it is made JOINTLY by several
     principals.
  -- A conjunction may or may not be made explicit in the access
     policy.

Groups and Roles
  Principals can be organized into groups, (principals) can play roles.
  -- May be used as a level of indirection in access control.
  -- e.g.
       member of group G may access a file f owned by A
       - G maybe controlled by someone other than A
       - G may change, without immediate knowledge of A
       - ACL should be short and clear
       - Proofs of membership resemble(are) capabilities
       - Access to f might be partly anonymous
       - A may require a proof of identity at each access to f

  Objects and operations can also be put in groups.
  -- all company files

  Sometimes operations should be grouped (bundled) too.
  -- read a patient's record
  -- write a log record

Design Choices
  -- Principals, objects, and operations should have the "right"
     granularity and be at the right level of abstraction.
     - for ease of understanding
     - to avoid giving away too much info
     e.g. use a program to hide the detail of what a subject can do

Programs
  They may be principals too.
  -- deal with call chain
  -- connect programs to other principals
     - who write them
     - who install them
       Should be set up so they get appropriate rights when they run
     - who call them
       programs should be adequately protected from editing
  -- what is the run-time right of a program
     - combine system rights and user rights
     - some answers: setuid, program id, code access security, proof-
       carrying code.

Protection and Confinement
  Should be protected and confined so programs are limited to communicate
  over proper interfaces.
  -- often the job of OS and Hardware, each program has its own space
  -- a language and its run-time system can provide finer control over
     communication

Common Dangers
  Can be insufficient or irrelevant
  -- Circumventing Access Control
     - reference monitor does not protect all objects, or at all time
       e.g. race condition, data recovery (through virtual memory),
       hostile platforms (DRM system)

Issues
  -- Pervasive
  -- Difficult to get right
  -- Even harder for distributed systems

General theories and systems
  -- logics, langauges, infrastructures(PKI), architectures
  -- algorithmic analysis (Harrison, Ruzzo, Ullman, 1976)
     - System, Configuration, Command
     - Safety is undecidable (untrusted subjects cannot access
       object in any reachable state)
     - Some are decidable, e.g. containment problem (Li, Michell 2003)
  -- formal verification (not practical at the time)
  -- a logic from matrices
     - a ternary predicate symbol 'may-access'
       may-access(Alic, Foo.txt, Rd)
       may-access(p, o, Wr) -> may-access(q, o, Rd)
     - does this help? may need other constructs and axioms

Access control in Distributed Systems
  Challenges
  -- size
  -- faultiness of nodes
  -- heterogeneity of channels, protection mechanisms, etc
  -- lack of central adminstration and central trust

An approach
  1) Notation
  2) Derivation Rules

  Early ideas from (Roger Needham, 1987)
  Calculus for Access Control (Abadi, 1993)

</pre></body>
