Using Single External Storage Device with Multiple VMs

[curious...@mailbox.org]

To remain secure, must one use a different external storage devices per VM / security domain? Can one use a single external storage devices to store files from multiple VMs securely, and if so, how?

Is creating multiple encrypted partitions on a USB drive, each only mounted and unlocked in it's relevant VM, a good option? (This would require multiple passphrases and I believe recognizing the relevant partition from it's partition number / size, which seems a lot of effort).

I'm assuming that moving untrusted files between an untrusted VM and a USB drive, and moving trusted files between a trusted VM and the same partition on the USB drive is a breach of security through compartmentalization. Is that correct?

I understand that "Backup Qubes" is the best way to backup and restore multiple VMs, but I just want to move some files between multiple VMs and an external device. I have read the documentation and searched the list but feel like I'm missing something. Many thanks in advance.

[Chris Laprise]

On 2/1/20 4:12 PM, curious...@mailbox.org wrote:
> To remain secure, must one use a different external storage devices per
> VM / security domain? Can one use a single external storage devices to
> store files from multiple VMs securely, and if so, how?

One option is to create a Qubes storage pool on the external drive, then
move some of your VMs to it:

https://www.qubes-os.org/doc/storage-pools/

>
> Is creating multiple encrypted partitions on a USB drive, each only
> mounted and unlocked in it's relevant VM, a good option? (This would
> require multiple passphrases and I believe recognizing the relevant
> partition from it's partition number / size, which seems a lot of effort).

The answer in many of these cases is 'Yes', even without storage pools.
But it can get a little complicated.

Start by reading about 'qvm-block' (or the Devices GUI widget) and how
to attach raw block devices to different VMs. It also helps to know
about Linux storage e.g. how to create and use LUKS volumes.

You can, for example, have a physical disk partition accessible by
sys-usb, then 'qvm-block attach' it to a trusted encryption vm (this
could even be dom0) where 'cryptsetup' is used to format/open/close the
encryption layer. Then create partitions on top of that encryption layer
and use `qvm-block attach' to assign them to various AppVMs where they
are formatted/mounted.

Notice there is a separation of duties where sys-usb isn't trusted and
does the physical access, dom0 insulted from the physical device and
does the encryption, and the AppVMs only see their virtual disk
partitions and the filesystems they use on them.

A simpler approach is to attach partitions directly from sys-usb to your
AppVMs, and let each AppVM handle two layers: encryption and filesystem.
I say this is 'simpler' but this way you'll need to unlock each
partition separately before its mounted.

>
> I'm assuming that moving untrusted files between an untrusted VM and a
> USB drive, and moving trusted files between a trusted VM and the same
> partition on the USB drive is a breach of security through
> compartmentalization. Is that correct?

Yes. But as discussed above, it isn't necessary to do this if all you
want is external storage. You don't have to copy files around.

>
> I understand that "Backup Qubes" is the best way to backup and restore
> multiple VMs, but I just want to move some files between multiple VMs
> and an external device. I have read the documentation and searched the
> list but feel like I'm missing something. Many thanks in advance.

--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[David Hobach]

On 2/2/20 12:40 AM, Chris Laprise wrote:
> On 2/1/20 4:12 PM, curious...@mailbox.org wrote:
>> To remain secure, must one use a different external storage devices
>> per VM / security domain? Can one use a single external storage
>> devices to store files from multiple VMs securely, and if so, how?
>
> One option is to create a Qubes storage pool on the external drive, then
> move some of your VMs to it:
>
> https://www.qubes-os.org/doc/storage-pools/
>
>>
>> Is creating multiple encrypted partitions on a USB drive, each only
>> mounted and unlocked in it's relevant VM, a good option? (This would
>> require multiple passphrases and I believe recognizing the relevant
>> partition from it's partition number / size, which seems a lot of
>> effort).
>
> The answer in many of these cases is 'Yes', even without storage pools.
> But it can get a little complicated.
>
> Start by reading about 'qvm-block' (or the Devices GUI widget) and how
> to attach raw block devices to different VMs. It also helps to know
> about Linux storage e.g. how to create and use LUKS volumes.
>
> You can, for example, have a physical disk partition accessible by
> sys-usb, then 'qvm-block attach' it to a trusted encryption vm (this
> could even be dom0) where 'cryptsetup' is used to format/open/close the
> encryption layer. Then create partitions on top of that encryption layer
> and use `qvm-block attach' to assign them to various AppVMs where they
> are formatted/mounted.

