Support VM private block devices on external media

[DemiMarie]

Qubes OS version:

R4.0

Affected component(s):

Dom0 kernel/storage layer

---

Steps to reproduce the behavior:

Try to find a way to use a USB drive for a certain VM’s private storage

Expected behavior:

There is such a method. Furthermore, Qubes authenticates all data stored on the block device, ensuring that a compromised USBVM or external drive can only cause a denial of service.

Actual behavior:

No such method.

General notes:

The major uses of this involve consultants who work for multiple clients. It is necessary to

1. Ensure that each customer cannot read or modify data belonging to another customer.
2. Ensure that confidential information is securely deleted when the contract expires.

Qubes achieves (1) trivially (put each customer’s data in a separate VM). However, achieving (2) is very difficult on many laptops, which often use solid-state drives. Though one could wipe the drive and reinstall Qubes, this is inconvenient.

An alternative is to put the VM’s private data on an external drive. No VM data is stored on any internal medium, so there is nothing to erase. Furthermore, one can encrypt the external drive using authenticated encryption. This ensures that if the data on the drive is tampered with, it will be detected, and furthermore that if the external drive is compromised, the data on it is not usable.

Obviously, such a VM should be excluded from backups.

---

Related issues:

[marmarek]

See here for info how to put selected VMs on secondary disk. You can use this on an external, LUKS-encrypted disk, connected to dom0 with qvm-block. This isn't very convenient out of the box, but with a short script can be made easier. Especially when you want to disconnect USB, you need to (in order):

1. Shutdown all VMs using that disk
2. Deactivate LVM pool (vgchange -an ...) - if you use one
3. Deactivate LUKS (cryptsetup close ...)
4. Detach device from dom0 (qvm-block dt ...)

This also apply to suspending the system.

[marmarek]

See here for info how to put selected VMs on secondary disk. You can use this on an external, LUKS-encrypted disk, connected to dom0 with qvm-block. This isn't very convenient out of the box, but with a short script can be made easier. Especially when you want to disconnect USB, you need to (in order):

1. Shutdown all VMs using that disk
2. Deactivate LVM pool (vgchange -an ...) - if you use one
3. Deactivate LUKS (cryptsetup close ...)
4. Detach device from dom0 (qvm-block dt ...)

This also apply to suspending the system.

[DemiMarie]

What are the security considerations? In particular, can a malicious USB device compromise dom0?

…

On Sat, Apr 14, 2018, 6:24 PM Marek Marczykowski-Górecki < ***@***.***> wrote: See here <https://www.qubes-os.org/doc/secondary-storage/> for info how to put selected VMs on secondary disk. You can use this on an external, LUKS-encrypted disk, connected to dom0 with qvm-block. This isn't very convenient out of the box, but with a short script can be made easier. Especially when you want to disconnect USB, you need to (in order): 1. Shutdown all VMs using that disk 2. Deactivate LVM pool (vgchange -an ...) - if you use one 3. Deactivate LUKS (cryptsetup close ...) 4. Detach device from dom0 (qvm-block dt ...) This also apply to suspending the system. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3820 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWBy8C_im42jG5C5wNgVa75FoL28iBks5tonc6gaJpZM4TVOxU> .

[DemiMarie]

What are the security considerations? In particular, can a malicious USB device compromise dom0?

…

On Sat, Apr 14, 2018, 6:24 PM Marek Marczykowski-Górecki < ***@***.***> wrote: See here <https://www.qubes-os.org/doc/secondary-storage/> for info how to put selected VMs on secondary disk. You can use this on an external, LUKS-encrypted disk, connected to dom0 with qvm-block. This isn't very convenient out of the box, but with a short script can be made easier. Especially when you want to disconnect USB, you need to (in order): 1. Shutdown all VMs using that disk 2. Deactivate LVM pool (vgchange -an ...) - if you use one 3. Deactivate LUKS (cryptsetup close ...) 4. Detach device from dom0 (qvm-block dt ...) This also apply to suspending the system. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3820 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWBy8C_im42jG5C5wNgVa75FoL28iBks5tonc6gaJpZM4TVOxU> .

[marmarek]

Yes, there is a risk, especially related to malicious metadata on the device. Some of it can be mitigated with appropriate udev rules (for example add rule to set ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}="1" early). You can also disable partition scanning with (echo 1 > /sys/module/block/parameters/no_part_scan). To avoid parsing LUKS header from untrusted device, you can store it in dom0 instead of that USB disk, but it will not make the setup easier...

[marmarek]

Yes, there is a risk, especially related to malicious metadata on the device. Some of it can be mitigated with appropriate udev rules (for example add rule to set ENV{DM_UDEV_DISABLE_DISK_RULES_FLAG}="1" early). You can also disable partition scanning with (echo 1 > /sys/module/block/parameters/no_part_scan). To avoid parsing LUKS header from untrusted device, you can store it in dom0 instead of that USB disk, but it will not make the setup easier...

[andrewdavidwong]

Ensure that confidential information is securely deleted when the contract expires.
[...]
However, achieving (2) is very difficult on many laptops, which often use solid-state drives. Though one could wipe the drive and reinstall Qubes, this is inconvenient.

An alternative is to put the VM’s private data on an external drive. No VM data is stored on any internal medium, so there is nothing to erase. Furthermore, one can encrypt the external drive using authenticated encryption. This ensures that if the data on the drive is tampered with, it will be detected, and furthermore that if the external drive is compromised, the data on it is not usable.

