Implementing Complete Mediation

Recall, whether or not a system is secure is something that is relative to a security policy. The class of security policies that we have so far been discussing---Access Control Policies---involves a Complete Mediation mechanism and an Access Control Matrix. Last lecture covered one embodiment: JDK 1.2. Today we look at implementing this picture for a more general setting. Specifically, we discuss how to implement Complete Mediation. Subsequent lectures will discuss how to store the Access Control Matrix.

A reference monitor is a piece of software that checks every reference made by subjects to objects. (Note, a reference monitor is not the only way to implement Complete Mediation. You could also analyze the program before it is executed with an eye toward certifying that all accesses will be consistent with some stated access control policy.) As we discuss different reference monitor implementations, we will need some basis for comparing them. The basis we employ is simple: Complicated things are more likely to be flawed, hence to contain vulnerabilities. Computer Security researchers capture this notion by talking about the trusted computing base (TCB) for a system. The TCB comprises all of the (software and hardware) components that must function correctly for the system to implement its security policy. Thus, if any component in the TCB is compromised, then so is the system's security. By having the TCB be small, it is less likely to contain vulnerabilities, because it will be easier to understand, test, and analyze. Size and complexity of a reference monitor implementation is therefore a reasonable metric of quality.

Some system developers have structured operating systems in terms of a security kernel, a very small TCB on top of which the rest of the OS sits. This approach however has never caught on, probably because of the higher performance costs it entails. Services located in the kernel are often faster, and minimizing operating system overhead is perceived as an important goal. So, today, UNIX has a very large kenel as does Windows NT. The TCB's for these systems are far too large for anyone to have confidence that they are trustworthy.

How do we write a reference monitor? We discuss three approaches:

Approach 1. Use an interpreter. The target program does not execute directly on the underlying hardware but instead is interpreted by another program. Every target program instruction is thus executed only after it has been checked and found not to be violating the security policy being enforced.

This architecture has some implications:

• It allows a very broad range of security policies (e.g. "do not execute two MOV instructions in a row", or "do not write to this particular block on disk").
• It is usually very slow, because executing a single target instruction now requires the interpreter to execute multiple (12?) instruction. Nevertheless, this architecture is employed by Java; the interpreter for Java is called JVM.

Approach 2. Use a wrapper. A wrapper is an environment that intercepts (and interprets or redirects) only some of the instruction issued by the target program. Thus, target execution is potentially faster because the wrapper-overhead is not seen for all instructions executed by that target.

Certain security policies cannot be implemented with wrappers, because a wrapper can only restrict those events that it sees. Security policies that involve target instructions not intercepted by the wrapper cannot be enforced by the wrapper. The performance improvement of this implementation approach depends on identifying instructions that should be intercepted. We might distinquish those instructions by looking at their opcodes (e.g. a call to READ is caught, ADD is not) or by looking at their operands (e.g. normal memory accesses are not caught but READ/WRITE to memory-mapped I/O is).

Approach 3 - Exploit hardware to intercept relevant instructions.

Today's processor architectures are designed based on some assumptions about processes:

• Associated with each process is some region of memory.

  

• There exists some state that is not associated with any process (e.g. I/O registers). The instructions to manipulate this state are somehow distinct from other machine-language instructions. Usually, this separation is achieved by implementing two modes of operation for the processor and having two sets of instructions. If a process is in user mode then only a subset of all instructions can be executed. A process in supervisor mode can execute any instructions. The instructions available only in supervisor mode are the only ones that can be used for manipulating the processor state not associated with the process.

• The OS is the custodian of things like I/O control and memory maps (e.g. segment/page tables, base/bounds registers). Processes do need to manipulate those resources (e.g write to disk or request more memory). Therefore, there is a special instruction (e.g., SVC) to invoke operating system routines, which implement that manipulation. We thus allow user processes to execute sequences of instructions in supervisor mode but restrict them to executing only certain sequences of instructions in supervisor mode. These selected sequences manipulate the operating-system owned resources in reasonable ways.

For example, UNIX enforces a security policy on files. In UNIX, we can restrict/allow read/write access to files but cannot enforce a policy on reading/writing shared variables. The reason is that the instructions for manipulating shared variables are not implemented by the operating system.

Taking a step back, the architecture of the system we have been describing is as follows: Use memory protection to restrict processes from accessing memory belonging to other processes and to protect the integrity of the memory used by the OS. State associated with no process is accessed by processes indirectly, through the routines that are called using SVC.

Note, we can achieve the same effect by using operands of instructions instead of the opcode. We would need a way to invoke the OS for certain operands and not others. This can be done by using a memory architecture. Specifically, segmentation can be set up to cause a trap whenever a process tries to access a particular segment. This method is quite powerful, because by supporting very small segments, we could then associate a different policy with each method or procedure call (if segments are small). The Multics system was built this way.