On 4/20/06, [email protected] <[email protected]> wrote:
> On Wed, 19 Apr 2006 17:19:04 PDT, Crispin Cowan said:
> > [email protected] wrote:
> > > In other words, it's quite possible to accidentally introduce a vulnerability
> > > that wasn't exploitable before, by artificially restricting the privs in a way
> > > the designer didn't expect. So this is really just handing the sysadmin
> > > a loaded gun and waiting.
> > >
> > While that is true of the voluntary model of acquiring and dropping
> > privs, it is not true of AppArmor containment, which will just not give
> > you the priv if it is not in your policy.
>
> The threat model is that you can take a buggy application, and constrain its
> access to priv A in a way that causes a code failure that allows you to abuse
> an unconstrained priv B.
So you are talking about a 2 prong attack. One in where you somehow
trick program A to do something that it's allowed to. That then would
cause an error in program B ? Or cause program B to do something
wonky.
I guess a good example of this would be if you sent an email to
sendmail (which is constrained) to write the message to my mailbox
(which is allowed, obviously).
Then I use an imap daemon (which would not be constrained, in the
hypothetical, personally I constrain everything I can). To retrieve
that message but the payload of the message causes the imap daemon to
delete /lib ?
Is that a proper example? or do you mean something else?
-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]
