Re: [RFC][PATCH 0/11] security: AppArmor - Overview

["Theodore Ts'o" <tytso@mit.edu>]

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/