By finally coming forward and “applying” for inclusion into the mainline kernel, AppArmor finally has to face critique on it’s approach. And it seems that it’s being beaten up quite a bit.

I don’t think there is anything in AppArmor that you can’t do with SELinux just as good (Yes, SELinux does use labeled files to work around the hardlink issues, but guess how these labels are assigned initially? By pathname. If you have a hard link with two different labels, only one of them will stick.).

You can in fact “learn” your SELinux policies just like AppArmor. That’s called audit2allow, and it is frowned upon for good reasons, and only considered to be okay for interim solutions.

There are also tools in development to produce meaningful policies, that is where SELinux really sets itself apart from AppArmor. In AppArmor, you specify for each “confined” application which files it access (and which capabilities), usually by learning these. On SELinux, you basically divide your system into meaningful parts (e.g. logfiles, user mail, user web files) and then specify which kind of access an application is to be granted.

This manual part, deciding which access is allowed, is a big feature. Apparently the AppArmor thunderbird policy has “learned” the setuid permission for thunderbird, which I consider a very bad idea. You can’t just learn everything while application may have bugs (or workarounds, or security nets

  • e.g. it might try to setuid and quit if it succeeds!).

And despite some claims, SELinux does not require you to have a policy for everything on your system. Only in “strict” policy, whereas if you use “targeted” policy, you’ll have a so called “unconfined” domain, too.

The AppArmor approach reminds me a lot of what grsecurity 1.x ACLs were doing, back with some 2.4.x kernel. It never worked too well for me, that’s why I can’t say much about newer grsecurity versions… but to me, grsecurity sounds a lot better than AppArmor. Much more mature.