Reference monitors

• Hardware (microprocessor)
• OS kernel (e.g. hypervisor: emulates the host computer, making it possible e.g. to run several OSs, each on a virtual machine, on one machine)
• OS (e.g. file access control - Unix/Windows later)
• Services (cf Java/.NET/databases/distr.systems - later)
• Applications (later)

Where we can put it depends (partly) on what information the RM needs in order to make a decision (vs which information is available in a layer), and the "protection granularity" of the layer (cf memory pages vs data stored in the page).

But also (Design decision 5):

• protect from the "layer below"

which is another argument for putting it as low as feasible.

An execution monitor checks each execution step (at some level of abstraction), possibly taking the history of execution steps into account, while static analysis (e.g. type checking) can analyse also future steps - what may or will happen.

Examples:

• at each file memory reference (execution step), check the permissions on the page of the reference
• at each file opening (execution step), check the file permission
• at each program step, check whether a Chinese Wall should be built
• at each network connection made, check whether the program is executing within code trusted to make a connection

Users (untrusted) must be able to use protected resources, e.g. access memory and perform I/O, but only in a controlled way.

Rules:

• Users must not be able to modify the (operating) system.
• Users must be able to use the (operating) system.
• Users must not be able to misuse the (operating) system.

How to control the use of the OS?

Examples of control mechanisms:

• context switch: (typically) by
  • traps/interrupts, using trap/interrupt vector (which needs protection)
  • privileged instruction (e.g. RTE on MC68k)
• memory:
  • MMU, page table, segment table, base/limit/bounds registers (need protection)
  • need privilege (security level) to modify these

The part of the OS kernel which implements the reference monitor:

• enforces security policy
• provides the security interfaces/mechanisms

Why "kernel"? [ring pictures: HW/OS kernel/OS/Appl, security spread out VS HW/SKernel/OS/Appl]

• Coverage (complete mediation): with kernel, OS can use ref.monitor
• Separation: easier to protect the security mechanisms from users and OS
• Unity: easier to track down errors/problems
• Modifiability: easier to make modificationas, test them, and see/understand effects
• Compactness: with only security functions, smaller
• Verifiability: (thus) easier to analyse and verify

Note:

• complete mediation may degrade system performance (cf. ACL checking at every write)
• kernel may/will not contain all security functions
  • e.g. user authentication:
    1. user interface
    2. user id lookup
    3. authentication data comparison
    4. authentication data updates

The TCB is "all parts which are necessary to enforce security", the parts of the system we depend on for security.

Intutition:

• the parts of the system which are not in the TCB can be implemented by evil crackers, and the system will still be secure
• our trust in the security of the system depends (only) on the TCB.

(Gollman: "Trusted: the parts that can hurt you.")

Often important to separate processes from eachother

• physical (run on different hardware/locations)
• temporal (run secure jobs at different times)
• logical (separate address spaces or use virtual machines)

Cf. the design principle of Least common mechanism

• minimise mechanisms shared between users to hinder information flow