Operating System Access Control

Background

Most of today's operating systems use Discretionary Access Control (DAC) as their primary access control mechanism. One key weakness of DAC is that it is susceptible to the trojan horse attack. An attacker can create a malicious program as a trojan horse, and a process running the trojan horse program will have the privileges of the user who runs it; thus the process can abuse these privileges and violate the intended DAC policy. For similar reasons, existing DAC mechanisms provide inadequate protection when softwares are buggy. When attackers are able to feed malicious inputs to buggy softwares, they may be able to exploit the bugs and take control of the process. From this point of view, buggy softwares become trojan horses when the attacker is able to feed inputs to them.

Exploiting this weakness of DAC, attackers are able to execute malicious code under the privileges of legitimate users, compromising end hosts. Host compromise further leads to a wide range of other computer security problems. Computer worms propagate by first compromising vulnerable hosts and then propagating to other hosts. Compromised hosts may be organized under a common command and control infrastructure, forming botnets. Botnets can then be used for carrying out attacks such as phishing, spamming, and distributed denial of service.

This project aims at developing Mandatory Access Control (MAC) techniques to enhance existing DAC mechanism to prevent host compromise. This project has several important differences from previous projects with a similar goal. First, usability is treated as a top priority. The usability goals are as follows: Configuring such a MAC system should not be more difficult than installing and configuring an operating system; and existing applications and common usage practices can still be used. This resulted in design choices that trade off security for simplicity and the introduction of novel exception mechanisms to the MAC rules. Second, the security objective is clearly defined and limited. The goal is to protect end host and user files against network attackers, malicious websites, and user errors. Third, the project closely integrates DAC and MAC, rather than viewing them as disjoint components. For example, MAC labels for files are inferred from their DAC permissions.

Personnel

Principles for Designing Usable Access Control Systems

We identified six principles for designing usable access control systems for operating systems.  See the UMIP paper for explanation of these principles.

  1. Provide "good enough" security with a high level of usability, rather than "better" security with a low level of usability.
  2. Provide policy, not just mechanism.
  3. Have a well-defined security objective.
  4. Carefully design ways to support exceptions in the policy model.
  5. Rather than trying to achieve "strict least privilege", aim for "good-enough least privilege".
  6. Use familiar abstractions in policy specification interface.

The Usable Mandatory Integrity Protection Model (UMIP)

The security objective of UMIP is to protect the system integrity against network-based attacks.  We assume that network server and client programs contain bugs and can be exploited if the attacker is able to feed input to them. We assume that users may make careless mistakes in their actions, e.g., downloading a malicious program from the Internet and running it.  However, we assume that the attacker does not have physical access to the host to be protected. Our policy model aims at ensuring that under most attack channels, the attacker can only get limited privileges and cannot compromise the system integrity.

The basic UMIP policy is as follows: Each process has an integrity level, which is either high or low. When a process is created, it inherits the integrity level of the parent process. When a process performs an operation that makes it potentially contaminated, it drops its integrity. Such operations include communicating with the network, receiving data from a low-integrity process through an interprocess communication channel, and reading or executing a file that is potentially contaminated. A low-integrity process by default cannot perform sensitive operations.

One novel feature of UMIP is that, unlike previous MAC systems, UMIP uses existing DAC information to identify which files are to be protected. In UMIP, a file is write-protected if its DAC permission is not world-writable, and a file is read-protected if it is owned by a system account (e.g., root, bin, etc.) and is not world-readable. A low-integrity process (even if running as root) by default is forbidden from writing any write-protected file, reading any read-protected file, or changing the DAC permission of any (read- or write-) protected file.

While the basic UMIP policy achieves the security goal, many existing applications will not be able to run and many common practices for using and administering the system will become impossible. Thus the basic UMIP policy is extended to balance the functional requirements, the security goal, and the simplicity of the design (for usability). UMIP introduces several concepts to model programs that are partially trusted; these programs can violate the default integrity policy in certain limited, well-defined ways. For example, a program can be declared to be a remote administration point, so that a process running the program does not drop integrity upon receiving network traffic. This enables remote system administration through, e.g., the ssh daemon. Such a program is only partially trusted in that a process running it still drops integrity when reading a low-integrity file or receiving data from another low-integrity process. For another example, exception policies can be specified for some programs so that even when they are running in low-integrity processes, they can access some protected resources.