Section 8.3. MLS Constraints

8.3. MLS Constraints

SELinux supports two MLS constraint statements, mlsconstrain and mlsvalidatetrans, which together enable us to specify the optional MLS access enforcement rules. These two statements are identical to their non-MLS counterparts except that they allow you to also express constraints based on the security levels of a security context. You may only use the MLS constraints in policies that have the optional MLS features enabled. You may use the non-MLS constraint statements from Chapter 7, "Constraints," in either type of policy.

8.3.1. mlsconstrain Statement

The mlsconstrain statement is based on the constrain statement. We can use any of the syntax discussed for the constrain statement in Chapter 7. The mlsconstrain statement adds new keywords for stating constraints based on the low and high security levels of the source (l1 and h1) and target (l2 and H2). The sidebar on page 171 contains the full syntax for the mlsconstrain statement.

mlsconstrain Statement Syntax

The mlsconstrain statement allows you to restrict specified permissions for specified object classes by defining constraints based on relationships between source and target security contexts that include the optional MLS features (that is, high and low security levels). The full syntax for the mlsconstrain statement is as follows:

mlsconstrain class_set perm_set expression ;

class_set	One or more object classes. Multiple object classes must be separated by spaces and enclosed in braces ({ })for example, {file lnk_file}. The special operators *, ~, and - are not allowed in class sets for this statement.
perm_set	One or more permissions. All permissions must be valid for all object classes in the class_set. Multiple permissions must be separated by spaces and enclosed in braces ({ })for example, {read create}. The special operators *, ~, and - are not allowed in class sets for this statement.
expression	A Boolean expression of the constraint.

The Boolean expression syntax supports the following keywords:

t1, r1, u1, l1, h1	Source type, role, user, low level, and high level, respectively
t2, r2, u2, l2, H2	Target type, role, user, low level, and high level, respectively

Constraint expression syntax also supports the following operators:

==	Set member of or equivalent.
!=	Set not member of or not equivalent.
eq	(Roles and security level keywords only) equivalent.
dom	(Roles and security level keywords only) dominates.
domby	(Role and security level keywords only) not dominated by.
incomp	(Role and security level keywords only) incomparable.

The complete semantic meaning and allowed parameters for each operator is described in Table 8-1along with those defined for the constrain statementChapter 7 (Table 7-1).

The mlsconstrain statement is supported only for optional MLS policies.

The mlsconstrain statement is valid only in monolithic policies and base loadable modules. It is not valid in conditional statements and non-base loadable modules.

To illustrate the mlsconstrain statement, let's look at applying MLS to ordinary filesystem objects. As a simple constraint suppose that we want to ensure that file objects may have only a single level. (That is, the high and low levels must be the same.) We can accomplish this restriction with a constraint such as this:

mlsconstrain file { create relabelto }          ( l2 eq h2 );

Assuming that create and relabelto are the file permissions required to set the security level of a file object, this constraint is sufficient to require that all files have high and low security levels that are the same.

Let's now look at more central MLS policy restrictions. Recall the basic premise of MLS from Chapter 2, namely to prevent information from flowing "downward" from higher security levels to lower or incomparable security levels. We do this by enforcing the "no read up, no write down" rules on all objects. In SELinux, the low security level generally represents the current security level of processes and objects. Thus, we have the following MLS constraint for files:

mlsconstrain file write ( l1 domby l2 );

In this statement we constrain write permissions for the file object class requiring the source security level (l1) to be dominated by ("lower than") the object security level (l2). In other words, a process can write files only at or "above" its current security level ("no write down").

This constraint is unfortunately too simple to ensure that MLS policy is enforced for file objects. First, let's consider file object class permissions. Many permissions other than write allow a process to "write" information to a file. For example, the append permission also allows information to flow from the process to the file. Likewise, less obvious permissions, such as rename, also allow some form of information to flow to the file (in this case, the name of the file). To be comprehensive, we need to expand our constraint to cover all "write-capable" file permissions:

mlsconstrain file { write create setattr relabelfrom append                                       unlink link rename mounton }         ( l1 domby l2 );

We now include a list of several permissions besides the standard write permission, all of which allow some form of information to flow from the source to the object. The constraint expression remains the same.

This constraint is still too simple. We need to address the situation where we have a trusted domain type that we need to give special permission to violate the "no write down" rule. Although you should avoid such trusted domains, nearly all applications of MLS systems have had a need for them. To accommodate this concept, we need to expand the constraint to allow for these trusted domains.

