Messages in this thread | | | Date | Mon, 24 Apr 2006 03:03:24 -0400 | From | Theodore Ts'o <> | Subject | Re: [RFC][PATCH 0/11] security: AppArmor - Overview |
| |
On Mon, Apr 24, 2006 at 02:18:50PM +1000, Neil Brown wrote: > Think about the name of this system for a minute. "AppArmor". > i.e. it is Armour for an Application. It protects the application. > It doesn't (as far as I can tell: I'm not an expert and don't work on > this thing) claim to protect files. It protects applications. ... > While the protection against subversion cannot be complete, it can be > sufficient to dramatically reduce the chances of privilege > escalation. There are lots of wrong things you can get an > application to do once you find an exploitable bug. Many of these > will lead to a crash. AppArmor will not try to protect against these > (I suspect). There are substantially fewer that lead to privilege > escalation. AppArmor focusses its effort in terms of profile design > on exactly these sorts of unplanned behaviours. > > So I think you still haven't given convincing evidence that AppArmor > is broken by design.
I have to agree with Neil here. I spent over 10 years doing network security as my day job, including chairing the IP Security working group and being a member of the IETF Security Area Directorate, before switching over to Linux as the thing that would pay the bills, and I can state quite authoratatively that perfect security which is never used because it's too hard to install, maintain, and configure, isn't worth much compared to imperfect security which is easy enough such that users always use it by default.
The goal of protecting against broken, buggy applications is a worthy one. If people can show that for a large set of stack overruns, or other types of buggy applications, it is possible to evade AppArmor by doing something clever, then AppArmor would need to be fixed or it's not worth doing. But if it can prevent a large class of buggy applications from allowing an atttacker to escalate that bugginess into a system penetration, then it has added value.
In the security world, there is a huge tradition of the best being the enemy of the good --- and the best being so painful to use that people don't want to use it, or the moment it gets in the way (either because of performance reasons or their application does something that requires painful configuration of the SELinux policy files), they deconfigure it. At which point the "best" becomes useless.
You may or may not agree with the philosophical architecture question, but that doesn't necessarily make it "broken by design". Choice is good; if AppArmor forces SELinux to become less painful to use and configure, then that in the long run will be a good thing.
- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |