Section 7.3. Label Transition Constraints

7.3. Label Transition Constraints

SELinux supports a second constraint statement, validatetrans. This statement was added as part of the modified multilevel security features we discuss in the next chapter. With the validatetrans statement, we can further control the ability to change the security context of supported objects. As of this writing, the only supported objects for this constraint are the filesystem objects (file, directory, device files, and so on).

Unlike the constrain statement, the validatetrans statement allows you to relate the new and old security context of an object with each other and/or with a third security context, that of the process attempting to relabel the object. Thus, new keywords are added for this statement, specifically t3, r3, and u3, respectively representing the type, role, and user of the process security context. The *1 keywords represent the old security context, and the *2 keywords represent the new security context. The full syntax for this statement is available in the sidebar on page 157.

Warning

Be careful not to confuse the keyword associations between the constrain and validatetrans statements. For the constrain statement, t1 represents the source (or calling process) type, and t2 represents the target (object) type. However, in the validatetrans statement, t3 is now the source process type, t1 is the "old" type, and t2 is the "new" type.

Validatetrans Statement Syntax

The validatetrans 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 process. The full syntax for the validatetrans statement is as follows:

validatetrans class_set expression ;

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

The Boolean express syntax supports the following keywords:

t1, r1, u1	Old type, role, and user respectively
t2, r2, u2	New type, role, and user respectively
t3, r3, u3	Process type, role, and user respectively

Constraint expression syntax also supports the following operators:

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

The complete semantic meaning and allowed parameters for each operator is described in Table 7-2.

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

To date, we have seen no example use of the validatetrans constraint. This statement was added as the cousin to the multilevel security (MLS) variant described in Chapter 8, "Multilevel Security," on the future possibility of it being useful. To help understand how one might use this statement, let's look at example. The key feature of the validatetrans statement is that it enables us to associate old and new security contexts on a label change for file objects.

Suppose that we have a type user_tmp_t that in our policy we use as the type for ordinary untrusted user programs' temporary files. We might, for example, want to ensure that a domain with privilege to change all file labels (for example, a label maintenance program an administrator might run) does not accidentally relabel a file with user_tmp_t as its type to certain highly critical types (say shadow_t type, which is the type of the /etc/shadow file). Here's our constraint that would provide this restriction:

validatetrans {file lnk_file} ( t2 != shadow_t or t1 != user_tmp_t );

Notice several features of this constraint. First, notice that we included both ordinary files and symbolic links (lnk_file) because we do not want someone to use a link in place of a file. Now examine the constraint expressions. In simple language, the constraint says that for a security context change to be allowed for file and symbolic link objects, the new type may only be shadow_t if the old type is not user_tmp_t. In other words, no domain type may be authorized to relabel a user temporary file into the type of the shadow password file.

To expand this example, assume there are a subset of domain types that we do want to allow to relabel user_tmp_t to shadow_t. (It is hard to imagine a situation where this would be advisable, but you never know.) So, now we create an attribute relabel_any and assign it to those domain types we want to grant this privilege. We then expand this constraint as follows:

validatetrans {file lnk_file}         ( ( t3 == relabel_any) or           ( t2 != shadow_t or t1 != user_tmp_t ) );

Now we have a set of domain types (those with the relabel_any attribute) that this constraint will not restrict in any way.

Table 7-2. Allowed Arguments and Semantic Meaning for Validatetrans Expressions

Operator	Left Side	Right Side	Semantic Meaning
==	t1	t2	Old type equals new type.
	t1 (t2)	type and/or attribute name(s)	Old (new) type is a member of the set of types indicated by names.
	t3	type and/or attribute name(s)	Process type is a member of the set of types indicated by names.
	r1	r2	Old role equals new role.
	r1 (r2)	role name(s)	Old (new) role is a member of the set of roles indicated by names.
	r3	role name(s)	Process role is a member of the set of roles indicated by names.
	u1	u2	Old user equals new user.
	u1 (u2)	user name(s)	Old (new) user is a member of the set of users indicated by names.
	u3	user name(s)	Process user is a member of the set of users indicated by names.
!=	t1	t2	Old type does not equal new type.
	t1 (t2)	type and/or attribute name(s)	Old (new) type is not a member of the set of types indicated by names.
	t3	type and/or attribute name(s)	Process type is not a member of the set of types indicated by names.
	r1	r2	Old role does not equal new role.
	r1 (r2)	role name(s)	Old (new) role is not a member of the set of roles indicated by names.
	r3	role name(s)	Process role is not a member of the set of roles indicated by names.
	u1	u2	Old user does not equal new user.
	u1 (u2)	user name(s)	Old (new) user is not a member of the set of users indicated by names.
	u3	user name(s)	Process user is not a member of the set of users indicated by name.
eq	r1	r2	Exactly the same semantics as ==.
	r1 (r2)	role name(s)	Exactly the same semantics as ==.
dom	r1	r2	Source role was defined to dominate target role using role dominates statement.
domby	r1	r2	Target role was defined to dominate source role using role dominates statement.
incomp	r1	r2	Neither source nor target role dominates the other.