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 very complex and offers a lot more possibilities than AppArmor. But it's also much harder to configure. Still he thinks, and I totally agree, that this was the right way, completely implement a scalable (another point which he says comes too short on AppArmor) security-infrastructure (SELinux) and the tools to make it easier will follow. As seen with the great Eclipse-plugin SLIDE and other nice tools that help a lot in managing SELinux.
That way you can have ease of use (well, it's still not very easy) without loosing some of SELinux' power.
Well, of course you could say that Joshua, as SELinux-developer, lacks some objectivity. But I think his posts are clear and understandable and I agree to what he writes. And it's not like he's the only source of posts like this.
I think after reading all this my ideas about implementing AppArmor in EasyLFS (as an alternative to SELinux, which is already there) have died after reading this and having some thoughts about that topic.
Post new comment