Outline for May 28, 1997

  1. Greetings and Felicitations
  2. ORCON (Originator Controlled; Graubert)
    1. Document/information can be passed on with approval of originator; real world justification is that originator of document trusts recipients not to release documents which they should not.
    2. Untrusted subject x marks object O ORCON on behalf of organization X and indicates it is releasable to subjects acting on behalf of organization Y. not releasable to subjects acting on behalf of other organizations without X's permission, and any copies made have the same restriction
    3. DAC: can't do this as the restriction would not copy over (y reads O into C, puts its own ACL on C)
    4. MAC: separate category with O, x, y. y wants to read O, copy to C; MAC means C has same category as O, x, y, so can't give z access to C. Say a new organization w wants to provide data in B to y but not to be shared with x or z. Can't use O's category. Hence you get explosion of categories. Real world parallel: individuals are "briefed" into a category and those represent a formal "need to know" policy that is standard across the entity; ORCON has no central clearinghouse to categorize data; originator makes rules.
  3. Solution?
    1. Owner of object can't change ACL's relationship with object (MAC characteristic)
    2. On copy, ACL is copied as well (MAC characteristic)
    3. Access control restrictions can be tailored on a per-subject/object basis (DAC characteristic)
  4. Verifiably Secure Systems
    1. Reference monitors; use them to isolate all access control functions into a small nucleus; the "security kernel"
  5. UCLA Secure UNIX
    1. Each user process in separate domain, with 2 parts: the application program level (user mode) and the UNIX interface/Kernel Interface SubSystem level (supervisor mode)
    2. Protection domains set by C-Lists
    3. Policy manager manages policies for kernel objects, shared files
    4. Dialoguer provides trusted path between user, terminal
  6. KSOS (Kernel Secure Operating System)
    1. Complete OS (not a security kernel)
    2. Enforces access control policy and multilevel security
    3. Handles files and type extensions
    4. UNIX emulator, "trusted" non-kernel system software run in supervisor mode
  7. PSOS (Proveably Secure Operating System)
    1. Levels of abstraction
    2. For PSOS:
      command interpreter
      user environments, name space
      user I/O
      procedure records
      user processes, visible I/O
      creation, deletion of user objects
      directories
      abstract data types
      virtual memory (segmentation for PSOS)
      paging
      system processes, system I/O
      primitive I/O
      basic arithmetic, logical operations
      clocks
      interrupts
      real memory (registers, main store)
      capabilities


Notes by Eddie Lo
You can get this document in Postscript, ASCII text, or Framemaker version 5.1.
Send email to cs253@csif.cs.ucdavis.edu.

Department of Computer Science
University of California at Davis
Davis, CA 95616-8562



Page last modified on 6/12/97