Paranoid Penguin - Introduction to SELinux, Part II
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.
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:
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.
The targeted policy ships with RHEL 4 and 5, Fedora Core 3 and later, and CentOS 4 and 5.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released