[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 <sandeen () redhat ! com>
Date:       2023-07-24 19:11:14
Message-ID: 8935c6d5-e7ed-0471-ac65-a795e4e4479f () redhat ! com
[Download RAW message or body]

On 7/23/23 7:22 PM, Steve Grubb wrote:
> On Saturday, July 22, 2023 2:01:34 AM EDT Matthew Garrett wrote:
>> A discussion within Debian again brought up the problem that:
>>
>> 1) Automounting of removable media exposes the kernel to a lot of
>> untrusted input
>> 2) Kernel upstream are not terribly concerned with ensuring that kernel
>> filesystems are resilient against deliberately malformed filesystems so
>> are mostly not proactively looking for bugs there
>> 3) Uncommonly used filesystems are less likely to be tested against
>> adverse input in the real world and so are more likely to contain
>> exploitable bugs
>>
>> There are various cases where people do need to make use of uncommon
>> filesystems, but the majority of them aren't related to removable media.
>> udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that
>> shouldn't be automounted, which means something like:
>>
>> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
>> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
>> # repeat as necessary for anything else that shouldn't be automounted
>> LABEL="udisks_insecure_fs_end"
>>
>> ought to be enough. So:
>>
>> a) Does this seem like a good idea?
>> b) If so, is dealing with it via udev rules the right approach? This way
>> seems desktop-agnostic
>> c) Where should it ship, and what should the process be for disabling it
>> for people who need this functionality?
>>
>> Long-term I'd love to see more work put into having FUSE support for
>> these and leaving the in-kernel fs to stuff we know is trustworthy, but
>> that's rather more work.

If "a malicious input can't cause problems" is the threshold for 
trustworthy, I'm not sure we have any trustworthy filesystems as this point.

https://syzkaller.appspot.com/upstream/s/ext4
https://syzkaller.appspot.com/upstream/s/xfs
https://syzkaller.appspot.com/upstream/s/btrfs
https://syzkaller.appspot.com/upstream/s/fat

> A while back, I wrote the fsfuzzer specifically to find, in a repeatable way,
> filesystem bugs so they can be fixed:
> 
> https://github.com/stevegrubb/fsfuzzer
> 
> It does not support all filesystems, but it is easy to add support through
> adding the correct mounter to the scrips. It has found *so* *many* filesystem
> bugs over time.

That was awesome, back in the day! syzbot/syzcaller is the new shiny 
here though, finding filesystem flaws day after day that (with all due 
respect) fsfuzzer could never have reached (think: fuzzing metadata and 
then fixing up the checksum so it passes initial validation on read.)

And frankly that is some of my motivation to find an improvement here. A 
small cadre of filesystem developers are near the breaking point trying 
to keep up with an army of machines running syzkaller.

-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]