linux-kernel - Re: [PATCH] kconfig: 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: <CACdnJut=Sp9fF7ysb+Giiky0QRfakczJyK2AH2puJPYWQQKhdQ@mail.gmail.com>
Date:   Thu, 2 Jan 2020 11:57:12 -0800
From:   Matthew Garrett <mjg59@...gle.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Andi Kleen <ak@...ux.intel.com>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Arnd Bergmann <arnd@...db.de>, Jiri Slaby <jslaby@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kconfig: Add kernel config option for fuzz testing.

On Tue, Dec 17, 2019 at 12:53 AM Dmitry Vyukov <dvyukov@...gle.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.