Dan Walsh has published an article on his SELinux policy generation wizard at Red Hat Magazine.

The article is a great introduction to the modern SELinux policy development environment, while the tool itself demonstrates how high-level abstractions are the key to SELinux usability.

In this case, the sysadmin is provided with a set of questions about the application to be confined, and makes selections based upon patterns which are commonly encountered in similar applications. Some further questions are asked, such as which ports the application might use, and then a loadable policy module is generated.

If you want to try the tool for yourself, you’ll find it in current RHEL 5 and Fedora 7, runnable via system-config-selinux .

Linux Journal have published an interesting article, Mambo Exploit Blocked by SELinux, by Richard Bullington-McGuire.

Mambo is a CMS written in PHP. At some point, the code was vulnerable to a worm, which breached Richard’s system. His article details how this breach was both detected and contained with SELinux, as configured with the default targeted policy under RHEL4.

It demonstrates one of the core goals of SELinux, which is to prevent flawed software from being exploited by malware. In this case, the payload was delivered into the system via a third party PHP application, but was then prevented from doing any damage.

The article is also useful generally as an example of computer forensics procedures.

Even though it is fairly well known that system call wrappers are dangerous, many security schemes continue to use them, including several well-known commercial security products from major vendors.

Briefly, the technique involves intercepting user requests at the system call level, then performing some security function and perhaps failing the call. A common example is re-vectoring the system call table so that a virus scanner is invoked when a file is opened. The Linux system call table was unexported long ago to discourage such use, although there’s no way to actually prevent it.

There are many problems with such techniques. One significant class arises from the combination of concurrency, and gaps in time between when an object is checked and when it is used. For example, an application may subvert the security mechanism by passing clean data to be checked, then replacing it with malicious data before it is used. This is called a Time of Check to Time of Use race, or TOCTTOU.

Robert Watson, of FreeBSD and TrustedBSD fame, recently presented a good paper on the topic, which he discusses here: USENIX WOOT07, Exploiting Concurrency Vulnerabilities in System Call Wrappers, and the Evil Genius.

In the paper, problems with system call wrapping are comprehensively detailed, while the slides also include several examples of exploit code.

One interesting case, which I think would surprise many, is the ease with which their sudo could be subverted.

With Sudo on MP systems, the window for execve() arguments was over 430K cycles. We were able to successfully exploit this vulnerability, replacing command lines so that they were incorrectly logged, masking all further attacker activity in the audit trail.

The paper also discusses ways to mitigate the problem, including not using system call wrapping at all, and instead directly integrating mediation into the kernel; which is what SELinux does.

The 2007 FOSS.IN conference has been announced, and will take place in Bengalaru from December 4-8.

It looks like they’re tightening their focus on community development and depth of talks, as discussed by Andrew Cowie.

There’ll be a HackCenter — an area set up specifically for people to work together — this is something I’d have found useful at many other conferences in the past.

I really hope to return to the conference this year, after not being able to make it for 2006.

I just posted about this on SELinux News: HP have now completed a common criteria certification of RHEL 5, covering LSPP, RBACPP and CAPP at EAL4 augmented. This is basically the same as the IBM certification. Indeed, both certifications stem from the same cooperative effort.

For the first time, we are seeing security certifications from different vendors which are fully compatible, thanks to a community-based approach. From a customer point of view, there is now true choice in certified solutions, as it’s possible to choose different hardware vendors. While technically not certified, pure RHEL clones effectively extend that choice to selection of OS vendor.

So, Linux now offers the highest evaluation level possible for an off-the-shelf operating system, with a flexible, modern MAC scheme, without vendor lock-in for either hardware or software. It’s all upstream, and the source is out there for anyone to review, use, experiment with or develop further.

More importantly, the underlying technology aims for general usability, and is already protecting millions of systems from modern security threats.

Seth Vidal writes about configuring polyinstantiated tmp directories under Fedora. This allows different users to have their own view of /tmp through the use of shared-subtrees and pam_namespace.

Also see Russell Coker’s paper on the topic.

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-depth¹ to ensure the underlying vulnerabilities are fixed.

Advisories: RHEL5, F7.

¹Here’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:

– Infoworld
– Yahoo

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.