- I have tons of empty space on internal drive that no qube is using.
- This is my goal:
- I want to be able to somehow “mount” this empty space into an offline (no netvm) AppVM qube, making this free space sort of “act like” a plugged in USB external drive.
- From this offline AppVM qube, I would then want to partition this “empty space” into two encrypted ext4 partitions that I can mount/see in a file manager. Note (requirement): The passwords for the partitions should only be typed in from within this offline qube!
- Can this be achieved somehow? How can I trick the machine from making the free space act like a fresh/empty USB drive? (Can this e.g. be done with some LVM tricks?)
deleted (put into main post instead).
Is this “empty space” simply unused parts of the partition you installed Qubes on?
If so one way might be to create a big empty file and mount it is a loop, but then you’d have to format it. At that point my knowledge runs out; I have no idea who to encrypt it.
If that “empty space” is in a separate partition, it becomes a bit easier, because you can attach the partition to your offline AppVM.
One thing I have done is to do this–it won’t be encrypted–but then put a veracrypt container in the partition (or looped file). You can then attach the partition (or file) to your AppVM, and mount it. It will see a directory with a veracrypt container in it. You can then run veracrypt inside it to unlock the container (the unlocked container will be mounted in another place on the AppVM). And doing it that way keeps the password within the AppVM.
It’s truly unused space on the disk that’s not used by any partition at all.
Should I now create (from within dom0 on Qubes, or some other OS from a bootable USB stick) a partition on this free space? And then create e.g. a “secrets-DECRYPT-ONLY-ON-OFFLINE-QUBE.veracrypt” file there? Is this what you suggest?
I really hope there is a way around this veracrypt trick/hack…
The main problem is: When creating the partition, to not expose the password to any online environment ever. And it seems to me (so far, please help on this), I can’t mount this unused space to an AppVM in a similar way I can mount an empty USB drive to an AppVM (which would allow partitions to be created from within this AppVM).
Ah, OK that clarifies things. Here’s what I’m thinking:
- Make a partition in the empty place.
- It will show up in qui-devices. You can then attach to your AppVM with qui-devices and then mount it, just as if it were a thumb drive.
That gets you halfway there; you can access the space. I’m not sure what your options are with having it be encrypted; I just don’t know anything about the “standard” way to encrypt drives and/or partitions. There are plenty of people around who know that stuff far better than I do.
I do know that the veracrypt method I described (encrypted containers on an unencrypted partition mounted on your AppVM) will function entirely within the VM so your password is kept there. If you can’t find a better way to do it, that will work.
I just looked in the documentation; veracrypt will encrypt an entire partition. I’m not sure how that would work in the context of attaching a drive in Linux; if it can work at all you’d have to install veracrypt on the AppVM’s template, run veracrypt on your AppVM and somehow get it to look at /dev/xvdi and decrypt it. (I might do some experimenting at some point; it’d be nice to encrypt an entire thumb drive and use it just like you’re talking about.)
What does this “access” mean? Does this include the ability to delete (from the AppVM) the very partition I just ended up creating and attaching to the AppVM? Because I’d kinda have to delete it & then replace it with an encrypted partition.
At this point I wonder if any filesystems/etc. have such a concept as “sub-partitions” or anything like it.
It means that you will see that partition, the same way you’d see a thumb drive. Which is more than you have now.
As I said, I don’t understand what happens if the partition is encrypted via some sort of standard encryption.
I am experimenting right now with a thumbdrive to see if Verycrypt will do a whole-partition encryption. It looks like it will do this once the partition is attached to your VM as /dev/xvdi. Right now it’s doing the encryption; I have to experiment to see how it is in actual use. Whatever I learn should also apply to the partition you make here.
You were right, and the solution was really simple:
- Boot into some other Linux (thumb/external drive).
- Open Gnome Disks.
- Create partition on the free space on the internal drive, with LUKS encryption. Use password “test”.
- Back in Qubes, setup Gnome Disks on the offline AppVM.
- In offline AppVM, use Gnome Disks to simply change password of partition from “test” to the real password.
- (I think I also could have simply created unencrypted ext4 partition in the other OS, then back on AppVM reformatted this partition as LUKS encrypted partition.)
Thanks a lot for all the hints!
Glad it was useful. Happy (and safe) computing!
For what it’s worth (for anyone using Veracrypt who reads this, it might be worth something), I was able to create an encrypted thumbdrive, attach it, and the destination system can decrypt it.
I have thumbdrives with veracrypt containers on them (I can attach them to other VMs than the one that decrypted them…but that’s complex), but I had never encrypted the entire thumbdrive. It did take HOURS to set up the 128GB thumbdrive in the Veracrypt “wizard” though; just taking forever to format ext3. I should have selected the fast format option.