LWN: Comments on "Filesystem mounts in user namespaces — one year later"

Filesystem mounts in user namespaces — one year later

mgedmin — Tue, 06 Sep 2016 07:52:12 +0000

Nitpick: nobody is uid (u16)-2, i.e. 65534.

Filesystem mounts in user namespaces — one year later

sourcejedi — Thu, 25 Aug 2016 08:51:56 +0000

I don't think INVALID_UID is actually -1. UIDs are unsigned 32-bit ints. So it's not the well-known `nobody` user ((u16) -1), but it's the equivalent for 32-bit UIDs.

Filesystem mounts in user namespaces — one year later

cavok — Mon, 22 Aug 2016 15:29:31 +0000

He clearly knows the right end of the Zap-O-CVE.

Filesystem mounts in user namespaces — one year later

ebiederm — Sat, 20 Aug 2016 23:48:05 +0000

The primary target for now remains fuse.

We may be able to support other filesystems eventually but fuse should be supportable now.
Do you have any fuzz testing with respect to fuse?

The work of handling the odd cases was performed with respect to the vfs and not fuse as the necessary changes are cleaner and more obvious that way.

Fuse presents a very interesting case as it allows isolating the filesystem code in userspace while still allowing that code to be used by all programs through the vfs.

Fuse can support all of the popular filesystems today, and as such provides a safer alternative to mounting filesystems on usb sticks. The user namespace mount aspect of this just this all more usable.

Filesystem mounts in user namespaces — one year later

thomas.poulsen — Sat, 20 Aug 2016 05:46:39 +0000

This situation appears similar to that of network filesystems. If a filesystem is exported to the local network, anyone who is root on a box on the network can mount it and create many of the same problems described here. Perhaps some of the concepts from nfs like exports and usermappings can be used in the user namespace situation.

Filesystem mounts in user namespaces — one year later

flussence — Fri, 19 Aug 2016 21:13:42 +0000

> As long as mounting a filesystem has been a privileged operation, that has not normally been a problem; getting an administrator to mount a random ext4 or XFS filesystem image can take quite a bit of social engineering.

Step 1: insert the provided BadUSB device.
Step 2: click the /media/not-evil-I-promise icon that appears in the file manager.
:)

Filesystem mounts in user namespaces — one year later

vegard — Thu, 18 Aug 2016 08:57:30 +0000

> Most Linux filesystems are simply not designed to be robust in the face of deliberately hostile on-disk filesystem images.

> Hardening filesystems against attacks from below is not a simple matter; such hardening has never been a design goal for the filesystems in common use.

We're still working on getting our filesystem fuzzing-with-AFL code out (http://lwn.net/Articles/685182/) but currently it does not take more than a few hours to find kernel-crashing bugs in any of the most widely used filesystems (ext4, xfs, btrfs, etc.). Several other filesystems crash in a matter of seconds under our AFL-based fuzzer.

I've looked more closely at ext4 myself and trying to fix the bugs that came up (http://lists.openwall.net/linux-ext4/2016/07/14/5, http://www.spinics.net/lists/linux-ext4/msg53166.html) and Bo Liu has been fixing quite a few bugs in btrfs. Other filesystems are on the roadmap but the sheer volume of issues means we don't have the manpower/bandwidth to fix everything at once.

Even so, these are only the bugs found by fuzzing. I can't find the link right now but I think there was a paper where somebody deliberately inserted bugs in the code and tried to discover them with coverage-guided fuzzing and it still only found some 10% of the bugs.

In light of all this, I would be extremely wary of enabling unprivileged mounts. Automatic mounting of external media (still enabled by default on most desktop distros) is already quite bad enough.

Filesystem mounts in user namespaces — one year later

bronson — Thu, 18 Aug 2016 06:13:54 +0000

> To avoid excessive consumption of CVE numbers

Love Corbet writing.