LOCK_DOWN_FORCE_INTEGRITY_FOR_FUZZING?

[Dmitry Vyukov]

On Fri, 17 Mar 2023 at 16:21, Nathan Lynch <nathanl at linux.ibm.com> wrote:
>
> Hi Dmitry,
>
> Dmitry Vyukov <dvyukov at 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?

Hi Nathan,

Thanks for the feedback.
Yes, something like this + config to enable this mode.

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

Debugfs also contains lots of code that needs to be tested.
It's also required to test production code, e.g. set up some stub devices, etc.
We generally can restrict fuzzer access based on paths (it's also
required to avoid writing garbage into /dev/sda, etc). So far having
debugfs accessible did not cause any problems.