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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2006-04-26 at 16:06 -0700, Ken Brush wrote:
> On 4/26/06, Neil Brown <[email protected]> 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.  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.

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

-- 
Stephen Smalley
National Security Agency

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux