Thread (32 messages) 32 messages, 7 authors, 2016-07-15

Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy

From: Kees Cook <hidden>
Date: 2016-07-15 19:14:28
Also in: linux-arch, linux-arm-kernel, linux-mm, lkml, sparclinux

On Fri, Jul 15, 2016 at 12:00 PM, Daniel Micay [off-list ref] wrote:
quoted
This could be a BUG, but I'd rather not panic the entire kernel.
It seems unlikely that it will panic without panic_on_oops and that's
an explicit opt-in to taking down the system on kernel logic errors
exactly like this. In grsecurity, it calls the kernel exploit handling
logic (panic if root, otherwise kill all process of that user and ban
them until reboot) but that same logic is also called for BUG via oops
handling so there's only really a distinction with panic_on_oops=1.

Does it make sense to be less fatal for a fatal assertion that's more
likely to be security-related? Maybe you're worried about having some
false positives for the whitelisting portion, but I don't think those
will lurk around very long with the way this works.
I'd like it to dump stack and be fatal to the process involved, but
yeah, I guess BUG() would work. Creating an infrastructure for
handling security-related Oopses can be done separately from this (and
I'd like to see that added, since it's a nice bit of configurable
reactivity to possible attacks).

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help