[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Restricting automounting of uncommon filesystems?
From:       Eric Sandeen <esandeen () redhat ! com>
Date:       2023-07-23 15:05:40
Message-ID: e16e3a56-cd51-3bd5-05a9-10a1f0b74652 () redhat ! com
[Download RAW message or body]

On 7/22/23 7:57 AM, Michael Catanzaro wrote:
> I've been thinking about this for a while. The status quo is really awful.
> 
> On Sat, Jul 22 2023 at 11:31:22 AM +0000, Zbigniew Jędrzejewski-Szmek 
> <zbyszek@in.waw.pl> wrote:
>> A bigger problem I see, is that if a user plugins in a usb stick,
>> expecting to make use of it, and it's not automounted without any
>> explanation, they are most likely to just click for it to be mounted,
>> or to even issue an explicit 'mount', defeating the whole protection.
> 
> Yup, there's the problem. The user will almost always mount it manually, 
> so disabling automount seems pointless.
> 
>> A more reasonable UI would be to display a pop-up that says "Device
>> ASDF uses file system AmigaFS 1982 which is not well supported. See
>> https://some.link/ for details. Do you want to a) mount once, b) not
>> mount, c) mount this fs type always?". This would require some work
>> in DE.
> 
> The UI would have to not mention technical details like the name of the 
> filesystem. Also, warning a user that the filesystem is not 
> "well-supported" is also not likely to accomplish much. The user plugged 
> in the USB stick in order to look at files, and will almost always 
> choose to do so if presented with the option. Even if we warn that the 
> device may be malicious (which we don't actually know), users will still 
> just think about it and decide "probably not, I want to see my files."
> 
> The desktop security model assumes the kernel is robust to malformed 
> filesystems and removing that assumption is just not workable. This 
> development mindset might be prevalent among kernel developers, but it's 
> not acceptable for desktop users.   Filesystems that are not designed to 
> be robust to untrusted input should be disabled outright and not 
> supported at all. I'm not sure how practical this actually is, though, 
> because I think it would probably entail disabling common filesystems 
> (ext4? xfs? btrfs?) in addition to uncommon filesystems. Starting with 
> disabling uncommon filesystems is better than nothing, though.

mount is a privileged operation in the kernel; when system configuration 
works around that to allow non-trusted users to initiate a mount, that 
breaks the restrictions that the kernel intentionally put on the ability 
to ingest a stream of untrusted data from a block device.

Filesystems generally *do* care about malformed input, but they do so in 
the context of the security model that the kernel defines.

As an example, XFS goes to great lengths to validate input, and placing 
checksums on every piece of metadata is a big part of that. In the real 
world, this validation catches and handles the vast majority of 
malformed/corrupted input that XFS should expect to see.

Other filesystems have similar validation, with similar assumptions.

But when fuzzers intentionally malform metadata and then fix up the 
checksum to look valid, this is something that would never happen 
organically; it is an intentionally malicious work-around to the 
existing mechanism. But again, mount is supposed to be a privileged 
operation, so if the system administrator decides to mount the USB drive 
they found in the parking lot, that's on them, and not a security issue. 
They are root, after all.

Once you let any random user do this, working around the kernel's 
privilege checks, it's a different scenario, and it exposes the system 
to risks that were not part of the original threat model.

I wholeheartedly support any effort to restrict (by default) 
auto-mounting to a smaller set of filesystems that could reasonably be 
expected to be found on removable media (isofs, fat, exfat ...) and shut 
off all the rest to limit the attack surface here. This issue and the 
associated CVEs that get raised have been consuming an inordinate amount 
of time from a very limited set of filesystem developers.

-Eric
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[prev in list] [next in list] [prev in thread] [next in thread]