Paranoid Penguin - Introduction to SELinux, Part II

In my last column, we began exploring the concepts, terms and theory behind Security-Enhanced Linux (SELinux). This month, we conclude our overview, ending with a description of the SELinux implementation in Red Hat Enterprise Linux, Fedora and CentOS.

As much as I'd like to dive right in with the new material, SELinux is one of the most complex topics I've tackled in this column, so some review is in order. Rather than simply summarizing last month's column, however, here's a list of SELinux terms:

As I mentioned last time, Type Enforcement is the most important of the three security models implemented in SELinux. In fact, in the Red Hat Enterprise Linux (RHEL) targeted policy, which I cover at length later in this article, Type Enforcement is the only SELinux security model used.

As important as Type Enforcement is, it's a very process-oriented model. It's most useful for “sandboxing” or isolating dæmons. But, what about actual human users, who may perform a variety of tasks on the system and, therefore, may need to traverse multiple domains?

SELinux's Role-Based Access Control (RBAC) model concerns the ways in which users may transition between the roles they're authorized to assume and, by extension, between the domains in which those roles have rights. In practical terms, such a transition occurs when a process running from within one domain spawns a process into a different domain.

For example, suppose user Mick is authorized to operate in the role Parent, which in turn is associated with the domains Supper and Bedtime. In order for Mick to transition from Supper to Bedtime (for example, to start a shell session in the Bedtime domain, with access to files and processes authorized for that domain but not for the Supper domain), an RBAC rule must explicitly allow the role Parent to transition from Supper to Bedtime. This is in addition to, not instead of, the need for Parent to be defined in security contexts for those two domains.

The third security model in SELinux is Multi-Level Security (MLS). MLS is in turn based on the Bell-LaPadula model for data labeling. The guiding principle of both the Bell-LaPadula model and MLS is “no read up, no write down”. That is to say, a process (user) authorized to read data of one classification may not read data of a higher (more sensitive) classification, nor may that process (user) write data of a given classification anyplace in which it might be accessed by processes (users) authorized only to view data of lower (less sensitive) classifications.

For this model to work, each subject on the system must be associated with a security clearance—that is to say, the maximum sensitivity of data to which that subject may have access. Every file (object) also must be labeled with a classification that specifies the minimum clearance a subject must have in order to access it. The MLS Range field, supported in SELinux since Linux kernel 2.6.12, provides this information in the security contexts of both subjects and objects.

The traditional four data security classifications are, in decreasing order of sensitivity, Top Secret, Secret, Confidential and Unclassified. However, in MLS, many more such hierarchical classifications can be defined in your security policy. Also, each hierarchical classification can be associated with non-hierarchical compartments, which you can use to enforce a need-to-know policy in which subjects authorized at a given classification level may be granted access only to objects associated with specific compartments within that classification.

For example, suppose the process hamburgerd has overall subject clearance of Secret, and specific clearance (within the Secret classification) to the compartments ingredients and handshakes; such a clearance might be notated as { Secret / ingredients, handshakes }. If the file high_sign has an object clearance of { Secret / handshakes }, hamburgerd will be permitted to read it.

Note that by “non-hierarchical”, I mean that compartments within the same classification are peers to each other. If I define two compartments, apples and oranges under the classification Classified, neither compartment is considered more sensitive than the other. However, any compartment associated with the Secret or Top Secret classification will be considered more sensitive than either { Confidential / apples } or { Confidential / oranges }.