On AppArmor

This will be the last thing I write about AppArmor because quite honestly it’s a waste of time to constantly refute people and I’d rather work to make security better for everyone .

That said, I taught an SELinux tutorial at LWE San Francisco last week, unfortunately my tutorial wasn’t one of the ones reviewed by the media, what a shame. During the tutorial I was asked about AppArmor, to which I said they could come up after the tutorial to talk about it, I didn’t want to disparage it in front of an audience of 50, I’m a nice guy like that.

Then I saw this article, which has a quite humorous title, which prompted me to go ahead and write up something that I can point to in the future.

If you’ve read my previous articles you’ll see the great deal of technical problems AppArmor has and I can even add a few such as an incomplete reference validation mechanism, incomplete object model, the fact that it isn’t really mandatory access control (and thus not even comparable to SELinux), etc. Those don’t seem to affect a large number of people though, decision makers and administrators sort of give me strange looks when I start going into those.

So here are some more reasons, slightly less technical but probably much more important to these particular crowds. You see, I was an admin once upon a time and speaking from experience admins are much less likely to take a ‘purity’ argument seriously, because they know the kind of impure crap that has to happen to get the job done.

I think the most important and compelling argument for both of these crowds is one of scalability. AppArmor is very much a ‘right now’ type of solution. They give you exactly what you see, a security mechanism that will protect some of your applications within a limited threat model, namely only remote intruders and only if they can only exploit 1 application. So, you say that’s all you need and AppArmor lets you write “profiles” in 5 minutes? That’s great, are you sure it is all you will ever need?

With AppArmor there is no room for improvement. The authors were so focused on ease-of-use that they pushed all the simplicity into the model (incidentally this often creates a very complex implementation but that is another point). The model, then, only covers this very limited threat model. You will never be able to secure your infrastructure more than you can today with AppArmor. Your system level applications will never be secured, your users will never be restricted, and your confined applications only haphazardly.

SELinux has its roots in research that started around 1992, to build very secure systems on OS’s like Distrubuted Trusted Mach (DTMach), which later continued as the Distrubuted Trusted Operating System project. Eventually the Flask architecture comes out of an implementation by the NSA and the University of Utah which is the same architecture that SELinux uses today. When I started working on SELinux 4-5 years ago it was a very very hard thing to use and implement in a distro. The SELinux researchers and developers were very interested in getting the security right, and then simplifying it with tools in userspace, like it should be.

So here it is, 2 years after Red Hat first put SELinux on by default in a general purpose distro (oh yea, AppArmor also doesn’t come on by default) and the usability of SELinux has leaped lightyears ahead of where it was. The best part is that SELinux will continue to get easier, while keeping its strengths while AppArmor was artificially limited by a broken design.

So, that’s the background on SELinux. The point of it was to say, SELinux is complete and comprehensive and also very flexible. The SELinux policy lets you basically accomplish any kind of security goals you have. So you can deploy SELinux today using the targeted policy and tweaking where necessary on your system, which requires little SELinux expertise and when you are ready you can secure more and more of your infrastructure, you aren’t artificially limited, SELinux scales to any security goals you might come up with anytime in the future.

So I believe that is a pretty compelling reason for an Admin, but I’ll throw in another bonus reason. AppArmor claims extreme ease of use and Novell is pushing it on their enterprise clients but one important thing they are missing for any enterprise is any kind of network policy management. I’ll grant you that SELinux isn’t overflowing with network policy management capabilities today but there are several works in progress. Even without the specific network management SELinux has modular policy and local customizations that let you maintain a set of policy modules that you can deploy to your systems while maintaining local customizations on top of those policies at each machine that needs them, already significantly better than any AppArmor offering. My employer, Tresys has a product coming out called Brickwall that has some pretty advanced network management capabilities and obviously my project, the policy server, has some crazy capabilities extending even to access control on the policy, so that you can delegate parts of the policy to junior administrators without letting the intent of the policy change.

With the scalability and management features of SELinux (and the lack of them in AppArmor) I’d be seriously shocked if an informed administrator chose AppArmor.