linux-kernel - Re: [PATCH v2] Add kernel config option for fuzz testing.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 Mar 2020 20:23:06 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Jiri Slaby <jslaby@...e.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Garrett <mjg59@...gle.com>,
        Andi Kleen <ak@...ux.intel.com>,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Add kernel config option for fuzz testing.

On Wed, Mar 11, 2020 at 3:11 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Tue, 10 Mar 2020 07:30:01 +0100
> Dmitry Vyukov <dvyukov@...gle.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.

The line crashing the system (for some definition) and
working-as-intended is somewhat fuzzy (no pun intended). E.g. FIFREEZE
is it crashing the system if used uncarefully? Or connecting a USB
keyboard programmatically (which can inject CTRL+ALT+DEL)? Or turning
off console output?


> Or teach the fuzz tool not to do specific bad things.

We do some of this.
But generally it's impossible for anything that involves memory
indirections, or depends on the exact type of fd (e.g. all ioctl's),
etc. Boils down to halting problem and ability to predict exact
behavior of arbitrary programs.


> 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.

I believe "coarse-grained" above refers to something different. We
don't disable whole subsystems (there are usually configs for that
already), but rather we have a single config that does small tweaks to
multiple subsystems (e.g. that single ioctl is disabled, etc). This
allows to still test majority of the subsystem, but just not that
single bit that is harmful.


> 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