Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

[Dave Chinner <david@fromorbit.com>]

On Wed, Sep 13, 2023 at 10:03:55AM -0700, Linus Torvalds wrote:
> On Wed, 13 Sept 2023 at 09:52, Eric Sandeen <sandeen@sandeen.net> wrote:
> >
> > Isn't it more typical to mark something as on its way to deprecation in
> > Kconfig and/or a printk?
> 
> I haven't actually heard a good reason to really stop supporting
> these. Using some kind of user-space library is ridiculous. It's *way*
> more effort than just keeping them in the kernel. So anybody who says
> "just move them to user space" is just making things up.

No filesystem developer thinks that doing a whole lot of work to
move unmaintained, untestable fs code from the kernel to an
unmaintained, untestable (and likely broken) fs library in userspace
is a viable solution to any of the problems being discussed.

There's a whole lot more to this discussion than "what to do with
old, unmaintained filesystem code".

> The reasons I have heard are:
> 
>  - security
> 
> Yes, don't enable them, and if you enable them, don't auto-mount them
> on hot-pkug devices. Simple. People in this thread have already
> pointed to the user-space support for it happening.

This is just a band-aid. It does nothing to prevent kernel
compromise and is simply blame-shifting the inevitable kernel
compromise to the user because they had to explicitly mount the
filesystem. It's a "security theatre" solution at best.

Indeed, it does not address the frequently requested container use
cases where untrusted users (i.e. root in a container) need to mount
filesystem images.  This is a longstanding feature request we really
need to solve and ignoring it for the purposes of knocking down a
strawman really doesn't help us in any way.

Put simply, what we really need is a trust model mechanism that
allows all the kernel supported filesystems to be mounted by
untrusted users without any risk that the kernel could be
compromised by such an operation.

That's where lklfuse comes into the picture: it allows running the
kernel filesystem parsing code in an isolated userspace sandbox and
only communicates with the kernel and applications via the FUSE
interface.

IOWs, we get *privilege separation* with this lklfuse mechanism for
almost zero extra work on all sides of the fence. The dangerous
stuff occurs in the sandboxed user process so the risk of kernel
compromise is greatly minimised and the user and their applications
can still access it like a normal kernel filesystem.

And because it uses the kernel filesystem implementations, we don't
have a separate codebase that we have to maintain - we get
up-to-date filesystem implementations in userspace for free...

To go back to your original concern about avoiding the removal of
unmaintained filesystems, once we get a robust trust model mechanism
like this in place we we can force them to be mounted through the
supported privilege separation mechanism. Then they can't compromise
the kernel, and the vast majority of the "untested, unmaintained
code that parses untrusted data in kernel space" concerns go away
entirely.

IOWs, if we deal with the trust model issues in a robust manner,
there is much less need for drastic action to protect the kernel and
users from compromise via untestable, unmaintained filesystem code.
Your argument for keeping them around indefinitely *gets stronger*
by addresing the security problems they can expose properly. Hence
arguing against improving the filesystem trust model architecture is
actually providing an argument against your stated goal of keeping
those old filesystems around for ever....

At this point, the only concern that remains is the burden keeping
these old filesystems compiling properly as we we change internal
APIs in future. That's another thing that has been brought up in
this discussion, but....

>  - "they use the buffer cache".
> 
> Waah, waah, waah.

.... you dismiss those concerns in the same way a 6 year old school
yard bully taunts his suffering victims.

Regardless of the merits of the observation you've made, the tone
and content of this response is *completely unacceptable*.  Please
keep to technical arguments, Linus, because this sort of response
has no merit what-so-ever. All it does is shut down the technical
discussion because no-one wants to be the target of this sort of
ugly abuse just for participating in a technical discussion.

Given the number of top level maintainers that signed off on the CoC
that are present in this forum, I had an expectation that this is a
forum where bad behaviour is not tolerated at all.  So I've waited a
couple of days to see if anyone in a project leadership position is
going to say something about this comment.....

<silence>

The deafening silence of tacit acceptance is far more damning than
the high pitched squeal of Linus's childish taunts.

-Dave.
-- 
Dave Chinner
david@fromorbit.com