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)
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
