Some more comments on AppArmor, since some people might see my previous post just as being disappointed by seeing it in Ubuntu, and not much work on SELinux.

First of all, I should note that I don’t have any SELinux systems I’m responsible for anymore. They still run SELinux in strict and are doing well, but I’m no longer responsible for them. So I’m actually pretty much out of SELinux development nowadays. I did some occasional policy merge to monitor policy development, and when I tried VMware, I even setup a SELinux system to check the current state. But I wouldn’t call myself an active developer or even user. So I don’t think I’m as biased as you might think I am.

Some things why I don’t trust the AppArmor people:

  • their website is incredibly full of marketing blah-blah such as “AppArmor is the most effective and easy-to-use Linux application security system available today” (effective as in what?)
  • their Wiki/FAQ states wildly inaccurate things about SELinux such as “To get the full power of SELinux, applications must be recompiled and linked against SELinux libraries.” (no, you don’t need to recompile and relink all your applications…) - and they even contradict themselves to some extend; on one hand they claim that you don’t need to modify applications for use with AppArmor, on the other hand they highlight it as a feature that you can patch your apache for AppArmor to get some more security for embedded interpreters such as PHP. This is pretty much the same as with SELinux.
  • they state such misleading things as “every user should give each system an afternoon’s test to decide which is a better match for their needs.” - sounds good at first sight, but how many admins are able to evaluate the security of a kernel-based security solution such as AppArmor or SELinux in one day? What this actually is, is an encouragement for admins to pick the security solution because of ease-of-use, not because of security considerations.

Instead they should be honest about what AppArmor can, and what it can not do. I don’t doubt that it can be used to make exploits with specially crafted PDF files in evince and such simple viewer applications a lot harder, but their security is not as thorough and complete as SELinux. They are potentially vulnerable to some attacks caused by their path name based approach, or that they cannot do MAC for files with unpredictable names such as most of /proc (e.g. /proc/1234/cmdline), any kind of sockets or when file descriptors are passed from one application to another.

They should also admit that since SELinux initially assigns file labels by very similar pathname/filename patterns as AppArmor uses, it maybe isn’t that much harder to setup in this aspect… In fact, it’s much easier in SELinux to add an additional location for font files, since all the application policies don’t need to be modified or reloaded, just the new font directory needs to be relabeled. In AppArmor, you’d need to modify an ‘abstraction’, then reload any policy that depends on this abstraction (you probably can only reload all at the same time, so that’s not too hard).

To anyone with a tiny bit of computer science knowledge, it should also be obvious that the performance of reconstructing the file path and matching it against a large set of filename globs (AppArmor) necessarily is slower than just using the security label in to the files attributes (SELinux, where this globbing was done once when doing the relabeling); any performance difference that shows that SELinux is slower than AppArmor is probably caused by SELinux doing a lot more security checks than AppArmor. So even AppArmor could benefit from using labeled security…

I’m cool with saying that AppArmor is easier to get started with than SELinux, but they need to be honest about the differences to SELinux and the problems with AppArmor.