My implementation for that:
https://github.com/3hhh/qcrypt

Anyway it depends on you use case:

If you trust the external device, attaching it to dom0 & additional
encryption against its loss & storage pools are likely the best option.
It's essentially like an internal disk then (the security properties are
very similar). You might want to keep in mind that you should use a
dedicated USB card/PCIE lane or mSata though - otherwise you have a
shared bus with other USB devices that you trust less.

If you don't trust it (you got it used from ebay, regularly give it to
other people or have many enemies in general), you'll want to go the
path outlined by Chris/in my implementation.

[Chris Laprise]

Thanks!

>
> Anyway it depends on you use case:
>
> If you trust the external device, attaching it to dom0 & additional
> encryption against its loss & storage pools are likely the best option.
> It's essentially like an internal disk then (the security properties are
> very similar). You might want to keep in mind that you should use a
> dedicated USB card/PCIE lane or mSata though - otherwise you have a
> shared bus with other USB devices that you trust less.
>
> If you don't trust it (you got it used from ebay, regularly give it to
> other people or have many enemies in general), you'll want to go the
> path outlined by Chris/in my implementation.

BTW, have you thought about a threat model where the whole disk uses a
single encryption key and partitions exist on top of that... and the
possibility that a compromised sys-usb copies some of the blocks from
other partitions into the partition of a compromised/coordinating AppVM?
What are the chances the compromised AppVM would be able to decrypt the
misappropriated blocks? I think many would be inclined to say the disk
cipher salt would protect the copied blocks from improper decryption,
but how certain is this?

[David Hobach]

On 2/3/20 7:12 PM, Chris Laprise wrote:
> BTW, have you thought about a threat model where the whole disk uses a
> single encryption key and partitions exist on top of that... and the
> possibility that a compromised sys-usb copies some of the blocks from
> other partitions into the partition of a compromised/coordinating AppVM?
> What are the chances the compromised AppVM would be able to decrypt the
> misappropriated blocks? I think many would be inclined to say the disk
> cipher salt would protect the copied blocks from improper decryption,
> but how certain is this?

That should be all covered:

Assuming the following single encryption layer structure
sys-usb (compromised)
<-->
appVM (compromised)
your're obviously fully compromised as both the appVM and sys-usb may
simply stop encryption and write plain text data to their attached
volumes. So your additional sys-usb encryption key is totally irrelevant
in that scenario (and thus not in the diagram above; it hides the number
of volumes you use from attackers looking at your external disk though).

The 2 layer encryption
sys-usb (compromised)
<-->
middleVM (not compromised)
<-->
appVM (compromised)
helps against that: appVM may stop encryption to middleVM, but middleVM
will do its job properly to sys-usb (middleVM should be a VM dedicated
to only doing encryption/decryption).

Another 1 layer scenario that you might have thought about:
sys-usb (compromised)
<-->
appVM (compromised)
appVM2 (not compromised)

appVM2 data will remain confidential as it is still doing its own
encryption. Integrity attacks may be attempted by sys-usb (i.e. sys-usb
may change encrypted appVM2 data without looking at the plaintext), but
will be detected by appVM2 (decryption will fail / data be lost) for any
reasonable symmetric cipher mode (mostly non-ECB).
sys-usb may also copy encrypted data from appVM2 to appVM, but neither
sys-usb nor appVM can break the encryption without the key.

Of course all of this assumes perfect VM segregation, no relevant bugs
inside cryptsetup, the Qubes block attachment code & some parts of my
code. So a rather large TCB unfortunately.