LOCK_DOWN_FORCE_INTEGRITY_FOR_FUZZING?

[Dmitry Vyukov]

On Mon, 20 Mar 2023 at 21:36, Paul Moore <paul at paul-moore.com> wrote:
>
> On Tue, Mar 14, 2023 at 6:02 AM Dmitry Vyukov <dvyukov at google.com> wrote:
> >
> > Hi Lockdown maintainers,
> >
> > 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).
>
> The first question I would ask is are there legitimate reasons to
> write directly to a block device that would not impact the integrity
> of the device?  Of course the first thing I think of when I think of
> block devices is a storage device with a filesystem on top, but I'm
> not comfortable enough with my block device knowledge to know what
> other classes of block devices might exist and how one might normally
> interact with them.

That thread mentions tune2fs utility that does this now.


> If storage devices are the only instances of block devices that we
> support, we would also need to be careful that any calls to
> security_locked_down() happen only when userspace is attempting a
> direct write; we wouldn't want to bump into a lockdown access denial
> when the filesystem attempts to write to the block device.
>
> > 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".
>
> It's been a little while, and I can't say I fully understood the
> ppc/pseries RTAS stuff at the time (or now for that matter), but I
> didn't think that the RTAS error injection mechanism was strictly for
> testing, is it?
>
> Regardless of RTAS, if the goal is testing lockdown with syzbot, which
> requires debugfs, why not test a lockdown level that still allows
> debugfs?

My understanding is that only possible to enable these 3 levels:
https://elixir.bootlin.com/linux/v6.3-rc3/source/security/lockdown/lockdown.c#L19
and we want something in-between "none" and "integrity".


> > 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.
>
> Regardless of what we decide wrt to a new level, I think we want it to
> always be present and not dependent on a config knob, either runtime
> or buildtime.

This will work for testing scenarios, but I was worried about production.
It's not supposed to be enabled in production builds, so making it
available can open the door for misconfiguration.