Quotes of the week

[Posted March 12, 2025 by corbet]

If we want filesystem corruption CVEs to be any other than security theatre, then we should be using the kernel CVE powers for the reason they were obtained in the first place. i.e. to force downstream distros to address issues they would otherwise ignore to help make our linux systems more reliable and secure.

— Dave Chinner

People have stuff to get done. If you disallow unprivileged filesystem mounts, they will just use sudo (or equivalent) instead. 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, or running it in a sufficiently tight sandbox that vulnerabilities in it are of too low importance to matter.

— Demi Marie Obenour

Microkernels

Posted Mar 13, 2025 1:27 UTC (Thu) by pabs (subscriber, #43278) [Link] (2 responses)

Perhaps a you could take a leaf out of the microkernel book, run Linux as a UML process (or in a VM), mount the untrusted data inside it, export the filesystem as 9p and mount that on the host :)

There is already guestfs for the VM version of that though.

http://libguestfs.org

Another option would be to complete the Linux kernel library project, to allow Linux filesystem code to run in userspace, and then use FUSE to mount the untrusted filesystems within a user namespace sandbox.

https://github.com/lkl

Or perhaps it is going to be the year of Hurd on the desktop soon! (or Redox).

Microkernels

Posted Mar 13, 2025 9:06 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

> Another option would be to complete the Linux kernel library project, to allow Linux filesystem code to run in userspace, and then use FUSE to mount the untrusted filesystems within a user namespace sandbox.

I honestly find it rather baffling that this has not already been done. All sorts of bizarre filesystems are mountable via FUSE, but for some reason you can't mount most "normal" filesystems that way. There's no logical reason for this to be the case - all of the necessary primitives are already exposed to userspace, it's just a matter of somebody writing/porting the FS code, and maybe a little extra faff to deal with the file permissions on /dev/whatever.

Microkernels

Posted Mar 13, 2025 12:45 UTC (Thu) by aragilar (subscriber, #122569) [Link]

I vaguely recall there was a wrapper around user mode linux that did this around 2010 (before udisks2 was more established)? I don't know if it used fuse or not though.