On different occasions, the same entity may be a subject or an object. A program is acting as a subject when it tries to read a file (the object in this case). When someone attempts to terminate that same process, the role switches to that of an object because the process is itself the target of an access request (termination) by yet another subject.

Where computers are concerned, the only types of access we need to define further are read and write. Remember the brief discussion regarding proofs of confidentiality and integrity? If you were performing a formal mathematical evaluation of a product, reducing all access statements to read and write would be required. Reading a security book at this low level would be about as interesting as watching wine age. Broadening the view is better because a variety of actions can be derived from read and write. These other actions might be creating an object, deleting an object, or renaming an object.

You use subjects, objects, and access rights to declare what can happen in a computer system. That is, they are used to specify the security policy you want to enforce. Now that you understand these basic definitions, the next topic of interest is how these relationships actually can be enforced.

The Reference Monitor

The security reference monitor (Anderson, 1972) is the black box controlling what happens when subjects make references to objects or try to access them. A reference monitor is an abstract concept. Every operating system available today implements some type of reference monitor to enforce security. The purpose of the reference monitor is to control requests by subjects to access objects (see Figure 1.1). One good way to visualize this concept is to think of subjects on the left, the reference monitor in the middle, and objects on the right. The only path subjects can take to get to objects is through the reference monitor. In lay terms, the reference monitor acts as a guard for the objects.

Figure 1.1  The reference monitor regulates subjects accessing objects.

The reference monitor consists of two main functions. First, the reference monitor provides reference functions that are used to evaluate access requests by subjects. Each time a subject wants to access an object, a reference function is computed and evaluated by the reference monitor. The reference monitor uses an authorization database to make decisions about whether to permit or deny requests it receives. When a request is forwarded to the reference monitor, it checks the authorization database to see whether the operation is permitted. A request in its most basic form is merely an attempt by a subject to access an object.

The authorization database conceptually contains entries or authorizations of the form {subject, object, access mode}. Recall from previous comments that only read and write access modes, or rights, need be considered. However, to have a meaningful discussion, other rights such as create and delete are permitted throughout this book. The authorization database is not part of the reference monitor, but it is something upon which the reference monitor depends. It is interesting to note that in formal analysis, entries in the authorization database specify what is not permitted, rather than what is allowed. This may sound odd, but it makes the proofs much easier. When specifying a security policy for your site, you probably are more accustomed to stating who can access what and how. When access control rules or authorizations are described in this book, the more familiar form is used stating who can access what and how it can be accessed.

The reference monitor controls changes to the authorization database itself through the use of its second part—authorization functions. The authorization database is used to permit or deny accesses to objects. Because the process of changing an entry in the authorization database is also an access request, this process can be similarly regulated using the notions of subject, object, and access. The reference monitor not only controls how subjects access objects, it also controls changes to the individual access rules.

That’s it. The reference monitor contains only two components—reference functions and authorization functions. True, building a secure computer system requires much more than just a reference monitor. The authorization database is one example of another component needed to ensure a secure system. Others will be added to the security model momentarily. For now, the key point to remember is that a reference monitor is an abstract engine enforcing access control using only two simple functions.

When you protect a file so that only specific users or groups can read the file, you are entering access control rules. The reference monitor is activated when you define the access control rules that conceptually exist in an authorization database. In reality, the access control rules probably are stored as permission bits or indicators with the file. When someone attempts to read the file, the reference monitor is activated again to evaluate the request. The reference monitor helps you define a policy, and then it helps you enforce the policy.

Plenty of example reference monitors exist outside of computer science. A teller at a bank performs reference-monitor functions by deciding whether to allow you (the subject) access to an account (the object). Possible actions include making a deposit, withdrawing a sum, or querying a balance. A manager or employee in the payroll department controls reference requests by responding to an employee who calls for personal payroll information. The payroll manager alone, though, controls authorization change requests. This control occurs when a new payroll employee is given limited power to look up information for regular employees but not for executives. Naturally, the right to change the authorization database is a powerful right in itself.