On Mon, Jul 24, 2023 at 11:45:26AM -0400, Solomon Peachy via devel wrote: > 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.) While in-person attackers are real, IMHO that are not the big risk factor for the general populace. I wasn't claiming this was a perfect solution, just that it addresses some easy low hanging fruit, where you have no clue what will be on a new drive you receive (whether purchased online, or as a swag at a trade show, etc). > (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.) Yes there are some lame vendors, that don't burn unique serials, which will make it imperfect. IMHO it is still credible to use the vendor/product/serial despite that. > > 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 you prompt a user every single time, all that results is training the user to press 'yes' without looking. To be useful the prompts need to only happen in unusual circumstances, that are infrequent enough to avoid training an instinctive response. > 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) Accidental corruption is indeed important, and wouldn't be solved by prompting. Protecting against that I think requires taking the libguestfs approach of mounting in an isolated guest OS kernel. In terms of malicious files, I think that not trusting newly seen devices is a valid strategy. There's plenty of documented cases where new devices had malware pre-installed. Re-formatting newly seen devices means the user only needs worry about their own usage from that point onwards, bringing in malware. 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
