Paranoid Penguin - Introduction to SELinux, Part II

Understanding SELinux's security models is the first step in harnessing its power.

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:

  • Discretionary Access Controls (DACs): the underlying security model in Linux, in which every file and directory has three sets of access controls, known as permissions: one set each for user-owner, group-owner and other. These permissions can be changed arbitrarily, at the discretion of the file's or directory's owner

  • Mandatory Access Controls (MACs): a much stronger security model, of which SELinux is an implementation, in which access controls are preconfigured in a system security policy that generally does not allow system users or processes to set or change access controls (permissions) on the objects they own.

  • Subject: a process that initiates some action against some system resource.

  • Action: a system function (writing a file, executing a process, reading data from a socket and so on).

  • Object: any system resource (process, file, socket and so on) against which subjects may attempt actions.

  • User: in SELinux, an SELinux-specific user account is separate from underlying Linux user accounts and owns or initiates a subject process.

  • Role: analogous to Linux groups in that it represents a set of access controls that apply to a specific list of possible users. In SELinux, a user may be associated with multiple roles, but may assume (act within) only one role at a time.

  • Domain: a combination of subjects and objects permitted to interact with each other.

  • Type: synonymous with domain in SELinux.

  • Security context: the user, role and domain/type associated with a given subject or object.

  • Transition: when a process attempts to change from one role to another by spawning a new process that “runs as” the new role, or when a process attempts to create a new file or directory that belongs to a different role than its parent directory.

  • Type Enforcement: the security model in SELinux in which processes are confined to domains via security contexts.

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.

Role-Based Access Controls

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.

Multi-Level Security

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 }.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SELinux Simplified: Red Hat's Targeted Policy

rmlynch's picture

The section "SELinux Simplified: Red Hat's Targeted Policy" is maddeningly unspecific. I wish that in this section an otherwise clear article had explained matters at a sufficient depth for a reader to understand precisely what the targeted policy does and does not allow.


adosch's picture

Agreed, rmlynch. I suppose defaulting to "use the SELinux policy GUI" was fitting for the title of the article, "SELinux Simplified". You could have enlightened many readers and saved a few pages in the magazine by just posting the link to RedHat Enterprise SELinux Guide.