[prev in list] [next in list] [prev in thread] [next in thread]
List: fedora-devel-list
Subject: Re: Restricting automounting of uncommon filesystems?
From: Demi Marie Obenour <demiobenour () gmail ! com>
Date: 2023-07-24 14:08:50
Message-ID: 2cfef8e9-5aa1-cd9f-cc96-f1d7b06a3acf () gmail ! com
[Download RAW message or body]
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic