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]

Message-ID: <20200311101115.53139149@gandalf.local.home>
Date:   Wed, 11 Mar 2020 10:11:15 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Dmitry Vyukov <dvyukov@...gle.com>
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 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.

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