Obviously, such a VM should be excluded from backups.

A better way to do this (which is already possible on Qubes right now) would be to ensure that the data is encrypted such that only ciphertext -- never cleartext -- is written to persistent storage. Then, simply destroy the decryption key when the contract expires.

Why this is better:

• There's still a nonzero chance of forensically recoverable data persistence with HDDs short of physical destruction of the storage medium
• It doesn't matter whether the underlying storage medium is an SSD, an internal or external drive, etc.
• Authenticated encryption can be used inside the VM
• Never requires wiping the drive
• Never requires reinstalling Qubes
• If the data is encrypted in the VM, the whole VM can be backed up without sacrificing confidentiality

[andrewdavidwong]

Ensure that confidential information is securely deleted when the contract expires.
[...]
However, achieving (2) is very difficult on many laptops, which often use solid-state drives. Though one could wipe the drive and reinstall Qubes, this is inconvenient.

An alternative is to put the VM’s private data on an external drive. No VM data is stored on any internal medium, so there is nothing to erase. Furthermore, one can encrypt the external drive using authenticated encryption. This ensures that if the data on the drive is tampered with, it will be detected, and furthermore that if the external drive is compromised, the data on it is not usable.

Obviously, such a VM should be excluded from backups.

A better way to do this (which is already possible on Qubes right now) would be to ensure that the data is encrypted such that only ciphertext -- never cleartext -- is written to persistent storage. Then, simply destroy the decryption key when the contract expires.

Why this is better:

• There's still a nonzero chance of forensically recoverable data persistence with HDDs short of physical destruction of the storage medium
• It doesn't matter whether the underlying storage medium is an SSD, an internal or external drive, etc.
• Authenticated encryption can be used inside the VM
• Never requires wiping the drive
• Never requires reinstalling Qubes
• If the data is encrypted in the VM, the whole VM can be backed up without sacrificing confidentiality

[DemiMarie]

Does Qubes have a facility for storing such keys?

…

On Sat, Apr 14, 2018, 7:15 PM Andrew David Wong ***@***.***> wrote: Ensure that confidential information is securely deleted when the contract expires. [...] However, achieving (2) is very difficult on many laptops, which often use solid-state drives. Though one could wipe the drive and reinstall Qubes, this is inconvenient. An alternative is to put the VM’s private data on an external drive. No VM data is stored on any internal medium, so there is nothing to erase. Furthermore, one can encrypt the external drive using authenticated encryption. This ensures that if the data on the drive is tampered with, it will be detected, and furthermore that if the external drive is compromised, the data on it is not usable. Obviously, such a VM should be excluded from backups. A better way to do this (which is already possible on Qubes right now) would be to ensure that the data is encrypted such that only ciphertext -- never cleartext -- is written to persistent storage. Then, simply destroy the decryption key when the contract expires. Why this is better: - There's still a nonzero chance of forensically recoverable data persistence with HDDs short of physical destruction of the storage medium - It doesn't matter whether the underlying storage medium is an SSD, an internal or external drive, etc. - Authenticated encryption can be used inside the VM - Never requires wiping the drive - Never requires reinstalling Qubes - If the data is encrypted in the VM, the whole VM can be backed up without sacrificing confidentiality — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3820 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB1ZQdqpLZG1vFrRng4Do171vXwI5ks5tooMkgaJpZM4TVOxU> .

[DemiMarie]

Does Qubes have a facility for storing such keys?

…

On Sat, Apr 14, 2018, 7:15 PM Andrew David Wong ***@***.***> wrote: Ensure that confidential information is securely deleted when the contract expires. [...] However, achieving (2) is very difficult on many laptops, which often use solid-state drives. Though one could wipe the drive and reinstall Qubes, this is inconvenient. An alternative is to put the VM’s private data on an external drive. No VM data is stored on any internal medium, so there is nothing to erase. Furthermore, one can encrypt the external drive using authenticated encryption. This ensures that if the data on the drive is tampered with, it will be detected, and furthermore that if the external drive is compromised, the data on it is not usable. Obviously, such a VM should be excluded from backups. A better way to do this (which is already possible on Qubes right now) would be to ensure that the data is encrypted such that only ciphertext -- never cleartext -- is written to persistent storage. Then, simply destroy the decryption key when the contract expires. Why this is better: - There's still a nonzero chance of forensically recoverable data persistence with HDDs short of physical destruction of the storage medium - It doesn't matter whether the underlying storage medium is an SSD, an internal or external drive, etc. - Authenticated encryption can be used inside the VM - Never requires wiping the drive - Never requires reinstalling Qubes - If the data is encrypted in the VM, the whole VM can be backed up without sacrificing confidentiality — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3820 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB1ZQdqpLZG1vFrRng4Do171vXwI5ks5tooMkgaJpZM4TVOxU> .

[andrewdavidwong]

It depends on what you're looking for. It could be as simple as having a LUKS container in one VM, then storing the passphrase for that container in KeePassX in a separate vault VM. If you're looking for something more automated, see #1293.

[andrewdavidwong]

It depends on what you're looking for. It could be as simple as having a LUKS container in one VM, then storing the passphrase for that container in KeePassX in a separate vault VM. If you're looking for something more automated, see #1293.