Messages in this thread | | | Subject | Re: [PATCH] kconfig: Add kernel config option for fuzz testing. | From | Tetsuo Handa <> | Date | Fri, 28 Feb 2020 07:10:12 +0900 |
| |
On 2020/02/18 19:54, Tetsuo Handa wrote: > On 2020/01/03 4:57, Matthew Garrett wrote: >> On Tue, Dec 17, 2019 at 12:53 AM Dmitry Vyukov <dvyukov@google.com> wrote: >>> +Matthew for a lockdown question >>> We are considering [ab]using lockdown (you knew this will happen!) for >>> fuzzing kernel. LOCKDOWN_DEBUGFS is a no-go for us and we may want a >>> few other things that may be fuzzing-specific. >>> The current inflexibility comes from the global ordering of levels: >>> >>> if (kernel_locked_down >= level) >>> if (kernel_locked_down >= what) { >>> >>> Is it done for performance? Or for simplicity? >> >> 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. >> > > Can we resume this topic? > > I think build-time lockdown (i.e. kernel config option) is more reliable > and easier to use. >
Here is an example of need to lockdown specific ations. Can we proceed?
https://lkml.kernel.org/r/CACT4Y+azQXLcPqtJG9zbj8hxqw4jE3dcwUj5T06bdL3uMaZk+Q@mail.gmail.com
| |