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)