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

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.

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.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.