LWN: Comments on "Unprivileged filesystem mounts, 2018 edition"

Unprivileged filesystem mounts, 2018 edition

ssmith32 — Fri, 24 Aug 2018 19:21:11 +0000

I kind of feel like, once you've convinced the user to install your software, convincing them to type in their admin password is not far behind, and, at that stage, why rely on a vulnerability to do something?

lklfuse

fest3er — Mon, 13 Aug 2018 03:52:02 +0000

... and well we all know that "the good enough is the enemy of the best".

Brings to mind Brian Wilson's quip: "Beware the lollipop of mediocrity; lick it once and you'll suck forever."

Unprivileged filesystem mounts, 2018 edition

philipstorry — Thu, 21 Jun 2018 21:33:13 +0000

I'd imagine that IBM offered it so that their customers could migrate to Linux.

It's curious to hear you call JFS a "me-too", as it predates the Linux kernel by over a year. (It originated with IBM's AIX systems in 1990, was later ported to OS/2, and finally to Linux.)

It's actually quite a nice filesystem for general use. It's got metadata journalling, uses extents and allocation groups, and has a reputation for being fast even under heavy loads whilst not consuming much CPU or memory itself.

XFS is probably the filesystem it's most natural to compare JFS to, as they have similar core features and were both ported to Linux at around the same time in 2001. It's also an OS that came from an old UNIX (IRIX) and is only three years younger than JFS, so understandably has a number of similar design decisions. It seems both were pretty cutting edge for the early 1990's!

I wasn't terribly involved with Linux back in 2001 when they were both ported, but it seems that XFS rapidly won the mindshare battle - it accrued more developers around it. Perhaps that's because SGI were more open to contributions from other developers than IBM were? Or maybe it's because its 64-bit on-disk structure gave it higher headline stats in terms of maximum sizes?

Certainly one of the things I've recently admired about JFS is that it's very much in "maintenance mode" these days. That may not be exciting or sexy, but it does make it attractive it you're looking for reliability. I suspect that the unchanging nature of JFS is why it tends to get discounted - it's not adding new features, but the ones it has are well implemented and reliable. But the tech industry and community likes the shiny new things, and JFS lost its shiny new feel over a decade ago.

Now it's simply a reliable workhorse.

