Category list

Section 1.3. Summary

1.3. Summary

Application software is flawed and will remain flawed for the foreseeable future. Nonetheless, we must find ways to create secure systems despite these inevitable flaws. Real security cannot be achieved without better underlying operating system security. The goal of SELinux is to provide this improved security in a mainstream operating system (that is, Linux).
The reference monitor concept is a common means of describing access control in operating systems. In a reference monitor, resources are encapsulated into distinct objects, and accesses between subjects (that is, processes) and objects are mediated by the reference validation mechanism according to the system security policy.
Operating systems have two forms of access control: discretionary access control (DAC) and mandatory access control (MAC). Standard Linux security is a form of DAC. SELinux adds a flexible, configurable MAC to Linux.
DAC has a fundamental weakness in that it is subject to a variety of malicious software attacks. MAC is a way to avoid these weaknesses. Most MAC features implemented so far are a form of multilevel security modeled after governmental classification controls.
SELinux implements a more flexible form of MAC called type enforcement and an optional form of multilevel security.

Exercises

1.	Set up an SELinux system and install the strict example policy using the instructions in Appendix A, "Obtaining SELinux Sample Policies."

Chapter 2. Concepts

In this chapter

2.1 Security Contexts for Type Enforcement
2.2 Type Enforcement Access Control
2.3 The Role of Roles
2.4 Multilevel Security in SELinux
2.5 SELinux Features Familiarization
2.6 Summary
Exercises

page 16

page 19

page 29

page 31

page 32

page 36

page 37

The details of the SELinux access control mechanism and policy language are extensive and fully described in later chapters. However, the basic concepts and goals of SELinux are fairly simple. In this chapter, we examine the security concepts of SELinux and the motivations behind these concepts. Gaining a conceptual understanding is necessary to effectively use and apply SELinux access controls. This chapter focuses on the primary access control feature of SELinux, type enforcement (TE), although we also briefly discuss the optional multilevel security mechanism.

2.1. Security Contexts for Type Enforcement

All operating system access control is based on some type of access control attribute associated with objects and subjects. In SELinux, the access control attribute is called a security context . All objects (files, interprocess communication channels, sockets, network hosts , and so on) and subjects (processes) have a single security context associated with them. A security context has three elements: user , role, and type identifiers. The usual format for specifying or displaying a security context is as follows :

user:role:type

The string identifiers for each element are defined in the SELinux policy language, which we discuss in greater detail later. For now, just understand that a valid security context must have one valid user, role, and type identifier, and that the identifiers are defined by the policy writer. The namespaces for each identifier are orthogonal. (So, for example, it is possible, but not usually advisable, to have the same string identifier for a user, a role, and a type.)

Examining Security Contexts

SELinux modifies many system commands by adding the -Z option to display the security contexts of objects and subjects. For example, ls -Z shows the security contexts of file system objects and ps -Z shows the security contexts of processes. Another useful command is id , which shows the security context of your shell (that is, your current user, role, and type). The following, for example, shows the security context of a shell on a running SELinux system:

$

id -Z

joe:user_r:user_t

You can use these commands to explore your own SELinux system as we walk through the examples in this chapter.

2.1.1. Comparing SELinux with Standard Linux

At this point, it is useful to compare the access control attributes on standard Linux with those of SELinux. For simplicity, we stick to common filesystem objects such as files and directories. In standard Linux, the access control attributes of subjects are the real and effective user and group IDs associated with all processes via the process structure in the kernel. These attributes are protected by the kernel and set via a number of controlled means, including the login process and setuid programs. For objects (for example, files), the inode of the file contains a set of access mode bits and file user and group IDs. The former controls access based on three sets of read/write/execute bits, one each for file owner, file group, and everyone else. The latter determines the file owner and group to decide which set of bits to use on a given access attempt.

As noted, in SELinux, the access control attributes are always the security context triple. All objects and subjects have an associated security context. Where standard Linux uses the process user/group IDs, the file's access mode, and the file user/group IDs to grant or deny access, SELinux uses the security contexts of a process and the object the process accesses . More specifically , because the primary access control feature of SELinux is type enforcement, the type identifier from the security context is used to determine access.

Note

SELinux adds type enforcement to standard Linux. This means that both the standard Linux and enhanced SELinux access controls must be satisfied to access an object. So, for example, if we have SELinux write access to a file but we do not have w permission on the file, we cannot write the file.

Table 2-1 summarizes the comparison of standard Linux and the added SELinux security attributes and access control.

Table 2-1. Comparison of Standard Linux and Security-Enhanced Linux Access Control

	Standard Linux	SELinux Added
Process security attributes	Real and effective user and group IDs	Security context
Object security attributes	Access modes and file user and group IDs	Security context
Basis for access control	Process user/group ID and file's access modes based on file's user/ group ID	Permissions allowed between process type and file type

2.1.2. More on Security Contexts

The security context is a simple, consistent access control attribute. In SELinux, the type identifier is the primary part of the security context that determines access. For historical reasons, the type of a process is often called a domain . The use of "domain" and "domain type" to mean the type of a process is so common and pervasive that we do not attempt to avoid using the term domain . In general, consider domain, domain type, subject type, and process type to be synonymous.

The user and role identifiers in a security context have little impact in the access control policy for type enforcement except for constraint enforcement, which we discuss in Chapter 7, "Constraints." For processes, user and role identifiers are more interesting because they are used to control the association of types with user identifiers and thus with Linux user accounts (more on this later). For objects, however, user and role identifiers have nearly no use. As a convention, the role of an object is usually object_r , and the user of an object is usually the user identifier of the process that created the object. They have no effect on access control.

Finally, be aware of the differences between the user ID in standard Linux security and the user identifier in a security context. Technically, these are completely orthogonal identifiers, used separately by the standard and security-enhanced access control mechanisms, respectively. Any relationship between these two is strictly provided via the login process according to conventions not directly enforced by the SELinux policy.

Buy on amazon.com >>

Mayer F., MacMillan K., Caplan D.

<< Previous page

Table of contents

Next page >>