Filesystem mounts in user namespaces

Posted Jul 30, 2015 6:13 UTC (Thu) by butlerm (subscriber, #13312)
Parent article: Filesystem mounts in user namespaces

It ought to a be a goal of every filesystem implementation for any kind of corruption to a filesystem image, whether the filesystem is mounted or not, to yield no side effects outside of the data and metadata returned to clients of that filesystem. No crashing, no hanging, no unbounded resource consumption, etc. Otherwise the entire system is at risk from much more mundane causes than a direct attack.

If those conditions are met, does it really matter if a filesystem mounted inside a user namespace is corrupt in every other way?

to post comments

Filesystem mounts in user namespaces

Posted Jul 30, 2015 7:34 UTC (Thu) by neilbrown (subscriber, #359) [Link]

> It ought to a be a goal of every filesystem implementation

Certainly, one goal of several including high performance and reliability. Developer resources need to be apportioned to these goals wisely. Guarding against maliciously corrupt media is understandably not high on the list of priorities though (well, it might be for isofs, udf, and VFAT).

One way to get more attention in this areas is start fuzz-testing filesystems and seeing if you can cause mis-behaviour. Without being able to measure improvements, it is hard to motivate them.

Filesystem mounts in user namespaces

Posted Jul 30, 2015 10:39 UTC (Thu) by Fowl (subscriber, #65667) [Link] (10 responses)

I think having the possibility of a malicious attacker able to control much more of the state of the system by supplying the value of every read() call and poke at the filesystem from the other side simultaneously is likely to significantly easier to exploit and defend against.

Maliciously different data between two accesses is not something that could happen before. (modulo maybe network filesystems?)

I know *nix doesn't really love mandatory locking, but maybe it could be appropriate to at least initially restrict mounts to devices/files that can be mandatory locked (ie. limit to single level of untrusted recursion)?

Filesystem mounts in user namespaces

Posted Jul 30, 2015 17:04 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (9 responses)

> Maliciously different data between two accesses is not something that could happen before. (modulo maybe network filesystems?)

It could happen with any filesystem mounted from a USB device. For example, the "USB stick" could actually be an embedded computer emulating a USB stick, and thus able to return arbitrary data for each read.

Filesystem mounts in user namespaces

Posted Jul 30, 2015 23:09 UTC (Thu) by Fowl (subscriber, #65667) [Link] (1 responses)

Indeed. "BadUSB" type devices can do pretty evil things.

However in many scenarios (eg. cloud server) attaching a USB device is a slightly higher bar though, don't you think?

Filesystem mounts in user namespaces

Posted Jul 31, 2015 2:38 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

The ability to attach a USB device is a higher bar. I was simply pointing out that this situation is not unprecedented. There are scenarios where untrusted users with limited, supervised physical access are expected to be able to plug in their own USB storage devices without compromising the entire system. Any data coming from a removable drive ought to treated as unsanitized input. For that matter, applying the same rule to non-removable drives would help to improve robustness in the face of data corruption.

Filesystem mounts in user namespaces

Posted Aug 6, 2015 15:55 UTC (Thu) by Wol (subscriber, #4433) [Link] (6 responses)

Or indeed, any hard drive ...

Just as USB sticks have been programmed to be malicious, the same attacks have been shown to work by reprogramming a hard drive's firmware.

If you can't trust the hardware, you're stuffed. And most hardware nowadays is "smart" and contains a processor and operating system of some sort - indeed, some hard drives run linux :-)

Cheers,
Wol

Filesystem mounts in user namespaces

Posted Aug 6, 2015 16:59 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (5 responses)

> Or indeed, any hard drive ...

Sure, but unlike USB, untrusted users are rarely permitted access to a SATA or SCSI port. If the user has that level of physical access then there isn't much anyone can do—they could replace the entire system if they wanted—but a Linux-powered kiosk in a public place should be able to read and write user-provided USB storage devices (or SD cards, etc.) without major security issues due to assumptions in the filesystem layer.

Filesystem mounts in user namespaces

Posted Aug 6, 2015 18:35 UTC (Thu) by raven667 (subscriber, #5198) [Link] (3 responses)

That may not be practically achievable because it requires a large body of code to be perfect, which will never happen, given that you can't make a large body of code perfect, what's your next plan for containing the risk? How about a small system which handles the USB and filesystem that passes just the file data over an internal network to the main system, so the actual attack vector against the main system is that file passing network interface which can be made much simpler than all of USB and filesystem drivers.

In most cases people will just eat the risk and deal with the fact that kiosks can be broken into if you try, putting a keylogger on the kiosk might not even reduce its usability such that the owner even cares, certainly not enough to pay more money to increase security.

Filesystem mounts in user namespaces

Posted Aug 7, 2015 2:01 UTC (Fri) by nybble41 (subscriber, #55106) [Link] (2 responses)

> How about a small system which handles the USB and filesystem that passes just the file data over an internal network to the main system...

You mean like a microkernel? Kidding aside, this wouldn't be too hard to do with User-Mode Linux and FUSE. I think there is already a project to allow FUSE mounts of any supported filesystem with UML; it just needs support for disk images backed by libusb.

Filesystem mounts in user namespaces

Posted Aug 7, 2015 2:58 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> You mean like a microkernel?

Haha, we are already well into microkernel territory when we talk about VMs or containers. The whole idea of microkernels is to use the hardware memory protection to enforce separation between services, which is what VMs and containers do, rather than any specific implementation. You could break the system into sections for hardware interaction, sections for user interaction and backend data storage with VMs to enforce the separation.

Filesystem mounts in user namespaces

Posted Aug 7, 2015 15:56 UTC (Fri) by ewan (guest, #5533) [Link]

>You mean like a microkernel?

If you're building a real kiosk it could even be hardware. Taking a photo printing kiosk for example, the USB/SD card readers could be connected to a simple device (even down to the level of an Arduino-esque microcontroller) that then transfers files over a limited interface to the real system that prints things, drives touchscreens, and takes credit card payments.

Filesystem mounts in user namespaces

Posted Aug 7, 2015 0:58 UTC (Fri) by dlang (guest, #313) [Link]

> Sure, but unlike USB, untrusted users are rarely permitted access to a SATA or SCSI port

you haven't noticed that laptops and wireless access points are shipping with external SATA ports on them. In fact, I've seen a few USB3/eSATA combined ports

Filesystem mounts in user namespaces

Posted Aug 6, 2015 16:01 UTC (Thu) by Wol (subscriber, #4433) [Link]

> It ought to a be a goal of every filesystem implementation

It ought to be a goal of every power station to implement a perpetual motion engine and generate free energy ...

Just because it's a sensible goal, doesn't mean it's actually possible to achieve it.

Cheers,
Wol