I've been thinking about this for a while. The status quo is really
awful.
On Sat, Jul 22 2023 at 11:31:22 AM +0000, Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
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.
Yup, there's the problem. The user will almost always mount it
manually, so disabling automount seems pointless.
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.
The UI would have to not mention technical details like the name of the
filesystem. Also, warning a user that the filesystem is not
"well-supported" is also not likely to accomplish much. The user
plugged in the USB stick in order to look at files, and will almost
always choose to do so if presented with the option. Even if we warn
that the device may be malicious (which we don't actually know), users
will still just think about it and decide "probably not, I want to see
my files."
The desktop security model assumes the kernel is robust to malformed
filesystems and removing that assumption is just not workable. This
development mindset might be prevalent among kernel developers, but
it's not acceptable for desktop users. Filesystems that are not
designed to be robust to untrusted input should be disabled outright
and not supported at all. I'm not sure how practical this actually is,
though, because I think it would probably entail disabling common
filesystems (ext4? xfs? btrfs?) in addition to uncommon filesystems.
Starting with disabling uncommon filesystems is better than nothing,
though.
Michael
_______________________________________________
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
