LOCK_DOWN_FORCE_INTEGRITY_FOR_FUZZING?

From: Dmitry Vyukov <dvyukov@google.com>
To: Paul Moore <paul@paul-moore.com>,
	jmorris@namei.org, mjg59@srcf.ucam.org,
	linux-security-module <linux-security-module@vger.kernel.org>,
	nathanl@linux.ibm.com
Cc: syzkaller <syzkaller@googlegroups.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Subject: LOCK_DOWN_FORCE_INTEGRITY_FOR_FUZZING?
Date: Tue, 14 Mar 2023 11:02:16 +0100	[thread overview]
Message-ID: <CACT4Y+Z-9KCgKwkktvdJwNJZxxeA1f74zkP7KD6c=OmKXxXfjw@mail.gmail.com> (raw)

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

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

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.

Thanks