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.
There are several situations where booting might fail. So here we go with a summary of the most common pitfalls and possible solutions:
