Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy
> 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). In grsecurity, the oops handling also uses do_group_exit instead of do_exit but both that change (or at least the option to do it) and the exploit handling could be done separately from this without actually needing special treatment for USERCOPY. Could expose is as something like panic_on_oops=2 as a balance between the existing options. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy
> 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. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy
On Fri, Jul 15, 2016 at 12:19 PM, Daniel Micay wrote: >> 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). > > In grsecurity, the oops handling also uses do_group_exit instead of > do_exit but both that change (or at least the option to do it) and the > exploit handling could be done separately from this without actually > needing special treatment for USERCOPY. Could expose is as something > like panic_on_oops=2 as a balance between the existing options. I'm also uncomfortable about BUG() being removed by unsetting CONFIG_BUG, but that seems unlikely. :) -Kees -- Kees Cook Chrome OS & Brillo Security ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [kernel-hardening] Re: [PATCH v2 02/11] mm: Hardened usercopy
On Fri, Jul 15, 2016 at 12:00 PM, Daniel Micay wrote: >> 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
