Re: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11]security: AppArmor - Overview

[Stephen Smalley]

On Fri, 2006-04-28 at 13:47 +0200, Andi Kleen wrote:
> On Friday 28 April 2006 13:28, Stephen Smalley wrote:
> 
> > So you are only worried about script kiddies?  Further, once someone
> > crafts an exploit specifically targeting AA, knowing full well its
> > limitations, that exploit will become fodder for the kiddies as well.
> > If a security mechanism only prevents attacks that weren't designed
> > against it, what good is it aside from a temporary stopgap?
> 
> The same could be said about selinux. Or what are you doing
> to e.g. stop DOS attacks? Nothing is 100% water tight. The question
> is just if the subsets of controls it implements matches the requirements of 
> the administrator. These requirements both include easiness of use
> and security. Usually there is a tradeoff there and it's not the
> same for everybody.

I can't say I follow your reasoning.  AA and SELinux are both access
control mechanisms; DOS attacks are largely outside the scope of either.
They are both concerned with preventing unauthorized disclosure of
information (confidentiality) and unauthorized modification of data
(integrity), not with ensuring availability of service.  Neither will be
perfect in achieving such goals, but we can legitimately ask whether one
mechanism is so fundamentally flawed as to never be able to achieve the
goals in the face of an adversary with full knowledge of the mechanism.
And I think that AA qualifies here, again due to incomplete mediation
(so the attacker knows precisely where to strike) and ambiguous
identifiers (so the attacker knows precisely how to overcome the
intended protection).

Let's suppose that SELinux and AA are both widely deployed and used, and
attackers therefore craft attacks targeting each of them.  In the
SELinux case, let's say they find a flaw in the policy configuration,
and exploit it.  Solution?  Improve the policy configuration.  No
mechanism change required.  In the AA case, same issue applies to
situations where only the profile is in error.  But if the attacker
exploits the absence of mediation of a given operation in AA, or
exploits the use of ambiguous identifiers, then there is no fix for AA
without revisiting the base mechanism, and in the latter case at least,
revisiting the design.  See the difference?  That's not to say that
people won't find flaws in each, but the question is whether one is
fundamentally limited by design, and whether this means that ultimately
AA will cease to be relevant as a protection mechanism because attackers
will simply evolve to attack its inherent limitations.  I don't see an
evolutionary path for AA; it is a dead end by its own design.

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/