A kernel security hole [LWN.net]

A kernel security hole

Posted Jan 17, 2008 2:08 UTC (Thu) by jamesm (guest, #2273)
Parent article: A kernel security hole

Something to note is that the LSM hooks associated with these checks always used the correct acc_mode variable, so there was potentially some mitigation possible if e.g. using SELinux MAC policy. This was really accidental, and outside the scope of the protection goals of LSMs, but it is not the first time that a kernel bug has been mitigated in this way. It seems that having both DAC and MAC frameworks in the kernel provides some unexpected "defense in depth" benefits.

(Log in to post comments)

A kernel security hole

Posted Jan 17, 2008 9:12 UTC (Thu) by filipjoelsson (subscriber, #2622) [Link]

So, what you're saying is that implementing the same checks twice independently significantly
lowers the risk of this kind of mistake, right? (If the chance of a mistake is 1:1000 - the
chance of the same mistake in both layers is 1:1000000.)

Though this is clearly true, doesn't it implicate a bit of a performance problem? And is every
relevant check implemented twice (ie once in code and once for the security module)?

Or am I completely misunderstanding something?

A kernel security hole

Posted Jan 17, 2008 10:04 UTC (Thu) by jamesm (guest, #2273) [Link]

I don't know if you can generalize things in that way, as it is essentially a side effect of having independent DAC and MAC mechanisms that has been observed a couple of times. Yes, there is a performance hit when you have multiple security mechanisms, but MAC is typically expected to have some impact.