LOCK_DOWN_FORCE_INTEGRITY_FOR_FUZZING?

[Paul Moore]

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.

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?

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

-- 
paul-moore.com