linux-kernel - Re: [PATCH v3] Add kernel config option for tweaking kernel behavior.

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:   Mon, 13 Apr 2020 11:13:35 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Garrett <mjg59@...gle.com>,
        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>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [PATCH v3] Add kernel config option for tweaking kernel behavior.

On Sun, Apr 12, 2020 at 11:34 PM Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
>
> Existing kernel config options are defined based on "whether you want to
> enable this module/feature or not". And such granularity is sometimes
> too rough-grained for fuzzing tools which try to find bugs inside each
> module/feature.

I still detest making this a hardcoded build-time config option.

A kernel parameter that sets a flag seems much simpler. More
importantly, having it be something sanely named, and something you
can set independently some other way, would allow a regular kernel to
then run a fuzzer as root.

Some kind of "not even root" flag, which might be per-process and not
possible to clear once set (so that your _normal_ system binaries
could still do the root-only stuff, but then you could start a fuzzing
process with that flag set, knowing that the fuzzing process - and
it's children - are not able to do things).

Honestly, in a perfect world, it has nothing at all to do with
fuzzing, and people could even have some local rules like "anybody who
came in through ssh from the network will also have this flag set".

                 Linus