Messages in this thread | | | Date | Mon, 24 Apr 2006 23:52:17 +0000 | From | Theodore Ts'o <> | Subject | Re: [RFC][PATCH 0/11] security: AppArmor - Overview |
| |
On Mon, Apr 24, 2006 at 05:07:56PM -0400, Stephen Smalley wrote: > > 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. > > Does it have any hope of stopping an attacker who has designed his > attack with full knowledge of AppArmor's design and implementation (no > security through obscurity)?
Well, it also depends on your threat model, right? What capabilities are you assuming the attacker will have? Does the attacker have an account on the system? Or has the attacker just exploited a stack overrun in a network daemon, or a failure to check some input field coming from the network, and the goal is to stop the attacker from escalating that to gaining full root privs on the system.
There is a big difference between assuming the attacker has full knowledge of AppArmor's design and implementation, which granted, is a fair assumpion (no security through obsecurity) and assuming the attacker has full root privs, and still wanting to stop them (i.e., mandatory access controls). You seem to be judging AppArmor with the goals of SELinux, and that's not necessarily a fair comparison.
A Hummer can go through 36 inches of standing water, where as a Prius can not. Does that mean that a Prius is a failure? Only if you judge it by the standards of the Hummer. But from point of view of gas mileage, the Prius will run circles around the Hummer....
> The problems with path-based mechanisms are technical in nature, not > just philosophical.
If you restrict namespaces and chroot, then it solves that particular problem. It will be useless for software packages that use namespaces, such as for example if a hypothetical future version of a propietary source code management tool decided to use shared subtree support. There are however a huge number of software packages, including most commercial/propietary packages that have to work across a broad range of heterogenous systems, including AIX, Solaris, and Linux, that won't be using namespaces and shared subtrees anytime soon.
- 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/
| |