SELinux Concepts
- Security Contexts for Type Enforcement
- Type Enforcement Access Control
- The Role of Roles
- Multilevel Security in SELinux
- SELinux Features Familiarization
- Summary
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
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
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.)
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.
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.