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

[Stephen Smalley <sds@tycho.nsa.gov>]

On Mon, 2006-04-24 at 23:52 +0000, Theodore Ts'o wrote:
> On Mon, Apr 24, 2006 at 05:07:56PM -0400, Stephen Smalley wrote:
> > 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. 

AppArmor doesn't do a very good job there either; its mediation is very
incomplete (nothing over IPC or many other inter-process operations),
and its ambiguous identification of objects leaves it prone to
coordinated attacks.  Why not just use a jail-style mechanism if that is
what you want, ala VServer or OpenVZ?

> 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.   

But AA specifically emphasizes that it controls capabilities so that
even a uid 0 process is "confined" by it.  

> 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.

pam_namespace in Fedora Core.  Not to mention that the restrictions you
mention only solve the problem within the jail, which is fine if we are
only talking about jail mechanisms.  Not so good for any kind of real
MAC.

-- 
Stephen Smalley
National Security Agency

-
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/