The first half of the 4.17 merge window

Posted Apr 6, 2018 15:18 UTC (Fri) by epa (subscriber, #39769)
In reply to: The first half of the 4.17 merge window by ebiederm
Parent article: The first half of the 4.17 merge window

I guess some filesystems should by default be disabled for removable devices.

The first half of the 4.17 merge window

Posted Apr 6, 2018 15:54 UTC (Fri) by pizza (subscriber, #46) [Link] (25 responses)

For most block devices, the "removable/not-removable" distinction is purely mechanical in nature, and not something that software has any hope of determining.

The first half of the 4.17 merge window

Posted Apr 6, 2018 16:49 UTC (Fri) by droundy (subscriber, #4559) [Link] (24 responses)

True, but the software that decides to automatically mount a USB stick or DVD when it is inserted knows that this is an external device.

The first half of the 4.17 merge window

Posted Apr 6, 2018 17:20 UTC (Fri) by k8to (guest, #15413) [Link] (5 responses)

I'd be perfectly happy with the system as a whole simply never mounting a filesystem without explicit user authorization.
Some kind of fstab entry is reasonable for stable filesystems as an indication of authorization, but for random USB insertions, why not ask the live user if it's OK to mount?

Specialized devices without a traditional user interface might have to get a little creative, of course.

Automounting

Posted Apr 6, 2018 21:36 UTC (Fri) by corbet (editor, #1) [Link] (1 responses)

In fact, some of us turn off the "helpful" desktop code that wants to just go ahead and mount anything that shows up. Automatic mounting is not an inherent Linux feature.

Automounting

Posted Apr 8, 2018 0:05 UTC (Sun) by k8to (guest, #15413) [Link]

Indeed. It was a comment on "recent" trends in Linux desktop implementations. I try to disable all of these, but sometimes I don't get full freedom to reconfigure my laptop before beginning work.

The first half of the 4.17 merge window

Posted Apr 7, 2018 7:11 UTC (Sat) by karkhaz (subscriber, #99844) [Link] (1 responses)

The idea that filesystems are always auto-mounted is totally new to me, none of the laptops or workstation that I own do this. I don't think I did anything special to prevent it, either.

Where does this functionality come from? It's certainly not the kernel that does this. Maybe distributions patch it in, or maybe some of the more heavyweight desktop environments do this on the user's behalf by default?

The first half of the 4.17 merge window

Posted Apr 7, 2018 13:30 UTC (Sat) by pizza (subscriber, #46) [Link]

> Where does this functionality come from? It's certainly not the kernel that does this. Maybe distributions patch it in, or maybe some of the more heavyweight desktop environments do this on the user's behalf by default?

The latter, working in combination with the likes of udisks to detect the media and muck with permissions so that the user can do anything with it.

At least in GNOME's case, it's also completely configurable, including being able to disable it entirely.

The first half of the 4.17 merge window

Posted Apr 8, 2018 12:10 UTC (Sun) by niner (subscriber, #26151) [Link]

FWIW at least KDE requires you to actually click on "Open in File Manager" in the device notifier or on the device in the file manager to actually mount a removable device. So it behaves as you described it should do. I wonder which systems actually do mount automatically without any user participation?

The first half of the 4.17 merge window

Posted Apr 6, 2018 17:30 UTC (Fri) by pizza (subscriber, #46) [Link] (17 responses)

Okay, that's fair, but what exactly is udisks/etc supposed to do instead of mounting the drive? It's not like the user will ever answer "no" to the question "do you want to access the usb stick you just plugged in?"

Granted, udisks/etc could be set up to automatically run fsck on the new filesystems prior to mounting them, but that carries its own set of risks and implications (eg a mechanism to report failures, interactive prompts to allow fixing problems, etc etc...)

Mounting an external drive

Posted Apr 6, 2018 21:42 UTC (Fri) by ebiederm (subscriber, #35028) [Link] (5 responses)

For mounting the drive I would recommend running a file system driver in user space with fuse. I have seen fuse drivers available for most filesystems. That will be quite a bit more robust than using a kernel driver, and the exploit would be less severt. Especially if the filesystem process is sandboxed from the rest of the system.

It definitely makes sense to wait until a user asks. Some devices present as multiple usb devices, sometimes you get confused and plug the wrong device. Waiting for the user to say mount the drive now limits nefarious actions to when a user is actively watching which is more difficult to hide.

So even with in-kernel filesystem drivers that have not been built to be robust against malicious usb sticks there are things you can do that will make an attackers life more difficult.

Mounting an external drive with FUSE

Posted Apr 7, 2018 16:03 UTC (Sat) by alison (subscriber, #63752) [Link] (2 responses)

What is the best way to mount a ext4- or FAT-formatted USB stick with FUSE? 'man mount' and 'man fuse' offer few clues, as does /etc/fuse.conf. 'mount -t fuse /dev/sdc1 /mnt' doesn't work.

I gather that mounting block devices 'noexec' is in sufficient? If the filesystem metadata is, for example, designed to create a stack overflow and 'mount' is executed as root, it's easy to see why there could be a problem.

Mounting an external drive with FUSE

Posted Apr 8, 2018 0:04 UTC (Sun) by pabs (subscriber, #43278) [Link] (1 responses)

There are at least two projects that allow the use of Linux kernel code as user-space shared libraries, perhaps they could lead to the use of Linux kernel filesystem drivers in userland via FUSE.

https://www.phoronix.com/scan.php?page=news_item&px=I...
https://www.phoronix.com/scan.php?page=news_item&px=L...

Mounting an external drive with FUSE

Posted Apr 8, 2018 21:51 UTC (Sun) by OttoErickson (guest, #122996) [Link]

Tanenbaum would be so proud.

Mounting an external drive

Posted Apr 12, 2018 15:14 UTC (Thu) by bfields (subscriber, #19510) [Link]

"For mounting the drive I would recommend running a file system driver in user space with fuse. I have seen fuse drivers available for most filesystems. That will be quite a bit more robust than using a kernel driver, and the exploit would be less severe. Especially if the filesystem process is sandboxed from the rest of the system."

I'd worry that the userspace driver will also get less maintenance. I guess the sandboxing could be pretty restrictive if it literally only needs access to the one device and the fuse interface? On the other hand the ability to return arbitrary data and metadata, unexpected errors, etc., could offer a lot of potential attacks against any application accessing that filesystem.

I don't know, it seems like a hard problem to me.

Every time we have this discussion I have flashbacks to some 30 years ago--weren't removable media (floppies) a primary vector for malware?

Mounting an external drive

Posted Apr 13, 2018 8:03 UTC (Fri) by lacos (guest, #70616) [Link]

"For mounting the drive I would recommend running a file system driver in user space with fuse"

You can also use guestfish or guestmount from the libguestfs project. Those will use kernel drivers, but the kernel will be run in a virtual machine. (In fact, guestmount is a special case of fuse.)

http://libguestfs.org/guestfs-security.1.html
http://libguestfs.org/guestfs-faq.1.html#how-does-libgues...
http://libguestfs.org/guestmount.1.html

The first half of the 4.17 merge window

Posted Apr 7, 2018 0:53 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link] (9 responses)

It's not like the user will ever answer "no" to the question "do you want to access the usb stick you just plugged in?"

That isn't necessarily the case. For example, I occasionally just want to format the device I've just inserted rather than mounting it. Sure, I can just unmount it first, but I might be paranoid enough not to want to mount it at all if it came from a questionable source.

Asking the user would also help in the case of a malicious device that the user doesn't know contains storage at all. Since USB devices are designed to be chained, it's possible for a single physical USB device to contain multiple logical devices. Some devices use this for good- ISTR there are some password storage sticks that contain a virtual keyboard device so they can type passwords into the correct space on forms- but it's easy to see how it could be used for evil. If I think I've just plugged in my USB powered keyboard vacuum and my system asks me if I want to mount the disk, I'm very unlikely to click "OK".

The first half of the 4.17 merge window

Posted Apr 7, 2018 2:12 UTC (Sat) by pizza (subscriber, #46) [Link] (8 responses)

Folks like you and I are several sigmas beyond the mean, and it is extremely foolish to generalize our relatively-clueful paranoia onto the general populace.

It is widely established that users will overwhelmingly say "yes" to any and every prompt confirming potentially risky behaviour. Usually without any conscious thought.

Especially given that the overwhelmingly common case is "Of course I want to access the files on the stick I plugged in! That's why I plugged it in!"

By all means, let's emulate Windows here, perform a quick read-only fsck upon insertion. and prompt if there's a potential problem, but no amount of filesystem-level paranoia will save the user if they click on the file labelled "hot avian pr0n.sh" and get their account (and more importantly, all the data they care about) completely compromised.

The first half of the 4.17 merge window

Posted Apr 7, 2018 12:25 UTC (Sat) by roc (subscriber, #30627) [Link] (2 responses)

One underlying cause of the slow pace of Linux desktop adoption, which you can see in the comments in this article, is that many Linux users and contributors don't much care whether desktop Linux is usable by "the general populace".

The first half of the 4.17 merge window

Posted Apr 8, 2018 9:33 UTC (Sun) by flussence (guest, #85566) [Link] (1 responses)

Linux hasn't exactly done better for lack of an equivalent to Windows XP's “what do you want to do with this device” autorun popup, or the infamous Have Disk prompt of despair for a hotplugged device. Sometimes I wish it did ask me before splatting a .ko into kernel memory in the background for those events; the USB authorization mechanism is already there and sits unused.

Or to put it more simply: I want a PoisonTap to present *at least* the same deliberately terror-inducing UI as I currently get for a self-signed SSL cert. Because one of these things is actually dangerous.

The first half of the 4.17 merge window

Posted Apr 10, 2018 3:47 UTC (Tue) by pabs (subscriber, #43278) [Link]

Install one of these:

https://usbguard.github.io/
https://github.com/kochstefan/usbauth-all/

The first half of the 4.17 merge window

Posted Apr 9, 2018 12:56 UTC (Mon) by cortana (subscriber, #24596) [Link] (3 responses)

Here's my suggestion for UI that will allow power users to confirm mounting without an annoying prompt that will turn off average users.

When you insert a disk, nautilus appears as normal (with the disk selected on the left-hand pane), but instead of the disk being mounted and the files displayed on the main pane, a prompt and button are displayed instead:

  +----------------------------------------------------+
  |            |                                       |
  | Recent     | Mount the device "USB disk"?          |
  | Home       |                                       |
  | Documents  | [x] Remember for this disk            |
  | Downloads  |                                       |
  | Music      | [Mount] [Eject]                       |
  | Pictures   |                                       |
  | Videos     |                                       |
  | Wastebasket|                                       |
  |            |                                       |
  +-USB-disk---+                                       |
  |            |                                       |
  |            |                                       |
  |            |                                       |
  |            |                                       |
  |            |                                       |
  |            |                                       |
  |            |                                       |
  +----------------------------------------------------+

The first half of the 4.17 merge window

Posted Apr 9, 2018 14:44 UTC (Mon) by jem (subscriber, #24231) [Link] (2 responses)

How do you define "this disk"? Is the disk the same after being reformatted? Is it regarded different after the file system has been doctored to exploit a vulnerability?

How do you know what the right answer (mount/eject) to the question is? If you have plugged it in, your intention was to use the disk. Why would you suddenly not want to use it after all?

The problem with removable storage is similar to running executables from an unknown source (except the storage problem is possibly worse, because the file system code is in the kernel). If the disk doesn't come from a trustworthy source, don't plug it in. Also, don't allow strangers to plug in disks at all on machines you are in charge of. I don't see the added value of asking "are you sure?"

The first half of the 4.17 merge window

Posted Apr 9, 2018 17:45 UTC (Mon) by droundy (subscriber, #4559) [Link] (1 responses)

I think the value of asking "are you sure?" is that the user might not have intended to plug in a disk. Perhaps I would like to allow someone to charge their phone using my computer, or I want to borrow a mouse, keyboard, or remote control for giving a presentation at a conference. In none of those cases would I be happy to have the device automatically mounted.

The first half of the 4.17 merge window

Posted Apr 10, 2018 10:25 UTC (Tue) by matthias (subscriber, #94967) [Link]

But you are happy to allow the kernel to automatically register a USB keyboard (or mouse) that can acknowledge the mount dialog? (or type rm -rf / from time to time to annoy terminal users)

Such a dialog would have to appear for every new device, not only mass storage. Furthermore, if you do not trust the device, you should not allow to register any component of the device. Which brings us back to square one: Why should you add a device that you do not trust? Ok, you could try to configure the keyboard (or mouse) that represents the presenter such that it can only forward inputs to the presentation software and not to some terminal or window manager. Is there anyone who really does this?

The bottom line is that you are usually doomed if you cannot trust the hardware that you are using, which is one of the reasons why Unix traditionally ultimately trusts any hardware.

The first half of the 4.17 merge window

Posted Apr 12, 2018 15:02 UTC (Thu) by bfields (subscriber, #19510) [Link]

"Folks like you and I are several sigmas beyond the mean, and it is extremely foolish to generalize our relatively-clueful paranoia onto the general populace.

It is widely established that users will overwhelmingly say "yes" to any and every prompt confirming potentially risky behaviour. Usually without any conscious thought."

Personally, I'm a little less sure that I'm any different from the "general populace".

After I've already clicked "yes" on a hundred of those dialogs, I'm not sure I could count on myself to click "no" on a dubious one.

The first half of the 4.17 merge window

Posted Apr 9, 2018 13:59 UTC (Mon) by bandrami (guest, #94229) [Link]

For 20 years my Linux systems did precisely nothing when I plugged in a USB drive other than register its presence with the kernel (and, later, with the in-memory device filesystem flavor of the week).

They did this because this is The Right Thing To Do when a new removable disk is added. This didn't need to change.