I didn’t intend to write (ok, rant…) on this topic again, but a few days ago, this “AppArmor FAQ”, was posted to the Linux Kernel Mailing list. Again, this is a lot of ‘marketing stuff’, and doesn’t have the facts quite right…

Some quotes:

In the traditional UNIX model, files do have names but not labels, and applications only operate in terms of those names.

No. In the traditional UNIX model, filenames point to inodes, and the inodes contain data such as file modification dates and permissions. This is where SELinux stores the labels it uses for access control. In fact, the “unix owner” and “unix group” are pretty much the same thing as SELinux labels. And also work pretty much the same way.

Contrary to popular belief, AppArmor is not “Pathnames R Us”, but rather “Use native abstractions to mediate stuff”: when you mediate something, you should use the native syntax that users normally use to access the object.

Maybe the appropriate term would have been “naive abstractions”?

And, no, security systems shouldn’t be designed around what a user can easily grasp, because that might just not work… it should be designed around the way resources are handled and how you can successfully restrict access.

“Contrary to popular belief”, SELinux does use path names. Actually in a very convenient way for the users. So I wouldn’t claim SELinux is really harder to use than AppArmor because of its use of path names.

The difference is that SELinux doesn’t rely on the path names, but it still gives the user the possibility to use them. In fact, the only way I know to get a proplerly labeled filesystem is based on path names.

If I’d for example keep my web stuff in /home/www, I can tell SELinux that the appropriate label is httpd_sys_content_t by doing

semanage fcontext -a -t httpd_sys_content_t /home/www
restorecon -R /home/www

In AppArmor, I’d need to modify the policy for several applications to achieve this, because of it’s dependency on path names. SELinux also uses an abstraction. One that is very convenient for users actually. SELinux does access control on object classes. What I’m doing in above example is to put these files into the “Web site data files” class. So please stop scaring people of “labels”. That is just the technical term for what is an “object class”, a concept every developer will be familiar with. (SELinux policy development has a couple of OOP-like features, btw., for example it is possible to give an application access to ‘all log files’.)

There are, however, some true statements hidden in there:

We also acknowledge that pathname based access control requires a way to perform pathname matching in the kernel, and this comes at a cost higher than comparing object labels […] So by providing string matching in the kernel, AppArmor trades run-time performance to grant reduced administrative work.

It is however not obvious how large the difference in “reduced administrative work” is between AppArmor testing the filename “run-time” compared to SELinux using filenames to relabel files “on demand” (or, with restorecond, even on creation by using inotify).

What I still seriously dislike is the FUD spread by AppArmor people such as

Label-based security (exemplified by SELinux, and its predecessors in MLS systems) attaches security policy to the data. As the data flows through the system, the label sticks to the data, and so security policy with respect to this data stays intact. This is a good approach for ensuring secrecy, the kind of problem that intelligence agencies have.

Why should this only be useful to “intelligence agencies”? Some people live in countries with very strict privacy requirements, and we might want to use these techniques to lessen the risk of leaking data. In AppArmor, I can copy a file with private customer data to the web server directory, and it becomes readable by the web server. In SELinux, the file will still be unreadable by the web server. Does that really sound like “only useful to intelligence agencies” to you?

Dear AppArmor people, please stop trying to invoke fear of the NSA, just to make people use AppArmor. That makes you look very untrustworthy, you know…

The SELinux kernel code is part of the Linux kernel, AppArmor is not. So in theory, that code has been reviewed much better than yours, and is maybe even less likely to contain a “NSA backdoor” than yours. Changes to SELinux are openly discussed on a mailing list, and go through peer review there. They foolow a very strict coding style, which makes review easier; obfuscated code doesn’t have a place there. It’s not like we were running a binary blob from the NSA we can’t have a look at.