On Mon, Jul 24, 2023 at 10:08:50AM -0400, Demi Marie Obenour wrote: > On 7/24/23 08:47, Richard W.M. Jones wrote: > > On Sun, Jul 23, 2023 at 11:18:45PM -0400, Demi Marie Obenour wrote: > >> On 7/23/23 12:10, Solomon Peachy via devel wrote: > >>> On Sun, Jul 23, 2023 at 11:25:12AM -0400, Neal Gompa wrote: > >>>>> If the system administrator wants to mount $UNCOMMONFS, they should be > >>>>> able to do so without hassle, but that doesn't mean that a normal user > >>>>> who got handed a sketchy USB stick at a conference should be able to do > >>>>> so with no restrictions at all. > >>>>> > >>>> > >>>> So then some kind of configuration to udisks2 to have a similar effect? > >>> > >>> And we're right back at square one, with the *overwhelmingly* common case > >>> of a single-user system whose "admin" is sitting in front of the system. > >>> > >>> Of _course_ they want to mount the disk. It's why they plugged it in, > >>> and they don't give two hoots if it's a "common filesystem" or not. > >>> > >>> (FFS, most of the stuff I personally plug in these days is ext4 or ntfs, > >>> because fat32 sucks and I can't rely on exfat on all systems I need to > >>> interoperate with) > >>> > >>> And let's be realistic here -- the overwhelmingly common threat model > >>> here is that there are untrusted files on a correctly-formed filesystem. > >>> Bad guys rarely need or care to get root on the system; what they're > >>> after requires normal, non-elevated user permissions. > >>> > >>> Prompting users 'are you sure you want to use this device' will turn a > >>> "yes" into an automatic reflex. Not automounting by default will just > >>> add another thing to the "things to change on default fedora > >>> installations" lists out there (ie right after the "enable freshrpms and > >>> install modern video codecs" step), becuase it's a usability nightmare. > >>> > >>> In the "usability vs security" tradeoff, usability/convenience *always* > >>> wins unless you're at a place that has armed guards at the door with > >>> instructions to shoot first. > >>> > >>> - Solomon > >> > >> Then the mount needs to be done in a sandbox, such as a KVM guest or > >> sandboxed userspace process. > > > > This is what libguestfs does (KVM guest). > > > > Rich. > > I saw that libguestfs has a guestmount(1) tool, and I think this could be > a potential solution. An exploit against the kernel FS driver would only > grant access to a KVM guest, and the QEMU process can be tightly sandboxed > by means such as seccomp and SELinux. > > I still believe that mounting should _not_ be automatic, though, because > it could have side-effects (such as replaying the FS journal) that might > not be wanted. To prevent prompt fatigue, Fedora could offer to remember > the user’s choice. Remember the choice per device. If I have a USB flash stick I plug in every day, it shouldn't ask me about that after the first time I use it. If I acquire a new USB flash stick I've never plugged in before, I don't want it auto-mounting before I can wipe & reformat it. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
