Section 1.2. The Evolution of Access Control Security in Operating Systems
1.2. The Evolution of Access Control Security in Operating SystemsEarly operating systems had little or no security; a user could access any file or resource just by knowing how to name the resource. Fortunately, it was not long before access control mechanisms began to emerge to provide some sense of security. The predominant type of access control we have today is called discretionary access control (DAC). The primary feature of DAC is that individual users, often a resource "owner," can specify who may or may not access the resource. As you will see, DAC has some fundamental security weaknesses that are intrinsic to its nature. To overcome these weaknesses, the computer security community has been trying to develop useful mandatory access control (MAC) mechanisms. MAC is intended to avoid the weaknesses of DAC while providing the security required. Unfortunately, creating a useful MAC mechanism that is secure yet flexible enough to address a wide range of problems has proven difficult. The primary value that SELinux brings to Linux is a flexible, configurable MAC mechanism. In the remainder of this section, we explore the strengths and weaknesses of various DAC and MAC mechanisms, as a means to provide a context for understanding the true value that SELinux provides. 1.2.1. The Reference Monitor ConceptTo understand access control, you must have an appreciation for the reference monitor concept. The U.S. Department of Defense led the early research into operating system security in the 1970s and 1980s. A key early report from that work, the so-called Anderson Report, [3] defined for the first time this fundamental model-for characterizing access control in operating systems (see Figure 1-1).
Figure 1-1. The reference monitor concept In a reference monitor, the operating system isolates passive resources into distinct objects such as files and active entities such as running programs into subjects. The reference monitor mechanism (called a reference validation mechanism) would then validate access between subjects and objects by applying a security policy as embodied in a set of access control rules. In this manner, program access to system resources such as files can be limited to those accesses that accord with the security policy. Access control decisions are based on security attributes associated with each subject and object that represents the subject's/object's security-related characteristics. For example, in standard Linux, subjects (that is, processes) have real and effective user identifiers, and objects (for example, files) have access permission modes that are used to determine whether a process may open a file. Other than implementing the security policy, the fundamental design goals of an implementation of the reference monitor concept are that it be:
Nearly all operating systems implement some form of a reference monitor and can be characterized in terms of subjects, objects, and security policy rules. In standard Linux, subjects are generally processes, and objects are the various system resource used for information sharing, storage, and communication (files, directories, sockets, shared memory, and so on). In Linux, as in most other popular operating systems, the security policy rules enforced by the reference monitor (that is, the kernel) are fixed and hard-coded, whereas the security attributes that these rules use for validation (for example, access modes) can be changed and assigned. Standard Linux security is a form of DAC security. 1.2.2. The Problem with Discretionary Access ControlAs noted, DAC is a form of access control that usually allows authorized users (via their programs such as a shell) to change the access control attributes of objects, thereby specifying whether other users have access to the object. A simple form of DAC might be file passwords, where access to a file requires the knowledge of a password created by the file owner (and distributed by word of mouth to other users authorized to view the file). Most DAC mechanisms are based on user-identity access control attributes. Nearly all modern operating systems have some form of user-identity-based DAC. In Linux, the owner-group-world permission mode mechanism is prevalent and well known. Likewise, a more general access control list mechanism is also common. All DAC mechanisms have a basic weakness in that they fail to recognize a fundamental difference between human users and computer programs. DAC typically tries to emulate an ownership concept where; for example, file owners have the right to specify access to files and only give access to other users they trust to access the file.[4] Assuming that you can trust the human user (arguably an invalid proposition in general), the way computers work does not directly model the real world. Simply put, users rely on software, not of their own creation, to perform functions on the computer. So, we are not really giving users the ability to grant and use access. Instead, we are giving software programs this capability. As has become obvious in the age of the Internet, programs are often full of flaws or are downright malicious. This is the problem with Trojan horses, first recognized in the 1970s, of which today's modern viruses, worms, and spyware are just variants. In short, if a user is authorized access, that really means programs are authorized that access, and if programs are authorized that access, malicious programs will have that same access.
DAC assumes a benign environment where all programs are trustworthy and without flaws. Although the early computer research community, which largely lived in an academic world and from which so much of our current technology evolved, might have wished for such an environment; in reality, however, we know of no such benign computer environment in the entire history of computer science. Human nature will always have those who exploit weakness in flawed software. 1.2.3. The Origins of Mandatory Access ControlThroughout the 1970s and 1980s, significant energy was exerted to address the problem of malicious and flawed software. The goal was to achieve MAC, where the basis of access control decisions was not at the discretion of individual users or even system administrators. We wanted to implement an organizational security policy to control access to objects that could not be affected by the actions of individual programs. The military funded most of this work, which focused on protecting the confidentiality of classified government data. In particular, the most common MAC mechanisms implemented to date address the problem of multilevel security, a simplified form of which is shown in Figure 1-2. Figure 1-2. Multilevel security model Multilevel security (MLS) is typically based on a formal model called the Bell-LaPadula model. [5] In the MLS model, all subjects and objects are labeled with a security level. In our example, we have a PUBLIC and a SECRET sensitivity level. The levels represent the relative sensitivity of the data and the clearance of the user on whose behalf the subjects are operating (SECRET being data of "higher" sensitivity than PUBLIC). In MLS, subjects can always read and write objects at the same sensitivity. In addition, subjects can read lower-level objects ("read down") and write higher-level objects ("write up"). However, a subject may never read higher-level objects ("no read up") nor write lower-level objects ("no write down"). The idea being that information can flow from lower levels to higher levels, but not the reverse, thereby protecting the confidentiality of the higher-level data.
MLS was a radical change in the way we thought about access control. No longer are data owners arbitrarily determining who may access objects. Further, we could now have strong security assuming most software was untrusted, because the information flow rules prevent inappropriate data access. In MLS, the organization decides via fixed rules how data may be shared regardless of the desires of individual users (and more important, the programs they run). MLS is by far the most implemented MAC mechanism to date and is still prevalent in several niche operating systems. MAC mechanisms similar to MLS have also been contemplated and built, all of which share a common theme of implementing a small number of fixed security properties. The primary weakness of MLS is the fact that it implements a single security goal (that is, protecting the confidentiality of sensitive data using the model of government classified documents) in a strict, inflexible manner. Not all operating system security concerns are related to data confidentiality, and of those that are, most are not amenable to the rigid and simple model of classified government documents (including many, if not most, government systems dealing with classified data). To expand upon this goal in MLS (and similar MAC mechanisms), subjects must be given privilege to work outside the security policy (that is, violating the principle of nonbypassability) and trusted not to violate the intent of the policy. This inflexibility and narrow focus has kept MLS and similar MAC mechanisms from achieving broad appeal. 1.2.4. A Better Form of Mandatory Access ControlSELinux implements a flexible MAC mechanism called type enforcement (TE). As you will see, type enforcement provides strong mandatory security in a form that is adaptable to a large variety of security goals, concurrently. Type enforcement provides a means to control access down to the individual program level, in a manner that allows an organization to define a security policy appropriate for their systems. In type enforcement, all subjects and objects have a type identifier associated with them. To access an object, the subject's type must be authorized for the object's type, regardless of the user identity of the subject. What makes the SELinux approach superior to a straight MLS solution is that the rules governing type-based access control are not predefined nor hard-coded in the kernel. By default, SELinux allows no access. An organization can develop any number of rules specifying what is allowed, making SELinux adaptable to a wide variety of security policies. The collection of rules that determine allowed access for a system is called an SELinux policy. Physically, an SELinux policy is a special file that contains all the rules that the SELinux kernel will enforce. The policy file is compiled from a set of source files. As you will see, SELinux policies can vary from system to system. During the boot process, the policy is loaded into the kernel, where it is then used as the basis for access control decisions. Note The term policy is greatly overloaded in the computer security field. Throughout this chapter, we use the term to refer to general definitions of an organization security goals and objectives. However, SELinux also uses policy to refer to the set of rules (and the file that contains them) that are loaded into the kernel for access enforcement. We try to avoid confusion by limiting the overloading use of this word (although we cannot completely avoid this problem). Where its use is ambiguous, we explicitly write SELinux policy to avoid confusion. SELinux brings flexible type enforcement along with a form of role-based access control and the optional addition of traditional MLS to Linux. This flexible and adaptable MAC security, built in to the mainstream Linux operating system, is what makes SELinux such a promising technology for improved security. 1.2.5. The Evolution of SELinuxSELinux has its origins in high-assurance operating system security and microkernel research from the 1980s. These two research threads came together in a project called Distribute Trusted Mach (DTMach), which merged the experiences of earlier research projects (LOCK, which involved a form of type enforcement in a high-assurance security kernel; and Trusted Mach, which incorporated multilevel security controls into the Mach microkernel). The U.S. National Security Agency's research organization participated in the DTMach effort and continued its participation through a number of subsequent secure microkernel projects. This work eventually resulted in a new security architecture, called Flask, that supported a more flexible and dynamic type of enforcement mechanism.[6]
The various platforms upon which this work was performed were research microkernels not in wide market use. The NSA recognized a need to expose this technology to a broader community in hopes of demonstrating its viability and gaining broader support for its use. In the summer of 1999, the NSA began to implement the Flask security architecture in the Linux kernel. In December 2000, the NSA made its first public release of this work, called Security Enhanced Linux. Being implemented in a popular mainstream operating system, SELinux started to attract the attention of the Linux community. SELinux was originally released as a collection of kernel patches for the 2.2.x kernel. Following the 2001 Linux Kernel Summit in Ottawa, Canada, the Linux Security Module (LSM) [7] project was started to create a flexible framework for the Linux kernel that allowed different security extensions to be added to Linux. The NSA and the SELinux community were major contributors to this effort, with SELinux helping to drive many of the requirements for LSM. Concurrent with the LSM effort, NSA started to adapt SELinux to use the LSM framework. The core LSM features were integrated into the mainline Linux kernel starting in August 2002, and were incorporated into the Linux 2.6 kernel. By August 2003, the NSA, with growing open source community help, had completed its migration of SELinux to the LSM framework, resulting in the inclusion of SELinux in the main Linux 2.6 kernel. SELinux had become a fully functional LSM module included in the core Linux code set.
Several Linux distributions began using the SELinux features in the 2.6 kernel to various degrees, but the primary effort to make SELinux ready for the enterprise was via the Red Hat-sponsored Fedora Core project. The NSA and Red Hat started a joint effort to integrate SELinux as part of the mainstream Fedora Core Linux distribution. Prior to Red Hat's interest, SELinux was always an add-on set of packages that required significant expertise to integrate. Red Had took the initiative (and business risks) to make SELinux a part of a mainstream distribution, complete with modified user-space tools and services and enhanced security enabled by default. Starting with Fedora Core 2 and continuing with Fedora Core 3, SELinux and its supporting infrastructure and tools were improved for mainstream use. In early 2005, Red Hat released its Enterprise Linux version 4 (REL4) with SELinux as a fully enabled by default security enhancement. SELinux and mandatory access control had reached the mainstream operating system market at last. SELinux is still a relatively new and complex technology, and significant research and development is continuing to improve its utility. We discuss much of these emerging developments throughout this book. |
EAN: 2147483647
Pages: 154