<body><pre>
Fundamental enforcement mechanisms
  The gold(au) standard: AAA, classic systems security

  Authentication
    - authentication + authorization

  Authorization
    - access control mediates action by principals

  Audit
    - audit log records security-relevant actions

  A fourth:
    program analysis and verification

Design Principles for secure systems
  1) Complete Mediation: system must have ability to mediate all security
  relevant operations.
  Assumption: mediation mechanism cannot be compromised (Trusted Computing
  Base)
  Examples: OS calls, kernel mediates through interface.
  Problem: covert timing channels

  2) Minimize TCB: Complex things are more likely to fail,
  fewer errors, easier to convince it's correct.
  Practice: off by default

  3) Lease Privilege: just right for accomplishng its tasks, no more, no less
  Problem: what is the minimal set of privileges? what is the granularity
  of privileges? how&when do the privileges change?

  4) Open Design: success of mechanism should not depend on it being
  secret. The only secrets are cryptographic keys. "No security through
  obscurity."

  5) Security is a Process
  Every system has vulnerabilities. Goal: assurance.
  System changes over time. Requirements and context of mechanisms change 
  over time. 
  Secure systems require maintenance.

OS security mechanisms
  Conventional Mechanisms.
  Program is black box, talks to OS via mediating interface (system calls)
  - multiplex hardware
  - isolate processes from each other (hardward memory protection)
  - restrict access to persistent data
  - language independent, simple

  Weakness
  - Treating the program as a black box
    -- not fine-grained enough to enforce desired properties
    -- no help with validation (of Input/Output)
    -- internal behavior of program is important

  Reference Monitor
  - Most current enforcement mechanisms, observes the execution of
    a program and stops it if behaves bad. 

  1) Access Control
     Local but not system wide
     ACL / Capabilites(cannot be forged)
     Capabilities allows privileges to be delegated outside local system.
     E.g. cryptographically strong pseudorandom number, Mach file
     descriptors, Java object reference.

  2) Java: objects as capabilites
     Might leak from using downcast, reflection, etc.

  3) Mandatory Access Control / Multilevel Security
     Attach security labels to data processes, control of propagation.
     Data from process with label L always has label L. Traditional 
     Discretionary access control has no control of propagation at 
     discretion of reader.

     Problems:
     Read Up/Write Down (either rejected or adjustment needed)
     Label creep makes data unusable (as they don't go down)
     Expensive

  4) Cryptography

  5) Intrusion Detection
     Monitor behavior and take remedial action if behavior is suspicious.

     Problems:
     False alarms; Run-time overhead; Instability/e.g. Autoimmune Disease;
     What kind of assurance do you get?

  6) Virus Scanning
     Scan for seen suspicious code. But doesn't help with worms.

  7) Distribution/Partition
     
  8) Replication
     Can improve integrity at the expense of availability, or vice versa.
     OR can improve both (quorum system)

  9) Rollback/Undo

  10) Interposition
      May not know what is security-relevent at design time, need general
      mechanisms for extensible mediation, VM Minotor, SVM, Program Trans-
      formation.
      Problem: recognizable operations may be at wrong level of abstraction.
</pre></body>
