search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
542 stars 48 forks source link

Support VM private block devices on external media #3820

Open DemiMarie opened 6 years ago

DemiMarie commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 < notifications@github.com> 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 https://github.com/QubesOS/qubes-issues/issues/3820#issuecomment-381364930, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWBy8C_im42jG5C5wNgVa75FoL28iBks5tonc6gaJpZM4TVOxU .

marmarek commented 6 years ago

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 commented 6 years ago

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:

DemiMarie commented 6 years ago

Does Qubes have a facility for storing such keys?

On Sat, Apr 14, 2018, 7:15 PM Andrew David Wong notifications@github.com 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 https://github.com/QubesOS/qubes-issues/issues/3820#issuecomment-381367404, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWB1ZQdqpLZG1vFrRng4Do171vXwI5ks5tooMkgaJpZM4TVOxU .

andrewdavidwong commented 6 years ago

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.

3hhh commented 5 years ago

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

If you're still looking for an automated solution, this should cover most of your requirements: https://github.com/3hhh/qcrypt