- 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
2.4 Multilevel Security in SELinux
Type enforcement is far and away the most important mandatory access control (MAC) mechanism that SELinux introduces. However, in some situations, primarily for a subset of classified government applications, traditional multilevel security (MLS) MAC coupled with type enforcement is valuable. In recognition of these situations, SELinux has always had some form of MLS capability included. The MLS features are optional and generally the less important of the two MAC mechanisms in SELinux. For the vast majority of security applications, including many if not most classified data applications, type enforcement is the best-suited mechanism for enhanced security. Nonetheless, the addition of MLS enhances security for some applications.
The basic concept of MLS was introduced in Chapter 1, "Background" actual implementations of MLS are more involved. The security level used by MLS systems is a combination of a hierarchical sensitivity and a set (including the null set) of nonhierarchical categories. These sensitivities and categories are used to reflect real information confidentiality or user clearances. In most SELinux policies, the sensitivities (s0, s1, ...) and categories (c0, c1, ...) are given generic names, leaving it to userspace programs and libraries to assign user-meaningful names. (For example, s0 might be associated with UNCLASSIFIED and s1 with SECRET.)
To support MLS, the security context is extended to include security levels as such these:
user:role:type:sensitivity[:category,...][-sensitivity[:category,...]]
Notice that the MLS security context must have at least one security level (which is composed of a single sensitivity and zero or more categories), but can include two security levels. These two security levels are called low (or current for processes) and high (or clearance for processes), respectively. If the high security level is missing, it is considered to be the same value as the low (the most common situation). In practice, the low and high security levels are usually the same for most objects and processes. A range of levels is typically used for processes that are considered trusted subjects (that is, a process trusted with the ability to downgrade information) or multilevel objects such as directories that might contain objects of differing security levels. For purposes of this overview, assume that all processes and objects have a single security level.
The MLS rules for accessing objects are much the same as discussed in Chapter 1, except that security levels are not hierarchical but rather governed by a dominance relationship. Unlike equality where a level is either higher than, equal to, or lower than another level, in a dominance relationship, there is a fourth state called incomparable (also known as noncomparable; see the definition of incomp in the following list). What causes security levels to be related via dominance rather than equality are the categories, which have no hierarchical relationship to one another. As a result, the four dominance operators that can relate two MLS security levels are as follows:
|
dom: |
(dominates) SL1 dom SL2 if the sensitivity of SL1 is higher or equal to the sensitivity of SL2, and the categories of SL1 are a superset of the categories of SL2. |
|
domby: |
(dominated by) SL1 domby SL2 if the sensitivity of SL1 is lower than or equal to the sensitivity of SL2, and the categories of SL1 are a subset of the categories of SL2. |
|
eq: |
(equals) SL1 eq SL2 if the sensitivity of SL1 and SL2 are equal, and the categories of SL1 and SL2 are the same set. |
|
incomp: |
(incomparable or noncomparable) SL1 incomp SL2 if the categories of SL1 and SL2 cannot be compared (that is, neither is a subset of the other). |
Given the domain relationship, a variation of the Bell-La Padula model is implemented in SELinux where a process can "read" an object if its current security level dominates the security level of the object, and "write" an object if its current security level is dominated by the security level of the object (and therefore read and write the object only if the two security levels are equal).
The MLS constraints in SELinux are in addition to the TE rules. If MLS is enabled, both checks must pass (in addition to standard Linux access control) for access to be granted. Chapter 8, "Multilevel Security," discusses the SELinux optional MLS features.