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