After yesterday's post about SELinux now part two of this (so far) three part series.
After I had read that shocking post about a company suggestion to disable SELinux I had another look through Joshua Brindle's Blog and found some more interesting stuff, this time about AppArmor.
My personal views on AppArmor hadn't been very good before, having read a pretty long article in one of my magazines and some stuff on the Internet. But Joshua's articles "On AppArmor" and "Security Anti-Pattern: Path based access control" really make me doubt the effectiveness of AppArmor.
In the second post (Path based access control) Joshua nicely shows the problems that arise if only paths are used to determine if access is allowed or not. Consider that a file can have more only one name, because files are actually nameless inodes, the names are only entries in the directory that point to that inode.
He gives a nice example why this can be a serious problem:
For example a users shell might only be able to read /etc/hosts but at the same time write to a hard link of that file at /home/user/chroot/etc/hosts. By writing to /home/user/chroot/etc/hosts he is also writing to /etc/hosts, this is clearly wrong.
It should be obvious that this is not the kind of behaviour we want to see on a box that's secured with a piece of software that is supposed to make things more secure, like AppArmor is supposed to be.
In the first post (On AppArmor) he even writes that AppArmor isn't really Mandatory Access Control and because of that couldn't even really be compared to SELinux, which is a lot more complex.
His reasons for this are easy and understandable: AppArmor has been designed for the normal user, to be easy to configure and to maintain. The problem is that this brings limitations, like shown above in his example.
SELinux on the other hand is