The main reasons to avoid it are either feature requirements (and they're more likely to be COW based) or simply the concern that at some point it may be deprecated due to its inactivity. That sort of concern is kind of a self-reinforcing feedback look really, and I suspect it's started to happen already.

However, it's served three different operating systems well, and is still a viable choice for many purposes. It's a pity JFS doesn't get a little more respect...

Unprivileged filesystem mounts, 2018 edition

mstone_ — Wed, 20 Jun 2018 18:56:32 +0000

I've lost data to JFS. I'm also not really sure why it exists other than as a me-too from IBM as it offered nothing that wasn't available in other linux filesystems.

lklfuse

nix — Fri, 08 Jun 2018 15:03:18 +0000

Also being free, and more-or-less portable, and not having PR1ME's, uh, reputation for eccentricity and fairly terrible marketing probably helped. Network effects kicked in from that point on: we already have Unix software, we don't want to massively rewrite it... the only option is another Unix.

lklfuse

Wol — Thu, 07 Jun 2018 07:08:47 +0000

That's always felt pretty arrogant to me.

Pr1mos was a Multics derivative, and I've always felt that in MANY ways it was better than Unix. Unix (in the form of BSD) just happened to be free, and gained traction, and well we all know that "the good enough is the enemy of the best".

Cheers,
Wol

Safely mounting random images: Use a VM?

robbe — Tue, 05 Jun 2018 12:49:07 +0000

You’re basically echoing Ted’s suggestion from
https://lwn.net/Articles/755669/

As to FUSE always playing catch-up, why not flip that around for filesystems like FAT, which are mounted untrusted in the *majority* of uses (e.g. the mentioned automount-my-usb-stick)? The in-kernel FAT implementation would be relegated to legacy status, while distributors made sure that the automount would set up a userspace equivalent (FUSE, or gvfs, or whatever).

That wouldn’t work out for the container case, though.

Safely mounting random images: Use a VM?

david.a.wheeler — Mon, 04 Jun 2018 14:55:38 +0000

There seems to be two fundamentally different ways of using a "disk" image. One is using a trusted image as fast as possible, and the other is one you don't trust. In many circumstances the image is trusted, so it makes sense that the "one you don't trust" has never gotten an adequate amount of effort.

FUSE, as far as I know, doesn't support all the options and features you'd want, and it's always playing catch-up. You can't run a different kernel in a container, either.

The only "easy safe way" I see to access a disk image you don't trust is to run a VM to access the drive and has no other access (in particular, no external network). Then "share" it over a simulated network that only has internal access. This does trust that the VMM is adequately protected, but that has a chance. Then you can run the *native* kernel code to read it. If the system gets broken into, you only get the VM & what it can see.

That's a pretty heavyweight approach. Is there a better one?

Unprivileged filesystem mounts, 2018 edition

stevan — Sat, 02 Jun 2018 10:27:19 +0000

Personal experience - JFS remains the only filesystem from which I have never lost data, though I have not used BTRFS or ZFS in anger. It's old and relatively unloved, but seems to work at human-manageable-scale systems. Data loss leaves lasting scars.

lklfuse

smurf — Fri, 01 Jun 2018 12:51:30 +0000

The point is, 9P does work. So does FUSE … has anybody done an in-depth comparison of these protocols?

Unprivileged filesystem mounts, 2018 edition

ehiggs — Fri, 01 Jun 2018 08:23:00 +0000

Sure. Here are some CVEs that demonstrate how maliciously crafted dmg files are indeed a potential attack vector:

https://www.cvedetails.com/cve/CVE-2018-4176/
https://www.cvedetails.com/cve/CVE-2015-7110/

lklfuse

bendystraw — Thu, 31 May 2018 11:52:51 +0000

We'd be so lucky.

Unprivileged filesystem mounts, 2018 edition

bendystraw — Thu, 31 May 2018 11:51:44 +0000

JFS is great; it's without a doubt my favorite file system for my OS/2 cluster.

lklfuse

k3ninho — Thu, 31 May 2018 10:03:19 +0000

It's heartening to know that 'those that don't learn from history end up reinventing UNIX' has moved on to reinventing what the UNIX team invented next: everything-is-a-file plus programs-are-servers is 9P and has similarities in any message-passing distributed system, notably microservices in containers.

K3n.

lklfuse

dgm — Thu, 31 May 2018 07:55:51 +0000

Funny how, the more Linux advances, the more it resembles Plan 9.

Unprivileged filesystem mounts, 2018 edition

ncm — Thu, 31 May 2018 01:50:06 +0000

The set Z for which "Zi is a pretty terrible security boundary" does not hold is small enough as to be statistically negligible. The burden of proof is on anyone asserting that some Zj is in that set.

Sshd (with password and challenge-response authentication turned off) might be in the set. Anything not specifically designed to be in Z can safely be assumed not to be.

Unprivileged filesystem mounts, 2018 edition

rahvin — Wed, 30 May 2018 23:39:31 +0000

How would you rate JFS in comparison?

Unprivileged filesystem mounts, 2018 edition

roc — Wed, 30 May 2018 23:16:56 +0000

Would be good to know why Ted T'so said "FUSE is a pretty terrible security boundary." So far I think he hasn't explained it in the thread.

Unprivileged filesystem mounts, 2018 edition

Paf — Wed, 30 May 2018 22:30:27 +0000

That’s really a pretty big question, but as someone who works on a file system and follows related news, here’s my sense of the zeitgeist.

I can think of three broad types worth addressing.

For traditional extent based file systems on Linux, EXT4 and XFS are clearly best of breed. There is an emerging consensus among enterprise distributions in favor of XFS as the default, if that helps, but neither is dramatically superior in general.

I can’t speak to log structured except to say that those are mostly built in to flash devices rather than used directly.

For copy-on-write, there are three real choices. ZFS, almost certainly best of breed but with complex legal issues, BTRFS, which you can get various answers on the readiness of, and bcachefs which is compelling but pretty clearly still too new.

lklfuse

phh — Wed, 30 May 2018 16:30:56 +0000

> that it lacks support for many important filesystem types.

On the list of supported FS by FUSE, technically there is lklfuse which makes it possible to mount any FS supported by Linux
I like the FUSE-only approach, because it makes the surface of attack fairly small. Then Ts'o suggestion is basically to replace FUSE with 9P. Yeah sure, whatever works I guess.

Unprivileged filesystem mounts, 2018 edition

rahvin — Wed, 30 May 2018 16:25:21 +0000

Not related to the article so I apologize in advance.

Given the advancement in older filesystems over the last few years how would those developers rate these older filesystems like JFS, XFS, ext4 and others for being the most advanced and development mind-share. It appears that XFS has the most mind share and appears to be advancing the fastest but this could be because of Redhats other efforts, I'm curious what other think.

My concern is probably that there is a LOT of older information out there on what filesystem is best in what circumstances, etc that may no longer be relevant as a particular filesystem has seen more work than others.

Unprivileged filesystem mounts, 2018 edition

ms-tg — Wed, 30 May 2018 16:07:43 +0000

Out of curiosity, does anyone know to what extent the same vector to privilege escalation attacks (allowing local non-admin users to mount a CD or USB) exist today on Mac OS or Windows?

On Mac OS in particular, is it possible to construct a malicious .dmg file using these principles, since Mac users typically mount those disk images to install software?