Section 8.2. Security Contexts with MLS

8.2. Security Contexts with MLS

As discussed in Chapter 2 "Concepts," when MLS is enabled, the security context is extended with two additional fields: a low and high security level. A security level itself has two fields: a sensitivity and a set of categories. Sensitivities are strictly hierarchical reflecting an ordered data sensitivity model, such as Top Secret, Secret, and Unclassified in government classification controls. Categories are unordered, reflecting the need for data compartmentalization. The basic idea is that you need both a high enough sensitivity clearance and the right categories to access data.

Warning

Do not confuse security level with sensitivity. A security level is a combination of a single sensitivity and a set (zero or more) of categories. Sensitivities are strictly hierarchical and can be compared using equivalence relationships (<, =, >). Security levels are not hierarchical and are compared using a dominance relationship (dom, domby, eq, incomp), which we briefly discuss in Chapter 2.

8.2.1. Defining Security Levels

In an SELinux policy, you define sensitivities using the sensitivity statement, as follows:

sensitivity s0; sensitivity s1; sensitivity s2; sensitivity s3;

These statements define four sensitivities called s0, s1, s2, and s3. These names are a typical generic sensitivity naming convention in SELinux. We could use any name you want here. The sensitivity statement also supports the ability to associate additional alias names with a sensitivity that will be treated the same as the core sensitivity name. For example:

sensitivity s1 alias unclassified;

Note

Recent improvement to SELinux, included in FC5, has added the utility semanage, which among other features enables you to assign human-readable (and printable) names to the policy sensitivities and categories. These human-readable names are translated by an SELinux library and are not part of the kernel policy enforcement language. The file that contains the printable mappings is /etc/selinux/[policy]/setrans.conf, where [policy] is an installed policy.

Because sensitivities must be hierarchically related, we must specify in the policy the hierarchy of sensitivities using the dominance statement, as follows:

dominance { s0 s1 s2 s3 }   # s0 is "low" and s3 "high"

The dominance statement lists the sensitivity names in order from lower to highest. Thus, in our example, s0 is lower than s1, which is lower than s2, and so forth.

Warning

The absence of an ending semicolon in the dominance statement is the correct syntax (even though most other policy statements end with a semicolon). In this case, the closing curly brace unambiguously denotes the end of the statement. It is one of those legacy-language design decisions that you have to keep in mind.

Categories are defined in a similar manner as sensitivities using the category statement. As with sensitivities, categories may also have alias names. Unlike sensitivities, categories are not hierarchically related (or related at all). So, there is no need to define any explicit relationship between categories. The following statements are examples of the category statement:

category c0 alias blue; category c1 alias red; category c2 alias green; category c3 alias orange; category c4 alias white;

The final step in defining security levels in the policy language is to define allowed security level combinations using the level statement. The level statement dictates how you may associate categories with sensitivities. Remember that a combination of a single sensitivity and a set of categories constitute a security level. Here are some examples of the level statement:

level s0:c0.c4; level s1:c0.c4; level s2:c0.c4; level s3:c0.c4;

These statements enable you to combine any of the defined categories with all the defined sensitivities from our earlier examples. You would generally have a single level statement for each defined sensitivity that identifies the categories that may be associated with each sensitivity in a valid security level.

In the preceding example, we associated all five defined categories (c0.c4) with all four defined sensitivities. You can be more restrictive in this association:

level s0:c0.c2; level s1:c0.c2,c4;

In this example, s0 may be associated only with categories c0, c1, and c2; and s1 with categories c0, c1, c2 and c4 (but not c3). By now, you should have noticed that a dot (.) indicates an inclusive range of categories, and a comma (,) indicates a noncontiguous list of categories.

Warning

Just because ranges of categories are specified using the range operator (.), this does not mean that categories are hierarchically related. Instead, the range operator is just a convenient way to refer to a set of categories. The ordering of the categories for the range operator is just the order in which they are declared and has nothing to do with any intrinsic ordering implied by their names.

So, for example, if you declare that categories in the order c1, c0, and c2, the expressions c0.c2 would mean c0 and c2, and not c1.

The level statement defines what combinations of sensitivities and categories constitute an acceptable security level for the MLS portion of the SELinux policy.

Security Level Statements Syntaxes

There are four statements that together enable you to define security levels in an SELinux policy. The full syntax of each are listed in this sidebar.

Sensitivity statement

This statement defines the policy sensitivity identifiers and optional alias identifiers.

sensitivity identifier [ alias alias_id [alias_id(s)] ] ;

identifier	String identifier for sensitivity.
alias_id	One or more additional string identifiers for sensitivity aliases.

The sensitivity identifier and associated alias identifiers can be used interchangeably within the policy.

Dominance statement

This statement defines the hierarchical relationship between all defined sensitivities:

dominance { identifier  identifier ...  identifier }

identifier

A sensitivity identifier defined by a sensitivity statement.

The ordering of sensitivities is from lower to highest. All defined sensitivities must be contained within the dominance statement in order to define the complete sensitivity hierarchy.

Category statement

This statement defines the policy category identifiers and optional alias identifiers:

category identifier [ alias alias_id [alias_id(s)] ] ;

identifier	String identifier for category.
alias_id	One or more additional string identifiers for category aliases.

The category identifier and associated alias identifiers can be used interchangeably within the policy.

Level statement

This statement defines the allowed combinations of sensitivity and category sets:

level sensitivity[:category_set] ;

sensitivity

One of the defined sensitivity identifiers.

category_set

A set of defined category identifiers. Categories can be listed as comma-separated lists and/or ranges of categories using the . range operator. For example, the category set c0.c3,c5 means all defined categories from c0 to c3 inclusively, plus c5. Note that there is no implicit ordering of categories according to name (for example, alphanumeric ordering); instead, the range operator uses the order in which the category identifiers are defined.

You may use only one level statement for each defined sensitivity. The category set is optional; an unspecified category set means the "empty" category set. (That is, that sensitivity may have no categories associated with it.) A valid security context may associate only a sensitivity with the categories defined in the level statement for that sensitivity.

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

8.2.2. MLS Extensions to Security Contexts

For MLS SELinux systems, the security context is extended to include two security levels: a low or current security level and a high or clearance security level. In general, the low level reflects the current security level of a process or the sensitivity of data contained within an object. The high level reflects the clearance level of the user identifier in the context (thereby determining the highest possible security level allowed for the current level of any security context) or the maximum range of data allowed for some so-called multilevel objects. When MLS is enabled, the extended security context has the following format:

user:role:type:sensitivity[:category,...][-sensitivity[:category,...]]

Notice that the security levels require a single sensitivity and zero or more categories (that is, categories are optional). In addition, when you specify a security context you need not specify the high level. If unspecified, the high level will be equal to the low level, which is a common case for objects.

For a security context to be valid, the high level must always dominate^[1] the low level. In addition, the categories associated with the sensitivities must be valid per the level statements in the policy. So, for example, if we have the previous level statements:

^[1] Recall from Chapter 2 that security levels are related using the "dominance" relationship. We discuss this relationship later in this chapter.

level s0:c0.c2; level s1:c0.c2,c4;

and user_u, user_r, and user_t are valid user, role, and type identifiers, the following security contexts are invalid:

user_u:user_r:user_t:s0-s0:c2,c4 (c4 is invalid for s0) user_u:user_r:user_t:s0:c0-s0:c2 (high does not dominate the low)