On 7/22/23 08:57, Michael Catanzaro wrote: > 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 A much better solution is: 1. Do not mount automatically. The user might have intended to operate on the drive at the block level, such as to create or validate boot media. Instead, defer mounting until the user looks at the contents of the filesystem. 2. Perform the mount in a **sandboxed** userspace process or even a virtual machine. This is what Chromium OS does and is the only solution that is decently secure. There are all sorts of other problems that need to be addressed as well, such as ensuring that only fuzzed and hardened USB drivers are used. But the mounting restrictions are the first step. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ 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