To implement trusted downgrading domains, we can create a type attribute, say mlsfilewritedown, which identifies any such trusted domain. So now our constraint is this:

mlsconstrain file { write create setattr relabelfrom append                                      unlink link rename mounton }         ( ( l1 domby l2 ) or         ( t1 == mlsfilewritedown ) );

Now the constraint allows an exception for any source domain (t1) that has the mlsfilewritedown attribute (that is, trusted domains).

For a complete MLS policy, we also need to also restrict read access (that is, "no read up"). As with write access, a number of permissions allow "read" access besides the read permission. For example execute permissions essentially allows a process to "read" the contents of an executable file. Here is a possible MLS read constraint for file objects:

mlsconstrain  file  { read getattr execute }         ( ( l1 dom l2 ) or           ( t1 == mlsfilewritedown ) );

As with the write restriction we have an attribute, mlsfilereadup, that allows for "read up" privilege for those few privileged domain types that have the attribute.

In writing a complete MLS policy, you need to examine all object classes and their associated permissions to ensure read and write restrictions are properly constrained. For example, in the preceding "read" constraint, we might want to address all filesystem objects in a single statement, as follows:

mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file }                 { read getattr execute }         ( ( l1 dom l2 ) or           ( t1 == mlsfilereadup ) );

You will typically find the MLS constraints for a given SELinux policy stated in a single source policy file, typically called mls. We do not extensively cover MLS features of SELinux outside of this chapter; if you are interested in additional information, find this file and examine it.

Table 8-1. Allowed Arguments and Semantic Meaning for Mlsconstrain Expressions (Plus Those Defined for the Contrain Statement in Table 7-1 [Chapter 7])

Operator	Left Side	Right Side	Semantic Meaning
==	l1	l2,H1,H2	Source's low (current) security level equals the target's low (l2), source's high (h1), or target's high (H2) security level.
	l2	h2	Target's low (current) security level equals the target's high security level.
	h1	l2,h2	Source's high (clearance) security level equals the target's low (l2) or high (h2) security level.
!=	l1	l2, h1, H2	Source's low (current) security level does not equal the target's low (l2), source's high (H1), or target's high (h2) security level.
	l2	H2	Target's low (current) security level does not equal the target's high security level.
	h1	l2,h2	Source's high (clearance) security level does not equal the target's low (l2) or high (h2) security level.
eq	l1	l2, H1, H2	Exactly the same semantics as ==.
	l2	h2	Exactly the same semantics as ==.
	H1	l2, h2	Exactly the same semantics as ==.
dom	l1	l2, H1, H2	Source's low (current) security level dominates the target's low (l2), source's high (H1), or target's high (H2) security level.
	l2	H2	Target's low (current) security level dominates the target's high security level.
	H1	l2, h2	Source's high (clearance) security level dominates the target's low (l2) or high (h2) security level.
domby	l1	l2, H1, h2	Source's low (current) security level is dominated by the target's low (l2), source's high (H1), or target's high (h2) security level.
	l2	h2	Target's low (current) security level is dominated by the target's high security level.
	h1	l2, H2	Source's high (clearance) security level is dominated by the target's low (l2) or high (h2) security level.
incomp	l1	l2, h1, h2	Neither the source's low (current) security level nor the target's low (l2), source's high (h1), or target's high (h2) security level dominate the other.
	l2	H2	Neither the target's low (current) security level nor the target's high security level dominate the other.
	H1	l2, h2	Neither the source's high (clearance) security level nor the target's low (l2) or high (H2) security level dominate the other.

8.3.2. mlsvalidatetrans Statement

We have one more MLS constraint we need to examine, the MLS variant of the validatetrans constraint discussed in Chapter 7, namely mlsvalidatetrans. This statement is similar to the validatetrans statement except that it introduces the six keywords l1 and h1, l2 and h2, and l3 and h3, meaning old low and high security levels, new low and high security levels, and the source process low and high security levels, respectively. The other difference between the two statements is that the mlsvalidatetrans statement is more commonly used to support an MLS policy than the validatetrans statement is in a typical TE policy. The full syntax of the mlsvalidatetrans statement is in the sidebar on page 176.

mlsvalidatetrans Statement Syntax

The mlsvalidatetrans statement restricts the ability to change the security context of specified supported objects by defining constraints-based relationships with old and new security contexts and the security context of the source process. The full syntax for the mlsvalidatetrans statement is as follows:

mlsvalidatetrans class_set expression ;

