SELinux policy modules can contain file context definitions through their .fc files. In these files, path expressions are used to point to the various locations that should match a particular file context, and class identifiers are used to differentiate file context definitions based on the file class (directories, regular files, symbolic links, and more).

In this recipe, we'll create a mylogging SELinux module, which defines additional path specifications for logging-related contexts. We will use direct file paths as well as regular expressions, and take a look at the various class identifiers.

Sometimes, applications and their resources get installed at different locations than expected by the SELinux policy. Trying to accommodate this by defining additional context definitions for each and every subdirectory can easily become unmanageable.

To help administrators, the SELinux utilities support substitution entries, which tell SELinux "if a path starts with this, then label it as if it starts with that". Administrators can set such a substitution (which is called an equivalence class) using semanage, as follows:

~# semanage fcontext –a –e / /mnt/chroots/bind

In this example, any location under /mnt/chroots/bind/ will be labeled as if it started from the main / directory (so /mnt/chroots/bind/etc/ becomes etc_t as /etc/ is etc_t).

Target locations for chroots are a good use case for this. A chroot is an alternate location on the filesystem, which will act as the root filesystem for one or a set of applications.

For administrators...

Up until now, we've only handled the configuration part on file contexts: if we would ask SELinux utilities to relabel files, then the changes we made would come into effect. However, unless you run with the restorecond daemon checking out all possible file modifications (which would really be a resource hog) or run restorecon manually against all files regularly, the newly defined contexts will not be applied to the files.

What we need to do is modify the local SELinux policy so that, upon creation of these files, the Linux kernel automatically assigns the right label to those files. This is handled through file transitions, which is a specific case of a type transition.

In a type transition, we configure a policy so that if a given domain creates a file (or other resource class) inside a directory with a specified label, then the created object should automatically get a specific label. Policy-wise, this is written as follows:

type_transition...

When an SELinux policy is MLS-enabled and supports multiple sensitivities (which is not the case with MCS, as MCS only has a single sensitivity), then SELinux can govern information flow and access between a domain and one or more resources based on the clearance of the domain and the sensitivity level of the resource. But even with a single sensitivity (as is the case with MCS), SELinux has additional constraint support to ensure that domains cannot access resources that have one of the categories assigned that the domain doesn't have clearance for.

A sensitivity level consists of a sensitivity (s0 is generally being used for the lowest sensitivity and s15—which is a policy build-time constant and thus can be configured—is the highest sensitivity) together with a category set (which can be a list such as c0,c5,c8.c10).

A security clearance is similar to a sensitivity level but shows a sensitivity range (such as s0-s3) instead of a single...