Tom Kelliher, CS42

Nov. 25, 1996


A mechanism for controlling the access of programs, processes, or users to the resources defined by a computer system.
How good is this?

Examples from what we've already studied?

Design Goals

  1. Separate un-trustworthy entities.

  2. Control access to resources.

  3. Detect design flaws, malfunctioning subsystems.

  4. Provide flexible mechanisms for supporting a multitude of policies.

What's being protected: objects in the name space.

Need-to-know principle:

At any time, an object should only have access to those objects needed to work toward the completion of its task.
Example: the root account on a Unix system.

Domain-Based Protection


A set of access rights. An access right is an order pair, <object-name, rights set>, stipulating what operations (rights set) may be applied to an object (object-name). An object works within one domain at a time, with the possibility of switching domains.
  1. Static, dynamic domains.

  2. Static domains and need-to-know.

  3. The intersection of domains need not be empty.

Objects which may make use of domains:

  1. Users.

  2. Processes, threads.

  3. functions.

Unix Example

  1. Users switch between domains.

  2. su.

  3. Setuid.
    % ls -l `which xterm`
    -rwsr-xr-x  1 root  wheel  131072 Jan  2  1996 /usr/X11/bin/xterm*

  4. Setgid.
    % ls -l /usr/sbin/sendmail /usr/sbin/lpc
    -r-xr-sr-x  1 bin   daemon   16384 Jan  1  1996 /usr/sbin/lpc*
    -r-sr-sr-x  3 root  kmem    208896 Oct 12 16:42 /usr/sbin/sendmail*

  5. Problems with setuid programs:
    1. Shell escapes.

    2. Shell scripts.

  6. ``Safe'' setuid programs:
    1. Custom-written programs.

    2. Perl.

Multics Example

  1. Domains are hierarchical rings (0--7). Ring 0 highest privilege.

  2. Functions exist within domains.

  3. Processes change domains through function calls. Gating to provide protection.

  4. Consequences wrt. need-to-know?

Access Matrix

General model of a domain.

  1. Rows: domains.

  2. Columns: objects. Includes:
    1. Domains.

    2. The access matrix itself.


  1. Standard access rights: read, write, execute, etc.

  2. Switch: switch from one domain to another.

  3. Copy: allows a right to be propagated to other domains (*). Variations.

  4. Owner: a domain owns an object; may modify rights at will.

  5. Control: a domain controls another domain; may remove any rights.



  1. Very sparse matrix.

  2. Global table: ordered triples <domain, object-name, rights set>.


  1. Storage efficiency.

  2. Rights-checking efficiency.

  3. Ease of adding, revoking rights.

Access Lists

  1. List associated with each object.

  2. Order pairs: <domain, rights set>.

  3. Variation: Search access list on first access, receive and use capability subsequently.

Capability Lists

  1. List of ordered pairs, <object, rights> associated with a domain.

  2. Inaccessible to objects in the domain.

  3. A ``secure'' pointer.

  4. Revocation implementation:
    1. Expiration, reacquisition.

    2. Back-pointers.

    3. Indirection.

    4. Keys.

Example: kerberos(1).


  1. Combination of access list, capabilities.

  2. Keys associated with domain, object.

  3. Access permitted if a domain key matches an object key.

Thomas P. Kelliher
Mon Nov 25 09:24:08 EST 1996
Tom Kelliher