On Sat, Jul 22, 2023 at 07:01:34AM +0100, 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?
In general, yes. I think the issue can be summed up as:
if you allow an attacker to plug in and automount a USB with an
arbitrary file system, it's almost certain that they will be able to
make the kernel to undefined behaviour. If the list of filesystem
types is limited to the best-supported file system types, there is a
reasonable chance that the attack will fail. By limiting the list
of fs types, we pragmatically make the attack much harder.
FWIW, systemd merged a patch to do something similar in a different
context: https://github.com/systemd/systemd/commit/80ce8580f5.
> b) If so, is dealing with it via udev rules the right approach? This way
> seems desktop-agnostic
The udev-based approach would work, and is something that could be
used right now. Nevertheless, it's not very user friendly. Some users
will want to override the list, and with the udev-rule-based approach
this is doable but not very convenient.
A bigger problem I see, is that if a user plugins in a usb stick,
expecting to make use of it, and it's not automounted without any
explanation, they are most likely to just click for it to be mounted,
or to even issue an explicit 'mount', defeating the whole protection.
A more reasonable UI would be to display a pop-up that says "Device
ASDF uses file system AmigaFS 1982 which is not well supported. See
https://some.link/ for details. Do you want to a) mount once, b) not
mount, c) mount this fs type always?". This would require some work
in DE.
> c) Where should it ship, and what should the process be for disabling it
> for people who need this functionality?
> 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"
Since those rules are for udisks, I think they should be part of the
udisks package.
If this is done, it'd be much better to make the rule configurable.
So maybe something like this:
SUBSYSTEM=="block", ACTION!="remove", PROGRAM="/usr/libexec/fstype-automount-policy", RESULT=="?*", ENV{UDISKS_AUTO}="$result"
And the program /usr/libexec/fstype-automount-handline would
have a built-in list, but also look for /etc/kernel/fstype-automount.conf
that would include lists like AUTOMOUNT_FSTYPE_ALLOW=
and AUTOMOUNT_FSTYPE_DISALLOW=.
We could then reuse this machinery in other places, not just udisks.
Obiously this is a very rought draft, but I think it should be extensible
and configurable.
> 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.
Yep.
Zbyszek
_______________________________________________
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
