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]

Message-ID: <5a72a7e8-f7fe-4560-0145-02d5570efa34@i-love.sakura.ne.jp>
Date:   Thu, 16 Apr 2020 09:47:24 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
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 2020/04/14 3:13, Linus Torvalds wrote:
> 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.

But I think that starting from build-time config option is the better.

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

We can't beforehand determine how many kernel parameters will be needed.

I don't think the number of kernel parameters is "one". You said "I'd *much*
rather see some way to just lock down certain things individually.". Also,
different fuzzing mechanisms may want different set of things (e.g.
current->do_not_emit_warning_string for syzkaller described bottom).

But will the number of kernel parameters be "a few" ? "a dozen" ?
"some dozen" ? "some hundreds" ? "one thousand" ?

Of course, I'm not expecting "one thousand". But I can't say how many kernel
parameters will be needed. The number of kernel parameters can be determined
only after we identify what "things" we need to tweak. The first step is to
identify which operation should be tweaked, and it will take *very long time*.
I don't think that it is realistic to update userspace programs to support that
flag whenever a new flag was added (with sane name and explanation for users
who are not interested in running fuzzers on their kernels) in the kernel side.

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

I don't think that fuzzing mechanisms is clever enough to distinguish which
process (fuzz tests or _normal_ system binaries) is causing the unwanted
result (e.g. shutting down the system). If administrator's proper operation
(e.g. freezing a filesystem for maintenance purpose) caused a warning (e.g.
khungtaskd complains that file write operation cannot be completed), fuzzing
mechanisms (e.g. monitoring kernel messages printed to consoles) will consider
it as "crash". Since who did "dangerous operation" is irrelevant, who can do
"dangerous operation" (e.g. use of per-process flags) is irrelevant. Doing

--- a/security/tomoyo/util.c
+++ b/security/tomoyo/util.c
@@ -1078,10 +1078,9 @@ bool tomoyo_domain_quota_is_ok(struct tomoyo_request_info *r)
                domain->flags[TOMOYO_DIF_QUOTA_WARNED] = true;
                /* r->granted = false; */
                tomoyo_write_log(r, "%s", tomoyo_dif[TOMOYO_DIF_QUOTA_WARNED]);
-#ifndef CONFIG_SECURITY_TOMOYO_INSECURE_BUILTIN_SETTING
-               pr_warn("WARNING: Domain '%s' has too many ACLs to hold. Stopped learning mode.\n",
-                       domain->domainname->name);
-#endif
+               if (current->do_not_emit_warning_string)
+                       pr_warn("WARNING: Domain '%s' has too many ACLs to hold. Stopped learning mode.\n",
+                               domain->domainname->name);
        }
        return false;
 }

is pointless for syzkaller; syzkaller will treat as "crash" as soon as _normal_
system binaries hit this path. Use of build-time config option is simpler.