Messages in this thread | | | Date | Wed, 11 Mar 2020 10:11:15 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH v2] Add kernel config option for fuzz testing. |
| |
On Tue, 10 Mar 2020 07:30:01 +0100 Dmitry Vyukov <dvyukov@google.com> wrote:
> Steve, I am not sure if by lockdown you mean the existing lockdown > mechanism, or just something similar in nature. As Tetsuo pointed, the > possibility of using the existing lockdown mechanism for this was > discussed here (and rejected): > https://lore.kernel.org/lkml/CACdnJutc7OQeoor6WLTh8as10da_CN=crs79v3Fp0mJTaO=+yw@mail.gmail.com/
From Matthew's message a couple of emails earlier:
> Simplicity. Based on discussion, we didn't want the lockdown LSM to > enable arbitrary combinations of lockdown primitives, both because > that would make it extremely difficult for userland developers and > because it would make it extremely easy for local admins to > accidentally configure policies that didn't achieve the desired > outcome. There's no inherent problem in adding new options, but really > right now they should fall into cases where they're protecting either > the integrity of the kernel or preventing leakage of confidential > information from the kernel.
Now, if you are worried that fuzzing will cause harm, or crash the kernel, it sounds to me, whatever fuzzing did would satisfy Matthew's "integrity of the kernel" portion.
In other words, I believe fuzzing folks should be working with the lockdown folks and letting the lockdown folks how root can crash the system. I would think from a security point of view, that if there's a known method to take down the kernel, and I don't want root to be able to do so, we should either fix the kernel to not be able to do so, or if that interface is "you should know what you are doing" then it should be something an admin could lock down to keep other admins who don't know what they are doing from crashing the system.
Or teach the fuzz tool not to do specific bad things.
Honestly, if you just go with a single config to prevent interfaces from crashing the system while running a fuzz test, then you just lowered the usefulness of the fuzz test, as it will never find legitimate cases where that interface crashed the kernel when it should not have.
We are currently trying to clean up the tracing / probing code to not be able to crash the kernel with any interface. It's hard, but it is a goal.
-- Steve
| |