From fedora-devel-list Sat Jul 22 08:32:01 2023 From: drago01 Date: Sat, 22 Jul 2023 08:32:01 +0000 To: fedora-devel-list Subject: Re: Restricting automounting of uncommon filesystems? Message-Id: X-MARC-Message: https://marc.info/?l=fedora-devel-list&m=169001470908290 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============8067804279272476930==" --===============8067804279272476930== Content-Type: multipart/alternative; boundary="00000000000026a21506010f3772" --00000000000026a21506010f3772 Content-Type: text/plain; charset="UTF-8" On Saturday, July 22, 2023, 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. 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 > --00000000000026a21506010f3772 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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!=3D"block", GOTO=3D"udisks_insecure_fs_end" ENV{ID_FS_TYPE}=3D=3D"hfs", ENV{UDISKS_AUTO}=3D"0"
# repeat as necessary for anything else that shouldn't be automounted LABEL=3D"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 sys= tems are considered uncommon in that context? And aren't most attacks b= ased on file systems used by windows, which makes them "common" ?= (Extfat, NTFS, VFAT)
=C2=A0
_______________________________________________
devel mailing list -- deve= l@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.or= g/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list= _guidelines
List Archives: https://lists.fedoraproject.<= wbr>org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrast= ructure/new_issue
--00000000000026a21506010f3772-- --===============8067804279272476930== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWwgbWFp bGluZyBsaXN0IC0tIGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnClRvIHVuc3Vic2NyaWJl IHNlbmQgYW4gZW1haWwgdG8gZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKRmVk b3JhIENvZGUgb2YgQ29uZHVjdDogaHR0cHM6Ly9kb2NzLmZlZG9yYXByb2plY3Qub3JnL2VuLVVT L3Byb2plY3QvY29kZS1vZi1jb25kdWN0LwpMaXN0IEd1aWRlbGluZXM6IGh0dHBzOi8vZmVkb3Jh cHJvamVjdC5vcmcvd2lraS9NYWlsaW5nX2xpc3RfZ3VpZGVsaW5lcwpMaXN0IEFyY2hpdmVzOiBo dHRwczovL2xpc3RzLmZlZG9yYXByb2plY3Qub3JnL2FyY2hpdmVzL2xpc3QvZGV2ZWxAbGlzdHMu ZmVkb3JhcHJvamVjdC5vcmcKRG8gbm90IHJlcGx5IHRvIHNwYW0sIHJlcG9ydCBpdDogaHR0cHM6 Ly9wYWd1cmUuaW8vZmVkb3JhLWluZnJhc3RydWN0dXJlL25ld19pc3N1ZQo= --===============8067804279272476930==--