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 12:59:31 -0400 [thread overview]
Message-ID: <20250319165931.GD1061595@mit.edu> (raw)
In-Reply-To: <Z9rbDdLr0ai-UFE_@itl-email>
On Wed, Mar 19, 2025 at 10:55:39AM -0400, Demi Marie Obenour wrote:
> What kind of performance do the existing solutions (libguestfs, lklfuse)
> have?
For most of the use cases that I'm aware of, which is to support
occasional file transfers through crappy USB thumb drives (the kind
which a nation state actor would to scatter in the parking lot of
their target), the performance doesn't really matter. Certainly these
are the ones which apply for the Android and ChromeOS use cases.
I suppose there is the use case of people who are running Adobe
Lightroom Classic on their Macbook Air where they are using an
external SSD because Apple's storage pricing is highway robbery, but
(a) it's MacOS, not Linux, and (b) this is arguably a much smaller
percentage of the use case cases in terms of millions and millions of
Android and Chrome Users. Most of the more naive Mac users probably
just pay $$$ to Apple and don't use external storage anyway. :-)
> There are other options, like "run the filesystem in a tightly sandboxed
> userspace process, especially compiled through WebAssembly". The
> difficulty is making them sufficiently performant for distributions to
> actually use them.
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.
I'll also note that since you are mentioning Chrome OS and Android a
lot, there seems to be a lot of interest in using VM's as a security
boundary (see CrosVM[1] which is a Rust-based VMM). So it's likely
that this infrastructure would be available to you if you are doing
work in this area.
[1] https://github.com/google/crosvm
Cheers,
- Ted
next prev parent reply other threads:[~2025-03-19 16:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2025030611-CVE-2025-21830-da64@gregkh>
[not found] ` <20250310.ooshu9Cha2oo@digikod.net>
[not found] ` <2025031034-savanna-debit-eb8e@gregkh>
2025-03-10 23:42 ` CVE-2025-21830: landlock: Handle weird files 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 [this message]
2025-03-19 17:32 ` Demi Marie Obenour
2025-03-19 20:11 ` Theodore Ts'o
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=20250319165931.GD1061595@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).