| Previous | Table of Contents | Next |
Nothing in the access control system will detect these problems. Only by monitoring your systems and looking for specific security policy violations will you detect errors such as these. Intrusion detection systems look for event patterns, such as the creation of world readable resources by a privileged program.
In some sense the login process itself is a form of access control, too. The login process limits who can access the computer. Unfortunately, this is not the type of access that was defined in the basic security model. Recall from that introductory material that access control in the security reference monitor is limited to the simple notions of read and write reference requests. The remainder of this chapter deals with how you access resources and accomplish tasks after you have survived the login steps.
The confusion about what precisely constitutes access control stems from various interpretations that appear in marketing literature. You might read a brochure claiming that a particular product can help limit access to your critical resources. Reading further, you find that the advertised solution is really a badge card reader that limits physical access to systems. In some respects, a router that regulates network traffic also performs access control functions because it will drop packets that do not satisfy configured routing rules. Still, for the purposes of this chapter, access control is considered only in the context of the operating system itself and its reference monitor.
Recall also from Chapter 1 that access control is the primary function of the reference monitor. An access request by a subject for an object is checked by the reference monitor against a conceptual database of access control rules. In theoretical computer discussions, entries in the access control database describe what is not permitted. In practice, and in the rest of this book, access control statements instead state what is permitted. The three values of interest in the access request are the subject identifier, the object identifier, and the type or mode of access requested. Changing one or more of these three values can generate a different result when the request is evaluated.
Think about that last statement again in more detail. Who the system thinks you are is the basis for deciding what you can do. When you log in to a computer, your subject identifier is created from your account information stored in the system. If you want to access a resource on the system, your subject identifier is passed to the reference monitor in the request. If you find a way to impersonate another subject or a way to change your subject identifier, you might be able to access a resource in a manner that normally would not be allowed. In most systems, this is both a design feature and a threat.
UNIX security features are provided for changing subject identifiers in a controlled fashion. These subroutines are the primary means of temporarily increasing privileges for a user, but they also provide avenues for hacker attacks if the implementation is not properly coded by the programmer. NT defines a special privilege that allows a process or thread to impersonate another user. Later in this chapter, you will see how subject identifiers can be changed in UNIX. To keep the issues from getting too confusing, Chapter 10, “Intrusion Detection for NT,” covers impersonation.
NOTE: Remember that you sometimes must request access to a resource that you cannot regularly reference. To accomplish your task, the system magically invokes a process with higher privileges to carry out the job on your behalf. Because this latter process has higher privileges, the boundary through which your process communicates with this privileged process must be tightly controlled. Otherwise, you might be able to send this privileged process information that tricks it and enables you to hack the system.
When you have logged into a system, everything else that happens seems to be regulated by access control. If you want to print a document, access to printers and documents must be granted. You can accomplish something after you have logged in and started a shell, desktop, or some other type of session in one of two ways:
First, you can create new programs that operate on your behalf. Many commands that you type into a shell are interpreted and executed directly by the shell. However, the majority of commands that you type into a UNIX shell will create new programs, even if these programs run for only a few moments.
Second, you can have your shell send a message to another program that already is running on the computer. This latter form of activity on the system is called inter-process communication (IPC) because two running processes are communicating with each other. Instead of creating a new process to execute some commands on your behalf, you can send an IPC message to another program that performs the task for you.
An example of this process is the print spooler on most systems. The spooler is a program running constantly on the system. You might use a direct communication channel to ask the spooler to print something for you, such as sending a print request through an IPC. You also can communicate with the spooler indirectly by storing a file in a special location that the spooler checks. In either case, you can communicate to the spooler that you want some action to occur—printing.
Depositing data, such as a file to print or mail, is a technique hackers have used to gain additional privileges on a system. Common Desktop Environment (CDE) had a bug in its mailer that gave peon users the capability to write any file into the mail directory. In some cases, a normal user could create a empty mail box in this directory for the root user. The mailbox would be owned by the normal user, not by root. At any later time, the peon could read the contents of the root user’s mailbox. Access control worked as designed; the access control rules just weren’t configured properly.
When you perform activities on the system, the credentials associated with your process (UID and GIDs) are checked to see whether the requested operations are permitted. If you run a program, the program has your credentials. If you communicate with another process using an IPC, the credentials of your process are checked by the receiving program. If you deposit data into a directory for a privileged program to act upon, the owner and group IDs for the file represent your credentials, and the privileged program inspects this information to make security decisions. These behaviors show access control at its most fundamental level of analysis—identifiable subjects request access to objects.
| Previous | Table of Contents | Next |