Paranoid Penguin - Introduction to SELinux, Part II

Understanding SELinux's security models is the first step in harnessing its power.
Multi-Category Security

I've referred to SELinux's three security models (TE, RBAC and MLS). In Red Hat Enterprise Linux 5, there's actually a fourth: Multi-Category Security (MCS).

As you might imagine, the combination of hierarchical classifications and non-hierarchical compartments makes MLS well suited to large bureaucracies, such as military organizations and intelligence agencies, but too complex for more general purposes. Red Hat has therefore implemented an alternative file-classification model in RHEL 5's implementation of SELinux: Multi-Category Security (MCS).

MCS uses SELinux's MLS Range field, essentially by ignoring the Classification field (assigning a classification of 0 to all subjects and objects) and instead acknowledging only the Compartment field. In this way, the power of data labeling is simplified to something more like the Linux DAC group functionality. In other words, MCS is similar to MLS, but lacks the added complexity of hierarchical classifications.

SELinux Simplified: Red Hat's Targeted Policy

Now that you understand SELinux's underlying security models and are familiar with at least a portion of SELinux's formidable body of jargon, we can turn our attention to SELinux's debut in the mainstream: Red Hat's targeted policy.

For many if not most system administrators, having to understand SELinux's various security models and complex terms, and managing its myriad configuration files, which may cumulatively contain hundreds or even thousands of lines of text, makes tackling SELinux a highly unattractive undertaking. To address this problem, Red Hat devised a simplified SELinux policy, called targeted, that emphasizes Type Enforcement, greatly simplifies RBAC and omits MLS altogether.

In fact, RHEL's targeted policy doesn't even implement Type Enforcement globally; it only defines domains for 12 specific subject dæmons, placing all other subjects and objects into a default domain, unconfined_t, that has no SELinux restrictions (outside of those 12 applications' respective domains).

The dæmons with SELinux domains in RHEL 4 and 5's targeted policy are:

  • dhcpd

  • httpd

  • mysqld

  • named

  • nscd

  • ntpd

  • portmap

  • postgres

  • snmpd

  • squid

  • syslogd

  • winbind

You may wonder, doesn't this amount to a global policy of “that which isn't expressly denied is permitted?” And, isn't that precisely backward of the “default-deny” stance that Mandatory Access Controls are supposed to provide?

Not really. It's true that the targeted policy falls well short of a trusted SELinux implementation of the kind you'd use for US Department of Defense work. However, neither does it amount to an “allow by default” policy. the regular Linux DAC (filesystem) controls still apply. So, if you think of the targeted policy as an extra set of controls layered on top of, not in lieu of, the normal filesystem permissions, application-level controls, firewall rules and other things you'd have on a hardened Linux system, you can see that even a limited SELinux policy can still play a meaningful role (no pun intended).

In fact, I'll go a step further and say that Red Hat's targeted policy is SELinux's best hope (to date) for mainstream adoption. Red Hat is by far the most popular Linux distribution to ship with any SELinux policy enabled by default; if that policy were locked down so tightly that any customized or substantially reconfigured application was barred from proper operation, most users would simply disable SELinux. (This was, in fact, what happened when Fedora Core 2 shipped with a “default-deny” SELinux policy.)

By enabling an SELinux policy that applies only to a limited, well-tested set of applications, Red Hat is minimizing the chances that a significant percentage of its users will associate SELinux with inconvenience and lost productivity. Furthermore, the targeted policy can be administered by a simple GUI, system-config-securitylevel, that doesn't require the user to know anything about SELinux at all.

Figure 1. RHEL 4's system-config-securitylevel Tool

The targeted policy ships with RHEL 4 and 5, Fedora Core 3 and later, and CentOS 4 and 5.

______________________

Comments

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.

Agreed

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.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

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.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

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.

Learn More

Sponsored by Storix