Outline for February 22, 2001

1. Greetings and felicitations!
   1. Friday Feb 23 1:10-2:30 (if not in this room, look in 1062 Banier); go to 1101 Hart Hall to view
   2. No class Tuesday (another trip, sigh ...)
2. Design Principles
3. Example Mechanism: MULTICS ring mechanism
   1. MULTICS rings: used for both data and procedures; rights are REWA
   2. (b₁, b₂) access bracket - can access freely; (b₃, b₄) call bracket - can call segment through gate; so if a's access bracket is (32,35) and its call bracket is (36,39), then assuming permission mode (REWA) allows access, a procedure in:
      rings 0-31: can access a, but ring-crossing fault occurs
      rings 32-35: can access a, no ring-crossing fault
      rings 36-39: can access a, provided a valid gate is used as an entry point
      rings 40-63: cannot access a
   3. If the procedure is accessing a data segment d, no call bracket allowed; given the above, assuming permission mode (REWA) allows access, a procedure in:
      rings 0-32: can access d
      rings 33-35: can access d, but cannot write to it (W or A)
      rings 36-63: cannot access d
4. Confidentiality: Bell-LaPadula Lattice Model
   1. Set of classes SC is a partially ordered set under relation dom; with GLB (glb), LUB (lub)
   2. Note: dom is reflexive, transitive, antisymmetric
   3. Application to MLS: forms a lattice with elements being the Cartesian product of the linear lattice of levels and the subset lattices of categories
   4. Examples: (A, C) dom (A', C') iff A' <= A and C' SUBSET C;
      lub((A, C), (A', C')) = (max(A, A'), C UNION C')
      glb((A, C), (A', C')) = (min(A, A'), C INTER C')
5. Integrity Policy: Biba
6. Integrity Policy: Clark-Wilson
   1. Theme: military model does not provide enough controls for commercial fraud, etc. because it does not cover the right aspects of integrity
   2. Data items: "Constrained Data Items" (CDI) to which the model applies, "Unconstrained Data Items (UDIs) to which no integrity checks are applied, "Integrity Verification Procedures" (IVP) that verify conformance to the integrity spec when IVP is run, "Transaction Procedures" (TP) takes system from one well-formed state to another
   3. Certification and enforcement rules:
      C1. All IVPs must ensure that all CDIs are in a valid state when the IVP is run
      C2. All TPs must be certified to be valid, and each TP is assocated with a set of CDIs it is authorized to manipulate
      E1. The system must maintain these lists and must ensure only those TPs manipulate those CDIs
      E2: The system must maintain a list of User IDs, TP, and CDIs that that TP can manipulate on behalf of that user, and must ensure only those executions are performed.
      C3. The list of relations in E2 must be certified to meet the separation of duty requirement.
      E3. The sysem must authenticate the identity of each user attempting to execute a TP.
      C4. All TPs must be certified to write to an append-only CDI (the log) all information necessary to resonstruct the operation.
      C5. Any TP taking a UDI as an input must be certified to perform only valid transformations, else no transformations, for any possible value of the UDI. The transformation should take the input from a UDI to a CDI, or the UDI is rejected (typically, for edits as the keyboard is a UDI).
      E4. Only the agent permitted to certify entities may change the list of such entities associated with a TP. An agent that can certify an entity may not have any execute rights with respect to that entity.
7. Cryptography
   1. basics (cryptosystems, attacks, codes vs. ciphers, superencryption)
   2. substitution ciphers (Cæsar cipher, Vigenère cipher)
   3. transposition ciphers (rail-fence cipher)
   4. product cipher (DES)
   5. public key crypto (RSA, DH)
   6. cryptographic checksums
   7. key management (Kerberos, PKI)
   8. digital signatures
   9. authentication
   10. Examples: PEM, PGP, IPSec

Principle of Economy of Mechanism
The protection mechanism should have a simple and small design.

Principle of Fail-safe Defaults
The protection mechanism should deny access by default, and grant access only when explicit permission exists.

Principle of Complete Mediation
The protection mechanism should check every access to every object.

Principle of Open Design
The protection mechanism should not depend on attackers being ignorant of its design to succeed. It may however be based on the attacker's ignorance of specific information such as passwords or cipher keys.

Principle of Separation of Privilege
The protection mechanism should grant access based on more than one piece of information.

Principle of Least Privilege
The protection mechanism should force every process to operate with the minimum privileges needed to perform its task.

Principle of Least Common Mechanism
The protection mechanism should be shared as little as possible among users.

Principle of Psychological Acceptability
The protection mechanism should be easy to use (at least as easy as not using it).

Matt Bishop Office: 3059 Engineering Unit II Phone: +1 (530) 752-8060 Fax: +1 (530) 752-4767 Email: bishop@cs.ucdavis.edu

Copyright Matt Bishop, 2001. All federal and state copyrights reserved for all original material presented in this course through any medium, including lecture or print.