[Apparmor-dev] AppArmor Security Goal 0.5

[John Johansen]

es
On Thu, Nov 08, 2007 at 10:50:20AM -0800, Crispin Cowan wrote:
> John Johansen wrote:
> >> AppArmor is intended to protect systems from attackers exploiting
> >> vulnerabilities in applications that the system hosts. The threat is
> >> that an attacker can cause a vulnerable application to do something
> >> unexpected and undesirable. AppArmor addresses this threat by confining
> >> the application to access only the resources it needs to access to
> >> execute properly, effectively imposing "least privilege" execution on
> >> the application
> > Sorry this just strikes me as the wrong focus.  AppArmor is not about
> > protecting a system from attackers.
> I don't understand this aversion. Talking about what the attacker might
> do and how you can mitigate it is standard in the security literature.
> If there is no attacker, then there is no need for security, so stop all
> this crap. Mechanisms to stop a benign fault instead of a malicious
> attack are very different.
> 
The point being that it doesn't have to be an attacker apparmor is
about containment and resource mediation pure and simple.  It defends
against an attacker by limiting resources, it protects against
benign faults by limiting resources.

Mechanisms to stop benign faults overlap resource mediation just like
methods to stop attacks.  My problem with using the attacker is
that we aren't trying to stop the attacker, like ASLR, or stack guard,
format guard techknowledgies are, AA is about mediating the resources
and thus containing damage an attacker could do and limiting the
resources/avenues he has to escalate an attack.

I know that in the literature the use of attacker is common but the
audience is different here.  Yes mediating resources is a great way to
provide security, by bounding damage, and avenues of attack, and it stops
real attacks, but from a technical point of view the goal is still
just mediation of resources.

> >   It is about containment (sandboxing)
> >   
> If we are going to get all picky about it, AA is not sandboxing.
> Sandboxing is where you make a private copy of stuff the confined app is
> going to use and then confine it, chroot and Java applets being the
> canonical examples. AppArmor is access control. If anything, one could
> say that AppArmor is a targeted policy access control system, but I
> dislike using a term that the SELinux community invented for something
> they see as weak.
>
Okay yes sandboxing has traditionally been used for only private copy
chroot style confinement.  But I have seen it used as controled sharing
too.  Traditional sandboxing systems like chroot, can also use sharing
through mounting devices at multiple points or using bind mounts.
But it is still a sandbox.

You are right that AA is about access control.  I used the
term sandboxing in that each application is stuck in a container
"sandbox" that limits what it can do.  The profile for any given
application doesn't expose the sharing, only that it has resources
to X, Y, and Z.

It is only when we get to total policy analysis that the sharing is
truely exposed.  It is both a strength and a weakness.  A type
enforcement system like selinux forces policy to explicitly control
how the sharing occurs, doing so is advantagous when you want to
completely lock a box down, however it makes policy more combersome
when you only want to lock down a couple apps.

> > which can limit what a program can access under legitimate uses,
> > and contain damage done by a misbehaving program.  Attackers can
> > make a program  misbehave, and the containment may actually stop and
> > attackers as a given attack may rely on resources that are not
> > available.
> >   
> Which is the whole point of doing it. AA is far too much trouble to be
> worth it for any other purpose.
> 
Yes, but that still doesn't change the technical method which is
resource mediation.

I can also profuse to offer security through, several other mean each
with their own technical details.
- perfect code  that has been proven and is analysable with no side effects
- managed code, which restricts memory based attacks.
- overflow canaries and redzones
- encryption
- obscurity
- resource mediation, through duplicate sandboxing or controlled sharing

Each have their strengths and weaknesses and when used for security
purposes the idea of an attacker is implicit.  It comes back to what is
the technical goal of the method.  stack canaries provide a means of
detecting code injections into stack based buffers which is useful for
security because of X.

AA provides resource mediation which is useful for security because it
limits the resources that can be accessed and henced damaged or stolen, and
it limits the avenues of attack which has been shown to stop some real
attacks.

> > I would like to see this document try to avoid the nebulous, attacker
> > and instead focus on containment.  Something more along the lines
> > of
> >
> > AppArmor is intended to provide a sandboxing solution that can limit
> > and control the resources accessable to an application.  The reduced
> > set of accessable resources allows for tighter control on program
> > behavior allowing for the restriction of traditionally acceptable
> > behavior in situations where it is not desirable and containment
> > of damage that can be done by a misbehaving program.
> >   
> I fundamentally disagree. Security is about protecting you from threats,
> and the above misses the point.
> 
It doesn't miss the point it perposely retargets fromt the attacker
which is implicit to the technical goal resource mediation/containment.

> >>     * AppArmor does not slice bread, cure cancer, bring world peace, or
> >>       provide perfect security. This list may be expanded :-
> > while I responded with the perfect security snipe I didn't actually
> > intend it to end up in this document and would prefer it was removed.
> > Looking at the proceeding list of what AA does not address it is
> > blatently obvious that AA does not provide perfect security.
> >   
> I'll take that clause out again, but I want to leave in the silly
> caveat, as it makes an important point, which is the "does not" list is
> incomplete, and cannot be made complete.
> 
yes I am fine with the caveat, I just think that does not provide
perfect security, portion added nothing because it wasn't a technical
limitation and detracted because it was a little snide.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-dev/attachments/20071108/90829183/attachment.pgp