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