Re: [PATCH] block: Add config option to not allow writing to mounted devices

["Theodore Ts'o" <tytso@mit.edu>]

On Tue, Jun 13, 2023 at 08:49:38AM +0200, Dmitry Vyukov wrote:
> On Mon, 12 Jun 2023 at 18:16, Jan Kara <jack@suse.cz> wrote:
> >
> > Writing to mounted devices is dangerous and can lead to filesystem
> > corruption as well as crashes. Furthermore syzbot comes with more and
> > more involved examples how to corrupt block device under a mounted
> > filesystem leading to kernel crashes and reports we can do nothing
> > about. Add config option to disallow writing to mounted (exclusively
> > open) block devices. Syzbot can use this option to avoid uninteresting
> > crashes. Also users whose userspace setup does not need writing to
> > mounted block devices can set this config option for hardening.
> 
> +syzkaller, Kees, Alexander, Eric
> 
> We can enable this on syzbot, however I have the same concerns as with
> disabling of XFS_SUPPORT_V4:
> https://github.com/google/syzkaller/issues/3918#issuecomment-1560624278
> 
> It's useful to know the actual situation with respect to
> bugs/vulnerabilities and one of the goals of syzbot is surfacing this
> situation.

So from my perspective, it's not a "vulernability".  It's another
example of "syzbot is porting that root can screw you".  The question
about whether the attacker has write access to the block device is a
threat model question.  If you have write access to the block device,
you can set the setuid bit on a copy of /bin/bash; but is that a
"vulernability"?  Not really....

Yes, from the lockdown perspective, what thight might mean is that
"root can run arbitrary code in ring0".  But for most distributions,
given that they allow users to provide custom modules (for exanple,
for Nvidia or other GPU support) that were not built by the
distribution, they can run arbitrary code in ring 0 because root can
provide an arbitrary kernel module.  If you are 100% locked down,
perhaps that's not the case.  But this is a very specialized use case,
and more to the point, asking upstream to worry about this is
effectively an unfunded mandate.


> For some areas there is mismatch between upstream kernel and
> downstream distros. Upstream says "this is buggy and deprecated",
> which is fine in itself if not the other part: downstream distros
> simply ignore that (maybe not even aware) and keep things enabled for
> as long as possible. Stopping testing this is moving more in this
> direction: silencing warnings and pretending that everything is fine,
> when it's not.
> 
> I wonder if there is a way to at least somehow bridge this gap.
> 
> There is CONFIG_BROKEN, but not sure if it's the right thing here.
> Maybe we add something like CONFIG_INSECURE.

"INSECURE" is not really accurate, because it presumes a certain treat
model, and it's not neccessarily one that everyone has signed off as
being one that they need to worry about.

So I'd put it differently.  We need to have a way of filtering out
those syzbot reports which are caused by allowing a privileged user to
be able to dynamically nodify the block device for a mounted file
system.  One way to do that is to simply surpress them.  For example,
we did that when we taught syzbot not to try to set the real-time
priority for a userspace task to MAX_RT_PRIO, which starves kernel
threads and causes the system to malfunction.  That's not a "kernel
bug", that's a userspace bug, and teaching syzbot not to do the stupid
thing made sense.

If you think there are some subset of people who are about syzbot
reports that are caused by dynamically modifying the underlying block
device while it is mounted, what if we can somehow attach a label to
the syzbot report, indicating that it was caused by modifying a
moutned block device?  That way, upstream can ignore it as a stupid
syzbot thing, and you can keep it as a "theoretical vulnerability".
And we don't have to debate the question of which threat model is the
more reasonable one.

						- Ted