Very true, of course. I just meant (non-gov/non-insider) "hackers." But
of course anyone concerned about gov/insider adversaries performing this
kind of DoS should not rely on a remote server unless it's maintained by
themselves or someone they personally trust.
>>> But if you really wish to address your specific problem -- just use
>>> usbvm as your backup vm whenever you backup onto a usb disk, and use
>>> some other vm for uploading to a remote server.
>> Just to make sure I'm following you: Do you mean to perform every backup
>> twice, sending one copy to the usbvm and the other copy to the backupvm?
>> (Assuming you want to store every backup file both locally and in the
>> cloud.) I suppose that's a pretty good compromise, since you can just
>> delete the copy in the backupvm (after uploading) to save disk space,
>> and the backup creation process is pretty fast.
(I just realized that qvm-copy could also be used here, as well.)
> I just meant that if that bothers you that a USB attack might steal your
> network storage login credentials, then just use a separate VM to backup
> to a USB device (whenever you feel like backing up to a USB device), and
> a separate one to upload to the cloud (whenever you feel like uploading
> to the cloud). The VM that plays a rols of a backup vm doesn't need to
> be special in any way, so anything can be a backup VM (well a
> Linux-based AppVMs that is).
>> But does this mean that it is indeed "insecure" to pass a USB block
>> device through to an AppVM, in the sense that any attaching a USB stick
>> to the "vault" VM while the usbvm possesses the USB controller
>> effectively makes the "vault" VM as untrusted as the usbvm? If so, we
>> should probably add more explicit warnings in the wiki against this
>> (though we've already been warning against similar behavior for a quite
>> a long time now).
> Passing a block device might be insecure, because e.g. the filesystem
> metadata on this device might be malformed and tried to exploit some bug
> in the dest AppVM's kernel.
Indeed, or perhaps even more likely: A piece of malware could be written
to the device in the usbvm and executed in the dest VM (either by some
auto-preview or by an unsuspecting user, e.g., if the file replaces a
previously "trusted" file with the same name).
I assume this is possible because I just now created a file on a USB
stick in my usbvm which then showed up in the AppVM to which the same
USB stick was attached (after remounting). (Actually, now that I think
about it, the fact that this is possible was probably already blatantly
obvious to everyone except me. :) )