Chapter 3
The Role of Access Control in Your Environment

Recall from Chapter 1, “Intrusion Detection and the Classic Security Model,” that the reference monitor is the portion of a computer model that performs access control decisions. After you have logged in, everything you do after that moment is regulated by the access control routines. The purpose of this chapter is to ensure that you have a clear understanding of the role that access control fulfills and to understand why intrusion detection is needed even if you think your reference monitor is doing its job. To accomplish this goal, you will learn about the types of access control features provided in UNIX and NT by default. Then, you’ll see why preventative access control techniques do not eliminate all of your problems.

Access control, like I&A, is a common place for hackers to attack. You know that I&A is imperfect and not completely successful as a preventative mechanism. Access control also leaves security exposures for two reasons:

Configuration Problems. Access control rules are not defined properly, thus providing the hacker a pathway for attacks. In general terms, the system is improperly configured.

Program Bugs. Flaws are found in the implementation of programs that enable an adversary to circumvent access control.

In the next two sections, you will find a quick overview of how configuration problems and program bugs lead to weaknesses in access control. To understand specific examples of these flaws, you need to understand how UNIX and NT implement access control. When this material is covered, you will see specific examples of how hackers get around access control systems and why you need intrusion detection to catch these events.

Configuration Problems

One of the most challenging tasks in building and shipping a complicated software product is the process of assigning ownership for files and configuring access control rules for all of the files in the product. Many system administrators have installed commercial products from shrink wrap media only to find that the default configuration is not secure. As the complexity of the product grows, so does the difficulty of properly defining default access control rules for the product.

The most common mistake occurs when the vendor sets file or directory access control rules that are too permissive. For example, a privileged program might be provided with a software product. The program should be run only by administrators. The flaw is that the default permissions enable any user to run the program. A definite security problem exists here.

A variation on this situation occurs when a privileged program reads information from a data file and alters its behavior according to the values it reads. If the directory or file permissions enable any user to modify the contents of the data file, then a lowly user with no special rights on the system can trick the privileged program into doing something it should not. Notice in both of these cases that the reference monitor is acting in a perfectly valid way. The reference monitor looks at the credentials for the subject, looks at the access control rules on the object, and allows the operation to proceed. The hole exists because the access control rules are not configured to accurately reflect the security policy for the site.

You might think identifying default configuration problems during product testing would be easy. However, if the product is developed by dozens or hundreds of programmers, you cannot always find a single individual who understands all of the security issues and interaction effects of the product. Not all programmers keep security at the forefront of their hot list, either. Sometimes, just getting the program or subsystem to function properly is challenging enough. Like software documentation, security issues are often left for the end of the development cycle when little time is available for thoroughness.

A related and equally important cause of system hacks is the system administrator configuration error. Someone who administers hundreds or thousands of users and a similar number of files and resources and has responsibility for many other tasks is bound to occasionally make a configuration mistake. These errors also can lead to security breaches.

Program Bugs

Access control rules, even if perfectly configured, are not sufficient for securing a computer system because the possibility of programming errors always poses a threat. Computer operating systems divide users into two broad categories—privileged users and normal users. To be precise, various types of privileged users exist, but for the moment, two categories will suffice. A privileged program is often invoked by a normal user to perform a task on behalf of the normal user. The privileged program runs under the identity of a privileged user.

Sometimes programmers make mistakes. You may find mistakes in software a lot more frequently than “sometimes,” but this is a topic for a different book. When a mistake sneaks into software, it can take several forms:

•  The programmer forgets to check the input parameters passed to the program.

•  The programmer forgets to check boundary conditions, particularly when dealing with string memory buffers.

•  The programmer forgets the basic principle of least privilege. The entire program is run in privileged mode, rather than running only a limited subset of the instructions in privileged mode and all other statements with reduced privileges.

•  A programmer creates a resource, such as a file or directory, from within the privileged program. Instead of explicitly setting the access control rules for the resource (least privilege), the programmer assumes default permissions would be set properly. Often, the programmer never even stops to think about setting permissions for privileged resources created by a program.

All of these weaknesses have been used to attack systems. Improper input parameters have been used to trick a privileged program into doing something it should not. Buffer overflow attacks are implemented by providing to a privileged program an input string that is too long. The programmer does not check the length of the input string. In the bogus input string are executable statements that the privileged program accidentally puts on the instruction stack. The program fragment is specially written to give increased privileges to the hacker or to an account that has been compromised. For example, a buffer overflow attack can be used to add a user to the system and to give that user superuser privileges. Generally, the first step in a buffer overflow attack is to gain access to a root shell on UNIX systems.