Re: Unprivileged filesystem mounts

[Dave Chinner <david@fromorbit.com>]

On Mon, Mar 10, 2025 at 10:19:57PM -0400, Demi Marie Obenour wrote:
> People have stuff to get done.  If you disallow unprivileged filesystem
> mounts, they will just use sudo (or equivalent) instead.

I am not advocating that we disallow mounting of untrusted devices.

> The problem is
> not that users are mounting untrusted filesystems.  The problem is that
> mounting untrusted filesystems is unsafe.

> Making untrusted filesystems safe to mount is the only solution that
> lets users do what they actually need to do. That means either actually
> fixing the filesystem code,

Yes, and the point I keep making is that we cannot provide that
guarantee from the kernel for existing filesystems. We cannot detect
all possible malicous tampering situations without cryptogrpahically
secure verification, and we can't generate full trust from nothing.

The typical desktop policy of "probe and automount any device that
is plugged in" prevents the user from examining the device to
determine if it contains what it is supposed to contain.  The user
is not given any opportunity to device if trust is warranted before
the kernel filesystem parser running in ring 0 is exposed to the
malicious image.

That's the fundamental policy problem we need to address: the user
and/or admin is not in control of their own security because
application developers and/or distro maintainers have decided they
should not have a choice.

In this situation, the choice of what to do *must* fall to the user,
but the argument for "filesystem corruption is a CVE-worthy bug" is
that the choice has been taken away from the user. That's what I'm
saying needs to change - the choice needs to be returned to the
user...

> or running it in a sufficiently tight
> sandbox that vulnerabilities in it are of too low importance to matter.
> libguestfs+FUSE is the most obvious way to do this, but the performance
> might not be enough for distros to turn it on.

Yes, I have advocated for that to be used for desktop mounts in the
past. Similarly, I have also advocated for liblinux + FUSE to be
used so that the kernel filesystem code is used but run from a
userspace context where the kernel cannot be compromised.

I have also advocated for user removable devices to be encrypted by
default. The act of the user unlocking the device automatically
marks it as trusted because undetectable malicious tampering is
highly unlikely.

I have also advocated for a device registry that records removable
device signatures and whether the user trusted them or not so that
they only need to be prompted once for any given removable device
they use.

There are *many* potential user-friendly solutions to the problem,
but they -all- lie in the domain of userspace applications and/or
policies. This is *not* a problem more or better code in the kernel
can solve.

Kees and Co keep telling us we should be making changes that make it
harder (or compeltely prevent) entire classes of vulnerabilities
from being exploited. Yet every time we suggest that a more secure
policy should be applied to automounting filesystems to prevent
system compromise on device hotplug, nobody seems to be willing to
put security first.

> For ext4 and F2FS, if there is a vulnerability that can be exploited by
> a malicious filesystem image, it is a verified boot bypass for Chrome OS
> and Android, respectively. Verified boot is a security boundary for
> both of them,

How does one maliciously corrupt the root filesystem on an Android
phone? How many security boundaries have to be violated before
an attacker can directly modify the physical storage underlying the
read-only system partition?

Again, if the attacker has device modification capability, why
would they bother trying to perform a complex filesystem
corruption attack during boot when they can simply modify what
runs on startup?

And is this a real attack vector that Android must defend against,
why isn't that device and filesystem image cryptographically signed
and verified at boot time to prevent such attacks? That will prevent
the entire class of malicious tampering exploits completely without
having to care about undiscovered filesystem bugs - that's a much
more robust solution from a verified boot and system security
perspective...

> so just forward syzbot reports to their respective
> security teams and let them do the jobs they are paid to do.

Security teams don't fix "syzbot bugs"; they are typically the
people that run syzbot instances. It's the developers who then
have to triage and fix the issues that are found, so that's who the
bug reports should go to (and do). And just because syzbot finds an
issue, that doesn't make it a security issue - all it is is another
bug found by another automated test suite that needs fixing.

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