Messages in this thread | | | Date | Fri, 21 Apr 2006 08:23:51 -0700 | From | "Ken Brush" <> | Subject | Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks) |
| |
On 4/20/06, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote: > On Wed, 19 Apr 2006 17:19:04 PDT, Crispin Cowan said: > > Valdis.Kletnieks@vt.edu 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |