Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks)

[Ken Brush]

On 4/20/06, Valdis.Kletnieks@xxxxxx <Valdis.Kletnieks@xxxxxx> wrote:
> On Wed, 19 Apr 2006 17:19:04 PDT, Crispin Cowan said:
> > Valdis.Kletnieks@xxxxxx 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/