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

List:       fedora-devel-list
Subject:    Re: Restricting automounting of uncommon filesystems?
From:       Solomon Peachy via devel <devel () lists ! fedoraproject ! org>
Date:       2023-07-24 15:45:26
Message-ID: ZL6cljuAhVLUgiYR () shaftnet ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Mon, Jul 24, 2023 at 04:00:21PM +0100, Daniel P. Berrangé wrote:
> 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.

Based on this "threat model" all an attacker has to do then is 
snag/modify/replace your existing drive and then they can pwn your 
system.  That's probably much easier to accomplish than getting you to 
insert a previously-unseen device (the latter has a lot of awareness 
around it, but the "of course I trust this one, it's mine!" will get you 
pwned.)

(Besides, how are you to distinguish the exact stick?  Most of the stuff 
I have lying around here reports the same generic vendor/product/serial 
number.  And drive/volume labels are notoriously unreliable.)

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

Honestly, what makes more sense to me is treat this whole thing purely 
as a usability problem.  Upon insertion, prompt the user to "mount, 
mount reat-only, check, ignore", because at least then we'd get an 
really easy method of fscking a disk without having to do the whole 
unmount dance.  It also provides a mechanism to supply user feedback (eg 
showing fsck results, or the XFS case where you _have_ to mount the 
filesystem to replay the journal before an fsck can be safely run)

If the filesystem is dirty, the dialog always is displayed (with an 
appropriate message recommending fsck), but if it's clean, the user can 
dismiss the dialog with prejudice and have it always accept that drive 
in the future.

We can also provide a hot-key (eg hold down shift when inserting the 
drive) to tell the system to always show the prompt even for previously 
whitelisted devices.

This IMO improves the general usability of the system, instead of making 
things universally worse, while simultaneously providing the hooks 
necessary to implement better security.

Again, let's be realistic about the threat models here -- the 
overwhelmingly common situations are accidental corruption due to 
improper shutdown/ejection, and malicious files on a well-formed 
filesystem (eg ransomware or something that's banking on users having we 
passwordless sudo in place, or curl https://url/setup.sh | sudo bash) 

So let's make things better for those before worry about mitigating APTs 
that need lots of system-specific awareness in order for an attack to 
succeed?

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libra.chat)

["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
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]