class_set	One or more object supported classes. Multiple object classes must be enclosed in braces ({ })for example, {file lnk_file}. Currently, only permanent filesystem object classes are supported.
expression	A Boolean expression of the constraint.

The Boolean expression syntax supports the following keywords:

t1, r1, u1, l1, h1	Old type, role, user, low level, and high level, respectively
t2, r2, u2, l2, h2	New type, role, and user, low level, and high level, respectively
t3, r3, u3, l3, h3	Process type, role, user, low level, and high level, respectively

The constraint expression syntax also supports the following operators:

==	Set member of or equivalent
!=	Set not member of or not equivalent
eq	(Roles and security level keywords only) equivalent
dom	(Roles and security level keywords only) dominates
domby	(Role and security level keywords only) not dominated by
incomp	(Role and security level keywords only) incomparable

The complete semantic meaning and allowed parameters for each operator is described in Table 8-2 in addition to those defined for the validatetrans statement in Chapter 7 (Table 7-2).

The mlsvalidatetrans statement is supported only for optional MLS policies.

The mlsvalidatetrans statement are valid only in monolithic policies and base loadable modules. They are not valid in conditional statements and non-base loadable modules.

As an example, for MLS we generally do not want file security levels to change; over the years of experimentation with operational MLS systems, however, we have learned that some MLS applications have evolved the need for a trustworthy application to change the security levels of existing objects such as files. So, to enforce this restriction while allowing for those trusted applications, we can use the mlsvalidatetrans constraint:

mlsvalidatetrans file      ( ( l1 eq l2 ) or        (( t3 == mlsfileupgrade ) and ( l1 domby l2 )) or        (( t3 == mlsfiledowngrade ) and ( l1 dom l2 or l1 incomp l2 )) );

This constraint has a number of features. First, it has the basic requirement that when a file object security context changes, its current (low) security level must be the same (l1 eq l2). However, it provides for upgrading (mlsfileupgrade attribute) and downgrading (mlsfiledowngrade attribute) privileges. Upgrading (that is, the old level l1 is dominated by the new level l2) is allowed if the process domain type has the mlsfileupgrade attribute. Likewise, downgrading (that is, the old level dominates or is incomparable to the new level) is allowed if the process domain type has the mlsfiledowngrade attribute.

Table 8-2. Allowed Arguments and Semantic Meaning for Mlsvalidatetrans Expressions (Plus Those Defined for the Validatetrans Statement in Table 7-2 [Chapter 7])

Operator	Left Side	Right Side	Semantic Meaning
==	l1	l2, h1,H2	Old low (current) security level equals the new low (l2), old high (h1), or new high (h2) security level.
	l2	h2	New low (current) security level equals the new high security level.
	h1	l2, H2	Old high (clearance) security level equals the new low (l2) or new high (H2) security level.
!=	l1	l2, H1, H2	Old low (current) security level does not equal the new low (l2), old high (H1), or new high (h2) security level.
!=	l2	H2	New the old low (current) security level does not equal the new high security level.
	H1	l2, H2	Old high (clearance) security level does not equal the new low (l2) or new high (h2) security level.
eq	l1	l2, h1, H2	Exactly the same semantics as ==.
	l2	h2	Exactly the same semantics as ==.
	h1	l2, H2	Exactly the same semantics as ==.
dom	l1	l2, H1, h2	Old low (current) security level dominates the new low (l2), old high (H1), or new high (h2) security level.
	l2	h2	New low (current) security level dominates the new high security level.
	h1	l2, H2	Old high (clearance) security level dominates the new low (l2) or new high (H2) security level.
domby	l1	l2, H1, H2	Old low (current) security level is dominated by the new low (l2), old high (h1), or new high (h2) security level.
	l2	h2	The new low (current) security level is dominated by the new high security level.
	h1	l2, h2	The old high (clearance) security level is dominated by the new low (l2) or new high (H2) security level.
incomp	l1	l2, H1, h2	Neither the old low (current) security level nor the new low (l2), old high (H1), or new high (h2) security level dominate the other.
	l2	h2	Neither the new low (current) security level nor the new high security level dominate the other.
	h1	l2, h2	Neither the old high (clearance) security level nor the new low (l2) or new high (h2) security level dominate the other.

Note

Remember that, as of this writing, validatetrans and mlsvalidatetrans constraint statements support only filesystem objects, specifically, dir, file, lnk_file, chr_file, blk_file, sock_file, and fifo_file object classes.