Notes for December 5, 2000

  1. Greetings and Felicitations!
    1. Final study guide
  2. Puzzle of the day
  3. Lattice Model
    1. Set of classes SC is a partially ordered set under relation <= with GLB, LUB
    2. Note: <= 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 lattics of categories
    4. Examples: (A, C) <= (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 INTERSECT C')
    5. Example: ( { 1, 2, 3, 4, 5 }, <= ); ( {stages of painting by the numbers }, containment)
  4. Biba: mathematical dual of BLP
    1. P may read O if L(P) <= L(O) and C(P) SUBSET C(O)
    2. P may write O if L(O) <= L(P) and C(O) SUBSET C(P)
    3. Combined with BLP: continue example
  5. 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.
  6. Malicious logic
    1. Quickly review Trojan horses, viruses, bacteria; include animal and Thompson's compiler trick
    2. Logic Bombs, Worms (Schoch and Hupp)
  7. Ideal: program to detect malicious logic
    1. Can be shown: not possible to be precise in most general case
    2. Can detect all such programs if willing to accept false positives
    3. Can constrain case enough to locate specific malicious logic
    4. Can use: writing, structural detection (patterns in code), common code analyzers, coding style analyzers, instruction analysis (duplicating OS), dynamic analysis (run it in controlled environment and watch)
  8. Best approach: data, instruction typing
    1. On creation, it's type "data"
    2. Trusted certifier must move it to type "executable"
    3. Duff's idea: executable bit is "certified as executable" and must be set by trusted user
  9. Practise: Trust
    1. Untrusted software: what is it, example (USENET)
    2. Check source, programs (what to look for); C examples
    3. Limit who has access to what; least privilege
    4. Your environment (how do you know what you're executing); UNIX examples
  10. Practise: detecting writing
    1. Integrity check files a la binaudit, tripwire; go through signature block
    2. LOCUS approach: encipher program, decipher as you execute.
    3. Co-processors: checksum each sequence of instructions, compute checksum as you go; on difference, complain

Matt Bishop
Office: 3059 Engineering Unit II Phone: +1 (530) 752-8060
Fax: +1 (530) 752-4767
Email: [email protected]
Copyright Matt Bishop, 2000. All federal and state copyrights reserved for all original material presented in this course through any medium, including lecture or print.

Page last modified on 12/8/2000