[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Restricting automounting of uncommon filesystems?
From:       Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange () redhat ! com>
Date:       2023-07-24 14:59:08
Message-ID: ZL6SBXX9Gv0/WP02 () redhat ! com
[Download RAW message or body]

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@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

[prev in list] [next in list] [prev in thread] [next in thread]