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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
