Re: LOCK_DOWN_FORCE_INTEGRITY_FOR_FUZZING?

[Nathan Lynch <nathanl@linux.ibm.com>]

Hi Dmitry,

Dmitry Vyukov <dvyukov@google.com> writes:
> Hi Lockdown maintainers,

I'm not a lockdown maintainer, but I feel like I can respond to a couple
things here.

> We don't enable Lockdown integrity mode on syzbot during fuzzing, but
> we would like to. The main problem is the restriction of debugfs,
> which we need for fuzzing. But we do duplicate some of its
> restrictions (e.g. DEVKMEM=n).
>
> It come up again recently in the context of discussion of memory
> corruptions when a mounted blocked device is being written to by root:
> https://lore.kernel.org/all/CACT4Y+b1vGfe0Uvp6YmKahK4GfCfvdBLCh0SAQzGgWN1s6A+0Q@mail.gmail.com/
> It looks like this restriction of writing to mounted block devices
> should be part of integrity lockdown (but I am not an expert).

I'm not sure, I'll leave that question to others.

> What do you think about the addition of a new level that is integrity
> but with debug fs access?
> LOCKDOWN_RTAS_ERROR_INJECTION also looks like it's in the same bucket
> of "fine for testing".

Thanks for checking. Error injection via RTAS (pseries partition
firmware) can cause unrecoverable cache and memory corruption. Right now
I don't think including LOCKDOWN_RTAS_ERROR_INJECTION in a relaxed
integrity mode for fuzzing would yield useful results.

> At least for us it is OK if it can be enabled only via kernel config
> (no cmd line) and named accordingly
> (TEST_ONLY_DONT_ENABLE_IN_PRODUCTION).
>
> If we have it, we could restrict writing to mounted devices in
> integrity mode and enable this mode on syzbot.

So I understand the proposal to involve something like:

--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -120,11 +120,12 @@ enum lockdown_reason {
 	LOCKDOWN_TIOCSSERIAL,
 	LOCKDOWN_MODULE_PARAMETERS,
 	LOCKDOWN_MMIOTRACE,
-	LOCKDOWN_DEBUGFS,
 	LOCKDOWN_XMON_WR,
 	LOCKDOWN_BPF_WRITE_USER,
 	LOCKDOWN_DBG_WRITE_KERNEL,
 	LOCKDOWN_RTAS_ERROR_INJECTION,
+	LOCKDOWN_INTEGRITY_FUZZING_MAX,
+	LOCKDOWN_DEBUGFS,
 	LOCKDOWN_INTEGRITY_MAX,
 	LOCKDOWN_KCORE,
 	LOCKDOWN_KPROBES,

Is that right?

I don't have a specific example at hand, but I suspect that enabling all
of debugfs would allow syzbot to reach code that integrity mode
ordinarily would prevent. Which doesn't seem like what you would want?

I wonder if the debugfs-hosted facilities needed by syzbot could be
identified in a finer-grained way that could be incorporated into the
lockdown reason list for this purpose. So that way only the things
syzbot needs would be exposed.