Mounting other disks (HDD, SSD, etc.)

User Support
1

Hello, Qubers. Looking for guidance/opinions/best practices.

My current storage configuration is pretty simple:

  • main disk (SSD) contains Qubes (dom0 + templates + VMs etc.)
  • all other disks (HDDs) contain regular/personal (non-system) data
  • all disks (SSD + HDDs) are encrypted with LUKS (same passphrase) and managed by LVM

I’m aware of the official article on how to add Secondary storage – I’m not interested in placing different VMs on different disks. All I really want to do is have some HDDs auto-mount on certain Qubes/VMs.

These are the possibilities I can see so far:

  1. add all HDDs to dom0’s crypttab so that they get decrypted with the same passphrase during Qubes OS startup + mount all partitions/logical volumes inside dom0 as well.
  2. add all HDDs to dom0’s crypttab so that they get decrypted with the same passphrase during Qubes OS startup. Leave the mounting part to the specific Qubes/VMs.
  3. Forget about dom0: just leave both decryption and mounting to the specific Qubes/VMs.

The greatest advantage of 1 and 2 is that I can type in the LUKS passphrase only once (during the Qubes OS startup) and not worry about LUKS key files.

That’s for the decryption part, though. When it comes to the mounting part, option 1 doesn’t sound that great, because mounting the volumes inside dom0 doesn’t seem to also mount them in the Qubes/VMs.

Option 3 would be unpractical if I were to do that for multiple Qubes/VMs, multiple times a day. The only way to make it simpler would be to use key files to automatically decrypt the volumes, but I’m trying to avoid that.

I’m left with option 2, which also feels closer to the Qubes philosophy in that I’m not making all those extraneous HDDs available inside dom0, because I’m only mounting them inside specific VMs.

What do you think of those options? Am I missing one that may work better in that scenario?

2

Disks with VMs need to be mounted in dom0, disks with data to be used in VMs should be mounted inside the VMs.

In the latter case if you have them attached to e.g. sys-usb you can use qvm-block or the GUI to attach them to the respective VMs. IIRC you can even do that persistently. Use keyfiles stored in the respective VM if you don’t want to retype your password.

Essentially the same is done by GitHub - 3hhh/qcrypt: multilayer encryption tool for Qubes OS (disclaimer: I’m the author).

3

Thanks for your response, @tripleh.

That makes sense.

Yes, this is another fundamental piece of the puzzle: in order for the volume to be available inside a VM, I need to ask Qubes (through the GUI or qvm-block attach, for example) to attach it to the VM. I’m okay with that too.

This is not a great solution, IMHO. The last thing I want to deal with is key files. For the simple reason that I’d have to store those files somewhere else. Then what – should I encrypt those too? (No, thanks!)

I think I’m going to stick with what I described as option 2.

4

I’m closing this thread with a short report about my experiment: it works. It’s a bit annoying that every time dom0 decrypts a LUKS volume during boot the device gets assigned a new name (dom0:dm-*), but I’ve created a couple of shell scripts that handle that for me, so it’s not too bad.

(It would be great if qvm-block attach could use some sort of stickiness to make the device names persistent across reboots.)

5

Read man crypttab and you will see that you can specify the name of
the block device in /dev/mapper.
If you use cryptsetup, you can also cryptsetup luksOpen /dev/sdb1 data
which will unlock /dev/sdb1 to /dev/mapper/data

1 Like
6

Indeed, and I am assigning a name to each entry in crypttab. What I forgot to mention is that I’m using LVM on top of LUKS, so what I’m actually making available inside dom0 are logical volumes, which I then attach to the App VMs.