A recent Apache vulnerability, where a remote attacker can cause httpd to send a signal to an arbitrary process and potentially crash it, is mitigated by SELinux targeted policy (as installed by default in RHEL5 and F7). Of course, even if you have SELinux enabled, it’s good defence-in-depth1 to ensure the underlying vulnerabilities are fixed.
1Here’s a useful reference page on Fedora Security Features.
RHEL is now certified at EAL4+, when configured appropriately on IBM’s mainframe, System x, System p5 and eServer boxes, according to the protection profiles LSPP (labeling), RBACPP (role based access control) and CAPP (audit).
EAL4+ is as far as you can go with an off the shelf OS. Beyond this, you need semiformal security design and pretty much a new OS. LSPP is the current equivalent of the old “orange book” B1 TCSEC rating.
This certification means that Linux is now officially considered appropriate for use as a “trusted” operating system, although with SELinux, it is far more flexible and capable than any of the existing MLS-oriented solutions. While the evaluation is specific to RHEL5 and IBM hardware, everything is freely available in source form, and also freely available as an installable distro via Fedora, Centos and derivatives thereof.
A lot of people thought it would be outright impossible to get an open source OS certified at this level. Not only were they wrong, but we’ve done it in a way which makes it part of the mainline kernel, upstream userland, and integrated into standard distributions. It is not some out-dated, incompatible and outrageously expensive fork of the OS, as has historically been the case with trusted OSes. “Military-strength” security is just now just another feature you get as standard in Linux, and it receives the same testing and community benefits as the rest of the OS.
Those who accuse Linux of lacking innovation might do well to look at this, and also see how others are now adopting these innovations.
News coverage:
According to this GCN article, Sun are thinking about implementing Type Enforcement (TE) in Solaris and Java:
Sun executives are considering adding type enforcement, a more granular approach used in SELinux, to their OS, but Vass added that his company is also considering adding it to its Java language because it sees merit in both.
TE is a fundamental SELinux component, and I really hope Sun incorporate it into their OS. I for one will be more than happy to collaborate to ensure interoperability with SELinux.
Rusty recently committed my patch to convert lguest over to the modern hrtimers API. This allows guests to run tickless (also known as dynamic ticks), which means that instead of being fed a constant stream of timer ticks, a guest will only receive a timer interrupt when it really needs one. As a bonus, these ticks will likely arrive with a much higher resolution than every 1/1000 s (or whatever HZ was set to).
Tickless operation is important for virtualized systems. Imagine if you had ten guests, each running at 1000HZ. With static ticks, the host would need to generate 10,000 virtual ticks per second, and each guest would be handling 1000 synthetic hardware interrupts/s, the vast majority of which would very likely be unnecessary. Instead, lguest now allows guests to request clock ticks to occur only at some appropriate point in the future, with nanosecond resolution.
A virtual clock event device is instantiated for each running guest. Instead of being a programmable piece of hardware (such as an HPET), the virtual device is quite simply a high-resolution timer attached to the guest. When the guest needs to program a clock tick event, the smarts of which are thankfully buried in the hrtimer code, it issues a new hypercall, HCALL_SET_CLOCKEVENT, with an argument in nanoseconds representing the relative amount of time until the event is required. The hypercall traps into the host, which converts the relative delta into an absolute value (we know when ‘now’ is in the guest’s virtual time, as we’re in its hypercall context, which is similar to being in the syscall context of a userland application), then starts a highres timer running in the host. When this fires, the host simply sets the timer interrupt for the guest. When the guest runs next, its own hrtimer mechanism is then invoked to process the timer interrupt.
Conceptually, it’s quite simple, which keeps the puppies happy. This is due in large part to the great hrtimer subsystem by Thomas Gleixner and Ingo Molnar. Check out the 2006 OLS paper for more info on hrtimers, as well as the LWN articles here and here.
Josh Brindle has written an in-depth article, Secure Networking with SELinux, which covers some of the different network security mechanisms in SELinux. Of particular value is its discssion of labeled IPSec, which is currently not well documented. Josh includes some worked examples of use with explanations, and discussion of potential uses:
For example, one possible application of this technology is to have an ‘internal’ and ‘external’ browser on employee workstations. The internal browser would run in a domain that is allowed to access internal company web application servers that contain confidential customer information while the external browser can access the internet. This reduces the risk that rogue internet content can compromise your internal data. This kind of separation would be much more difficult (or impossible) without SELinux’ advanced networking controls.
Linux now has some very powerful and expressive network security capabilities; perhaps unmatched anywhere. Better usability is an important next step with this, and I suspect from comments in the article that Josh may have more for us on this soon.
Dan Walsh writes in detail about how SELinux mitigates recent vulnerabilities in Samba. The referenced vulnerabilities potentially allow remote arbitrary code execution due to coding errors: exactly the kind of thing SELinux was designed to protect against.
It’s notable is that the SELinux memory execution controls are key here, as they are often the cause of problems with third-party software installation vs. SELinux issues. More often than you’d expect, applications and/or libraries will try to do highly questionable things like making areas of the heap executable, which SELinux will typically prevent. This tends to be seen more in closed software, which is also unfortunately harder to fix. In any case, SELinux is usually doing the right thing for you when this happens, as explained by Ulrich Drepper.
Generally, the best solution for software such as this is to fix it and make it safe; not to disable security protections. Ulrich provides example code of how to make such fixes in the referenced article.
SELinux kernel developers and other curious folk may be interested in the new SELinux Kernel Development Wiki page.
This is where we’ll maintain the current todo list and maintain various resources relating to SELinux kernel development. Anyone active in this area as a developer is welcome to edit the page. Accounts may be requested via Karl MacMillan.
Slides and papers from the 2007 SELinux Symposium are now up.
Recently, Glenn Faden of Sun posted a comparison of SELinux and Solaris Trusted Extensions from an MLS point of view.
Karl MacMillan has now published a response, starting with a discussion of classic “trusted operating systems” and their manifest inadequacies. Then, he outlines the role of SELinux in providing a more general and flexible approach to security in mainstream OSs, meeting a wider range of requirements in a more comprehensive manner, and to do this not as a stale fork of an OS, but as a first class component, available by default. Karl also addresses some of the pervasive technical errors in the Sun article, which need rebuttal, even though they sidetrack more essential issues.
On trusted systems:
The worst of it, though, is that these systems were only useful for a small set of customers. Namely, government customers that maintain classified data (you know, “Top Secret”, “Secret”, etc.). The systems weren’t super secure versions of their general purpose counterparts as many people mistakenly assume. Instead, they were only secure in terms of a very narrow set of requirements.
Indeed, these old MLS models are full of problems, although generally mitigated with subsequent band-aids, people may be surprised to know, for example, that one of the foundational MLS policies, BLP, provides no integrity at all and can be trivially subverted.
Frederick Cohen, in his now fascinatingly dated A Short Course on Computer Viruses describes with great simplicity a virus which would allow the least trusted user on a BLP system to infect software run by the most trusted user. This was not exploiting an implementation flaw; merely an inherent limitation of the narrowly focused security policy. Another feature of classic MLS or trusted systems is that a trusted application can be defined as one that violates the security policy. That is, the policy is so inflexible that you must break it with a privileged application to make the system work.
This is not to get into a critique of MLS, but to highlight the role of SELinux in providing a flexible security framework with integrity built in from the ground up, and that thinking in these areas has advanced significantly since the 1970s and 1980s.
There are still some cases where MLS is indicated, particularly where there are very large numbers of distinct compartments, and for these cases, SELinux provides an integrated MLS capability. Typically, however, users who claim to need MLS quite often don’t—it’s all they’ve ever known—and they’re better off with a more flexible security policy which meets their specific requirements and does not need to be subverted by trusted applications to work.
Framing a comparison of SELinux and Solaris Trusted Extensions in terms of how each meets classic MLS requirements ignores the essential issue of SELinux as a fundamental paradigm shift in security. With SELinux, mandatory access control is available for virtually any class of user.
The case for generalized MAC is compelling, and I would invite the OpenSolaris project to consider integrating the Flask model (of which SELinux is an implementation) into their OS.
The SE-BSD and SE-Darwin efforts prove that SELinux components can be integrated into other OSs (where licensing allows), or otherwise re-implemented. I believe this would further improve and refine the technology due to greater diversity of implementations, with the potential to standardize flexible mandatory access control, similarly to the rough consensus of DAC. We’d then have greater interoperability and normalization of strong security mechanisms, which would be greatly beneficial to general users and thus computer security in general.
The SELinux Symposium proper finished yesterday, with another WIP session, then some interesting applications of SELinux talks, and finally, talks on MLS. It’s interesting to see the conference evolve from being mostly about research and theory, to having an increasing orientation toward case studies and similarly practical topic areas.
Daniel Frye, an IBM VP, gave the second keynote and highlighted the growth of Linux as an enterprise OS from a security point of view, and the persistent challenge to make security compelling outside of the public sector.
Something which should help general users is setroubleshoot, which is now shipping in the RHEL5 and Fedora distros. It was developed by John Dennis, who gave a talk at the symposium. setroubleshoot detects when SELinux encounters a problem and tries to explain it to the user and provide a course of action to follow. It does this by popping an alert up in the system tray and optionally sending an email notification:
The symposium concluded with the usual drawing of prizes, this time including iPods, SELinux books, RHEL5, a Mac Mini and a HP laptop. Guess which one everyone wanted.
Today is the Developer Summit: a focused discussion on current and future directions by around twenty of the core developers.
In the photo, Karl MacMillan (2nd from the left) is talking, which is not unusual.