linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Demi Marie Obenour <demi@invisiblethingslab.com>
Cc: Dave Chinner <david@fromorbit.com>,
	cve@kernel.org, gnoack@google.com, gregkh@linuxfoundation.org,
	kent.overstreet@linux.dev, linux-bcachefs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org, mic@digikod.net,
	Demi Marie Obenour <demiobenour@gmail.com>
Subject: Re: Unprivileged filesystem mounts
Date: Wed, 19 Mar 2025 16:11:26 -0400	[thread overview]
Message-ID: <20250319201126.GA1079074@mit.edu> (raw)
In-Reply-To: <Z9r_19pcJCbDxPIQ@itl-email>

On Wed, Mar 19, 2025 at 01:32:59PM -0400, Demi Marie Obenour wrote:
> > I suspect that using a kernel file system running in a guest VM and
> > then making it available via 9pfs would be far more performant than
> > something involving FUSE.  But the details would all be in the
> > implementation, and the skill level of the engineer doing the work.
> 
> Why do you suspect this?  I'm genuinely curious, especially because my
> understanding is that virtiofs (which uses the FUSE protocol internally)
> is considered faster than 9pfs.

I was saying that 9pfs is faster than fuse.  Yes, virtiofs would be
faster than 9pfs.  No question.  However, it might be harder to audit
the virtiofs client implementation given the virtiofs ring buffer
interface to make sure it is free of potential security exploits.9pfs
would be simpler to reassure folks that it is safe(tm).

> The need to resort to virtualization as a security boundary makes me
> wonder if Linux is designed for outdated threat models and security
> paradigms.  Sadly, changing the threat model would be extremely
> expensive today.

I wouldn't say that it's specific to Linux; for many, MANY, MANY
decades, the disk drive was considered within the Trusted Computing
Boundary.  This was true for Multics; VMS; Unix, and other operating
systems that were certified to the Trusted Computing System Evaluation
Criteria (aka the "Orange Book") to the B1 and B2 certification

Ejecting the storage device so it is outside the TCB is a huge change
in the threat model, especially given that for a long time people have
made performance, including simultaneous modifications to the same
file, the primary requirement for most file systems.

If we want to make a single, simple file system that is good enough
for file exchange and backup, where we only need to optimize for
sequental, single-threaded I/O, and for low-cost or moderate-cost
flash devices, that's a much simpler sort of file system that we could
secure against this modified threat model.

However, given how much companies have always been massively stingy
about funding file system development (and these days, anything which
isn't AI :-), I suspect a sandbox/VM approach is going to be a much
more cost effective approach.  But I'm happy to be proven wrong, if
some company is willing to fund the effort --- let's see the names and
we can invite them into the relevant collaboration forums, such as the
weekly ext4 video conference if it's appropriate.

However, just having security people kvetching on open source mailing
lists, or raising syzbot bugs for threat models that the file system
maintainers had never agreed to, and then trying to bully or shame
volunteers to do the work for free is, I would argue, not productive.

Cheers,

					- Ted

  reply	other threads:[~2025-03-19 20:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2025030611-CVE-2025-21830-da64@gregkh>
2025-03-10 12:00 ` CVE-2025-21830: landlock: Handle weird files Mickaël Salaün
2025-03-10 13:49   ` Kent Overstreet
2025-03-10 14:36   ` Greg Kroah-Hartman
2025-03-10 23:42     ` Dave Chinner
2025-03-11  2:09       ` Kent Overstreet
2025-03-11  4:24         ` Dave Chinner
2025-03-11 10:50           ` Kent Overstreet
2025-03-11  2:19       ` Unprivileged filesystem mounts Demi Marie Obenour
2025-03-11  5:57         ` Dave Chinner
2025-03-11 11:01           ` Christian Brauner
2025-03-11 17:36             ` Al Viro
2025-03-11 17:43               ` Kent Overstreet
2025-03-11 17:54           ` Eric Biggers
2025-03-11 20:10           ` Demi Marie Obenour
2025-03-18  5:21             ` Dave Chinner
2025-03-19 14:55               ` Demi Marie Obenour
2025-03-19 16:59                 ` Theodore Ts'o
2025-03-19 17:32                   ` Demi Marie Obenour
2025-03-19 20:11                     ` Theodore Ts'o [this message]
2025-03-18 22:11             ` Theodore Ts'o
2025-03-19 17:44               ` Demi Marie Obenour
2025-03-19 21:25                 ` Theodore Ts'o
2025-03-20  6:26                   ` Demi Marie Obenour
2025-03-20 16:00                     ` Theodore Ts'o
2025-03-11  6:53       ` CVE-2025-21830: landlock: Handle weird files Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250319201126.GA1079074@mit.edu \
    --to=tytso@mit.edu \
    --cc=cve@kernel.org \
    --cc=david@fromorbit.com \
    --cc=demi@invisiblethingslab.com \
    --cc=demiobenour@gmail.com \
    --cc=gnoack@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).