[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: Restricting automounting of uncommon filesystems?
From: drago01 <drago01 () gmail ! com>
Date: 2023-07-22 8:32:01
Message-ID: CAMqY-FdPzeyRdS2vGozFY_MbP12WcA-T2c6CZXu0aNKYzsDz+Q () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Saturday, July 22, 2023, Matthew Garrett <mjg59@srcf.ucam.org> 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.
Which file systems are considered uncommon in that context? And aren't most
attacks based on file systems used by windows, which makes them "common" ?
(Extfat, NTFS, VFAT)
> _______________________________________________
> 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
>
[Attachment #5 (text/html)]
<br><br>On Saturday, July 22, 2023, Matthew Garrett <<a \
href="mailto:mjg59@srcf.ucam.org">mjg59@srcf.ucam.org</a>> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">A discussion within Debian again brought up the problem \
that:<br> <br>
1) Automounting of removable media exposes the kernel to a lot of <br>
untrusted input <br>
2) Kernel upstream are not terribly concerned with ensuring that kernel <br>
filesystems are resilient against deliberately malformed filesystems so <br>
are mostly not proactively looking for bugs there<br>
3) Uncommonly used filesystems are less likely to be tested against <br>
adverse input in the real world and so are more likely to contain <br>
exploitable bugs<br>
<br>
There are various cases where people do need to make use of uncommon <br>
filesystems, but the majority of them aren't related to removable media. <br>
udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that<br>
shouldn't be automounted, which means something like:<br>
<br>
SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"<br>
ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"<br>
# repeat as necessary for anything else that shouldn't be automounted<br>
LABEL="udisks_insecure_fs_end"<br>
<br>
ought to be enough. So:<br>
<br>
a) Does this seem like a good idea?<br>
b) If so, is dealing with it via udev rules the right approach? This way <br>
seems desktop-agnostic<br>
c) Where should it ship, and what should the process be for disabling it <br>
for people who need this functionality?<br>
<br>
Long-term I'd love to see more work put into having FUSE support for <br>
these and leaving the in-kernel fs to stuff we know is trustworthy, but <br>
that's rather more work.</blockquote><div><br></div><div>Which file systems are \
considered uncommon in that context? And aren't most attacks based on file \
systems used by windows, which makes them "common" ? (Extfat, NTFS, \
VFAT)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> \
______________________________<wbr>_________________<br> devel mailing list -- <a \
href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br> To \
unsubscribe send an email to <a \
href="mailto:devel-leave@lists.fedoraproject.org">devel-leave@lists.<wbr>fedoraproject.org</a><br>
Fedora Code of Conduct: <a \
href="https://docs.fedoraproject.org/en-US/project/code-of-conduct/" \
target="_blank">https://docs.fedoraproject.<wbr>org/en-US/project/code-of-<wbr>conduct/</a><br>
List Guidelines: <a href="https://fedoraproject.org/wiki/Mailing_list_guidelines" \
target="_blank">https://fedoraproject.org/<wbr>wiki/Mailing_list_guidelines</a><br> \
List Archives: <a href="https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org" \
target="_blank">https://lists.fedoraproject.<wbr>org/archives/list/devel@lists.<wbr>fedoraproject.org</a><br>
Do not reply to spam, report it: <a \
href="https://pagure.io/fedora-infrastructure/new_issue" \
target="_blank">https://pagure.io/fedora-<wbr>infrastructure/new_issue</a><br> \
</blockquote>
[Attachment #6 (text/plain)]
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic