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.

I’m in Baltimore for the 2007 SELinux Symposium. The past two days have been for tutorials, with two days now for the conference, and then a final developer summit day.

This morning’s keynote featured a talk by Richard Schaeffer, Director of Information Assurance at the NSA. Richard has been in this business for a very long time, and he provided some very interesting perspectives on computer security (I think the slides will eventually go up on the web site). We then had two sessions of solid technical talks, and are currently in the first of two WIP sessions. There’s a lot of interesting work happening now extending SELinux out past the base OS, with increasingly mature analysis and development tools, as well as continued refinements to the core technology.

Chris Vance’s SEDarwin talk was particularly interesting: apparently the next version of OSX will ship with the TrustedBSD MAC framework. This won’t initially include the SE Darwin work, but hopefully it’ll be possible to get it running without too much trouble.

There’s also good progress being made on extending SELinux to the desktop, as described in NSA talks on GConf integration and X.org integration. Xinwen Zhang of Samsung gave an interesting talk on extending SELinux to mobile platforms (such as cell phones), and related research into platform integrity.

The SELinux community is growing and looking very healthy, although I think we can still do a lot more to encourage wider participation.

Steve Rostedt and Glauber de Oliveira Costa have just posted initial patches for a 64-bit (x86-64) version of lguest. Looks like the next steps will be to consolidate the code into common and per-arch components. Initial feedback from Rusty seems good.

I’ve been working on converting lguest over to the new clockevent and dyntick frameworks. (Thomas Gleixner’s OLS paper, Hrtimers and Beyond: Transforming the Linux Time Subsystems, is also a great reference on the topic).

Tickless operation is particularly useful for virtual machines, allowing clock events (for timers etc.) to be programmed on demand, with events only being delivered to VMs as required, rather than say, generating a synthetic tick stream for each VM. (Or in the case of lguest, switching out of each guest on each host clock tick). It’ll be interesting to re-run the networking benchmarks again with tickless & high-resolution timer support.

There may be some scope to consolidate common clock code between several HV projects (Xen & lguest have nearly identical clockevent code in progress), although it’s not entirely clear yet how much can be usefully gained, as the new clock APIs make the client code fairly simple.

Máirín Duffy has created a new logo for lguest (also now known as the puppyvisor):

Via Val Henson: some hilarious slides from a talk on network protocols by Radia Perlman. I’m sad to say I haven’t seen Radia give a talk as yet.

The SELinux Symposium is on next week!

The rustyvisor is now segmentless, paving the way for x86_64, nested interrupts (useful for oprofile) and probably simpler guest SMP. It’s amazing how much can happen in Linux over a weekend. I was happily surprised to see my simple patch to enable bridging was applied in the midst of the rewrite.

Early registration for the 2007 SELinux Symposium ends in a few days. The WIP program is now quite full — I’ll be interested to see KaiGai Kohei’s talk on what’s happening with SELinux in Japan.

I thought it’d be useful to have a look at the performance of lguest networking, to establish a baseline for potential future improvements.

The I/O model uses a DMA-like scheme for transferring data between the host and the guest, which is clean and simple, but currently involves extra transitions across ring boundaries. For example, when an external packet for the guest arrives at the host, it is passed to host userland via the TAP driver. An I/O monitor detects that the TAP fd is readable via select(2), and sends a USR1 signal to the guest launcher, which causes the guest to switch out of ring 1 (where it was executing as the guest kernel) and back into a normal ring 3 process in the host. The guest process then prepares a DMA buffer with the packet and triggers a virtual IRQ, which fires after it switches back to the guest kernel in its main processing loop. The guest kernel then processes the packet via a paravirt network driver and its own network stack, after which, a userland process of the guest is switched in to receive the data.

So, in summary, the packet traverses two network stacks across several ring boundaries and context switches. Oh, and NAT or bridging would have been used in the host to get the packet into the TAP interface.

How does this impact performance?

I ran some very simple TCP bandwidth tests with iperf.

First, a vanilla kernel, without paravirt_ops configured, to help ultimately isolate the impact of lguest. The figures here are in MByte/s for a local 2.4Ghz 4-way Xeon system talking over switched gigabit ethernet to a uniprocessor 2.4Ghz P4.

loopback   client   server
--------------------------
     113     78.3     48.6

‘client’ indicates the bandwidth obtained with the local system acting as an iperf client, while ‘server’ means the local system was acting as an iperf server.

Next, I configured a bridge device as the external interface, to get an idea of the impact of the bridging code alone, as it will be used to get packets to the guest.

loopback   client   server
--------------------------
       -     30.2     44.3

Looks bridging imposes quite a hit on the receive path.

Then, the kernel was recompiled with paravirt_ops, to see if that alone would affect performance:

loopback   client   server
--------------------------
   113.6     77.1      49

Not really.

Bridging and paravirt_ops together had more of an impact than just bridging:

loopback   client   server
--------------------------
       -      26.4      40

This figure as is where we measure the impact of lguest from.

One thing I wanted to check before running a guest was the impact of simply loading the lguest module, as it disables PGE in the host, so that the TLBs covering kernel memory are flushed when switching between the guest and host kernels. This has the side-effect of causing global page TLB flushes on all context switches.

loopback   client   server
--------------------------
     110     26.1     39.9

Seems like there was only a slight performance hit in this case.

Now, a guest instance:

loopback   client   server
--------------------------
    42.6      8.3     10.5

So, it seems the network performance of lguest over link is around 25-30% allowing for the overhead of the bridging code. This is about an order of magnitude faster than what I’ve seen with Qemu (which is not really a fair comparison, as it’s an emulator, but a useful smoke-test), and competitive with Vmware and UML according to some Xen performance figures. Obviously, it’d be nice to get up to Xen’s near-native performance at some stage.

I also ran the same test using NAT instead of bridging, with similar results:

loopback   client   server
--------------------------
       -      8.5      9.9

Here are the figures for guest to host networking:

loopback   client   server
--------------------------
       -        8     11.8

while guest to guest networking (via –sharenet) ran at 20.1 MB/s.