Tag Apparmor
Misunderstanding UNIX security
I just got a comment on my post about path based access control that was fairly startling to me. The more I thought about it, though, the more I thought maybe others shared the beliefs so I’m going to respond to it here. inode-based security has analogous problems to path-based security. Software opens paths, not inodes, so it very much matters what the permissions are for the file at /etc/shadow or /var/data/mydb, regardless of what the inode happens to be.
On AppArmor
This will be the last thing I write about AppArmor because quite honestly it’s a waste of time to constantly refute people and I’d rather work to make security better for everyone 
.
That said, I taught an SELinux tutorial at LWE San Francisco last week, unfortunately my tutorial wasn’t one of the ones reviewed by the media, what a shame. During the tutorial I was asked about AppArmor, to which I said they could come up after the tutorial to talk about it, I didn’t want to disparage it in front of an audience of 50, I’m a nice guy like that.
Then I saw this article, which has a quite humorous title, which prompted me to go ahead and write up something that I can point to in the future.
Security Anti-Pattern: Path based access control
For those of you who missed my other Security Anti-Pattern post, an anti-pattern is a commonly reinvented bad solution to a problem. There are many of these in security but one that seems to be occurring quite often these days is path based access control, an access control system that use file paths to refer to objects. To the uninitiated this may seem like a good idea at first, hopefully this blog entry will eradicate such beliefs. Apologies in advance for the length of this post.
Top-down vs. Bottom-up Policy Development
I’ll be the first to say I’m not a policy developer. The process of actually writing policy is not at all interesting to me, fortunately for me there are people like Chris PeBenito, Russell Coker, et al that seem to enjoy this. I am interested, however, in how policies are developed.
There seem to be two schools of thought on this subject: top-down policy development and bottom-up. Top-down policy development is very similar to status quo encapsulation, which I talked about in a previous post, in that it basically means you take a running system and look at it top-down, in its entirety, and develop a policy based on that perspective. Bottom-up policy development, which is historically what SELinux has done, is the opposite; you create policies for individual applications running on a system until the sum of those policies meets the security goals of the system. I’ll try to talk about the advantages and issues with each of these.
Security Anti-Pattern: Status Quo Encapsulation
First a clarification: in my last post I said that least privilege is the ultimate goal of most MAC advocates but that isn’t entirely true, I accidentally ignored a large portion of MAC advocates (mostly those that predate me!). There are several different models which are commonly implemented and thought to be correct. In the government industry that model is Multi Level Security (MLS) and is in no way least privilege, but that is another topic altogether. In the civilian sector status quo encapsulation is a popular model to implement, which is what I’ll be talking about today.