On 4/27/06, Stephen Smalley <[email protected]> wrote:
> 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.
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 [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]
