[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-26 17:42:10
Message-ID: d5327432-b8e2-8024-7172-5e56011466b7 () redhat ! com
[Download RAW message or body]

On 7/24/23 10:40 PM, Demi Marie Obenour wrote:
> On 7/24/23 15:11, Eric Sandeen wrote:
>> 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
> 
> How much of the problem is the C programming language itself?  I'm NOT
> suggesting that you rewrite your filesystem in Rust; that would be an
> extremely unreasonable request.  I'm merely trying to figure out how
> much of this is a case of "filesystems are hard" and how much of this
> is C providing essentially no help.

Well, this has been discussed but it's obviously not a short-term 
solution. :) (Nor would Rust be a panacea. Some of the problems may be 
mitigated by a language like Rust, but certainly not all of them.)

I think it's a little bit of both scenarios, tbh.

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