Re: Restricting automounting of uncommon filesystems?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

-Steve

_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux