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

[Ken Brush]

On 4/27/06, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
> On Wed, 2006-04-26 at 16:06 -0700, Ken Brush wrote:
> > On 4/26/06, Neil Brown <neilb@xxxxxxx> wrote:
> > >
> > > I feel we have reached the stage where the questions/comments being
> > > made are actually directly relevant to AppArmor.  I'm afraid I cannot
> > > proceed any further now because I am not a security expert.
> > >
> > > I would like to summarise what I think are the key points that you
> > > have raised, and hope that someone who has a deeper understanding of
> > > these things might answer them, or point to answers.
> > >
> > > 1/ Does AppArmor's primary mechanism of confining an application to a
> > >   superset of it's expected behaviour actually achieve its secondary
> > >   gaol of protecting data?
> > >
> > >   Possibly it would be better to ask "When does ..."  as I think it is
> > >   easy to imagine application/profile pairs that clearly cannot allow
> > >   harm, and application/profile pairs that clearly could allow harm.
> >
> > Depends on the data. A properly constrained Apache webserver would be
> > prevented from accessing data it shouldn't.
>
> No, it wouldn't.  The question itself is flawed - it presumes that AA
> does confine the application to its expected behavior.

I can confine a process to my idea of it's expected behavior.

> But with
> incomplete mediation and ambiguous identifiers, there is no such
> guarantee.  No profile will meet the "clearly cannot allow harm"
> definition, because not all operations are controlled by it and of the
> operations that are controlled, the actual objects are not clearly
> identified, so harm is still possible.
>

I can guarantee that if my profile does not allow write access to /etc
that apache's write to "/etc/new_file" will not be allowed.

The argument that somehow someone would setup a soft link or something
so that apache could write to /etc via indirection is not my primary
concern.  That is systematic of a more concerted attack and a very
determined attacker.  Or at the very least, a mistake on my part. And
in that case, I cannot protect myself from myself.

> > > 2/ What advantages does AppArmor provide over techniques involving
> > >    virtualisation or gaol mechanisms?  Are these advantages worth
> > >    while?
> >
> > If you just wish to run every application in a chrooted jail. Would
> > you still need a MAC solution?
>
> If your goal is purely isolation, then virtualization may fit your
> needs.  If you want to support controlled sharing of data while still
> ensuring that certain confidentiality and integrity goals are met, then
> you want a MAC mechanism.  But AA really isn't a MAC mechanism, despite
> what its documentation may say.

I have no requirements like that. I just would prefer that when people
try to exploit my internet services, that the programs are not allowed
to do things that I would rather it not do. AA seems to fulfill that
requirement.

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