Is it possible to run a qube off an encrypted external drive?
As is, I have to attach the drive to a qube, then decrypt it. I can’t see how I might setup a storage pool to do that, without attaching the drive direct to Dom0.
Is it possible?
I’m not quite sure what you’re asking here.
I can describe what I have managed to do, and you can tell me if it would meet your needs.
I have, on a NAS, a lot of veracrypt containers…which are basically multi-gigabyte files that can be decrypted and mounted as though they are drives. The NAS itself is not encrypted, but those containers are.
I have a VM whose job it is to connect to the NAS and make the containers available (still encrypted) to other VMs…let’s call this one the “Owner.” The VM that accepts the container is Decryptor; it decrypts the drives and makes them available for yet a third VM, the Client.
dom0 doesn’t touch these files except for having to participate in handing off from one VM to another (that’s part of the way the block mounting works). dom0 never mounts the drives itself.
Client doesn’t know its a decrypted drive or where it actually lives (it has no knowledge of the NAS). Owner never sees the decrypted drive, nor does Owner see Client. Decryptor has access to neither of these and is, in fact, a disposable VM. Decryptor doesn’t even have direct access to where the passwords are kept (that’s yet another VM I haven’t mentioned until now, KeyManager)…passwords (and eventually, as I improve things, keyfiles) are given by KeyManager to Decryptor. [As of right now, KeyManager simply prompts me for the encryption password. I consider involving the user a vital part of the security–just like in copying files to other VMs–since otherwise KeyManager could be spoofed by a false Decryptor.]
What does the user–meaning you–actually see? First a popup from Owner prompting for the password for the NAS share. That needs to be done just once after rebooting. Then, when you actually want to access a container, a popup from the Client letting you pick and mount a drive (Client is allowed to ask Owner…via a service in dom0…for a list of encrypted containers). Finally, a password prompt from KeyManager. Once that’s provided the Client automatically mounts the decrypted drive. Read only and read-write are both options.
It’s also possible to let yet another VM (call it Manager) manage the process…instead of the Client doing so. That may be better security, but I don’t (yet) have a GUI popup that lets you pick the Client VM, so that’s a command-line thing (the scripts are flexible but a pain in the butt to use). It’s also possible that this management should be done by dom0…but even if so dom0 never mounts the drive. (I’d love to have a person who understands security better evaluate this stuff.)
[One special case: I have a windows qube, and it cannot handle read only, and some other qube must manage the process for it since bash scripts wont work on Windows. So I have a special Windows Manage qube that does nothing else but connect containers to the windows qube.]
@SteveC: Sounds pretty much like a single layer of [1].
[1] GitHub - 3hhh/qcrypt: multilayer encryption tool for Qubes OS
veracrypt is configured to be able to triply encrypt the containers…but even though it looks like you could use this 3hhh/qcrypt to do that, that’s not what it’s really for. With this, you can put containers into other containers. [I could probably fake that…by attaching a decrypted container to another owner qube, and configure Owner2 to mount that in the same place in its file system the first Owner does…but that would be writing more software, not a “user” sort of thing at all.] In fact, my Owner qube is very me-specific as it is…expecting the containers it owns to all be in a certain place. I didn’t push my code out largely for reasons like that; it needs a lot of work before it’s user ready, e.g., a way to configure the Owner qube through the gui, better gui handling of cases like shutting down the client qube with the container still attached, and so on.
Hm, you’re right that what you described is more like 2 layers of qcrypt:
yours: storage VM --d-> decryptor VM --a-> client VM
qcrypt: storage VM --d-> decryptor VM --d-> client VM
–d-> = attach & decrypt in the VM pointed at
–a-> = attach to the VM pointed at (no encryption layer)
Admittedly the last layer is only needed if the decryptor VM is compromised and that’s rather unlikely if you only use it for a single client VM. Otherwise it makes sense to add that encryption layer from my point of view even though it’s generally better to have dedicated decryptor VMs per client anyway.
Sound like a pretty sweet setup.
I imagine it works with hidden vaults too, depending on the password entered?
Is it able to work with SSDs or do you need a NAS?
From what you describe I imagine it has plenty of custom code to make it work.
Is this something I could implement with basic coding knowledge?
Honestly, it took about a month of my spare time to implement, but it would be faster for someone with the outline of my solution.
Customization would be with the Owner (who needs to know where the things are located). There’s no reason it couldn’t be files sitting on a (local) SSD rather than a NAS. In fact, if I simply mounted the SSD to the same directory I mount the NAS, even my Owner qube would never know the difference. (It would render moot the popup dialog for entering the NAS password…but that’s actually a separate piece of software anyway.) So really the only configuration one would have to change is the name of the mount point. (And to ensure clarity, I’ll repeat–the mount point for the file system that contains the encrypted container…not the mount point for the container itself.)
You’d absolutely HAVE to know scripting to do this. And the GUI front ends I wrote in C++ using gtk (not gtkmm as that requires a lot more libraries to be present on the qube).
The other customization comes when the Client gets to mount the decrypted container…I put those scripts in /home/user/bin on the presumption that the client will want to customize that behavior in some way. (Potentially, different containers could be mounted in totally different places, e.g., a “documents” container under “Documents” and “pictures” under “Pictures”–In my case I mount them to different directories with the same names as the containers, under “/home/user/Shares.”)
One other quirk of this system is that Owner must, once, catalog the containers, and each is assigned a number, seriatim. This number gets passed through the chain. So if someone had two containers, they’d end up being referenced as 1 documents and 2 pictures. Also, my containers all have file extension .vrc so I can tell they’re containers.
I don’t see an issue with hidden vaults…it will use the password handed to it. (I haven’t played much with that capability so I really don’t know how it works from the user perspective.) As mentioned before I haven’t gone so far as to supply key files, but that could be done with more coding. Since this uses the command line version of veracrypt, there doesn’t seem to be a way to supply the PIM without it prompting you for one, so I don’t see this supporting PIM values any time soon.
1 Like
I can imagine how I might set this all up with bash, if I knew how to share access to a mounted Veracrypt vault mounted in one Qube, but shared with another.
The other sticking point is how to setup the storage pool to save the Qubes on the external drive.
And lastly, attaching, mounting, and decrypting the drives with bash. I could not get this to work, no matter what I tried. I still have to mount external drives then decrypt them thru the GUI and Files app (which is a major friction point).
I need to do a full up post on this sometime. I had a draft but it disappeared.
I’m going to be a bit like Sven though and not share the source code, just summarize what I did at the top, then go into more detail below (which is not a normal way to organize such things, but it has its virtues).
Other than reverse engineering, what risks of sharing the code?
I’d hate for someone to grab it, use it…and it doesn’t work…or worse, causes damage because of a bug I haven’t found. (I actually wiped a couple of my containers clean with a really stupid choice I made…fortunately I had backups and when I finally figured out what had happened…let’s just say my ego was adjusted!)
What I plan to post are the key commands one could issue at the command line, but not the other 90% of the code that helps it be automated and error checks inputs, etc. Of course the commands themselves have to be issued on the VMs in question unless you set them up as qrexec services, so I might cover how to do that. You can in principle run everything from one VM at that point. The gui front end I wrote is just icing on the cake once you get there.
Posting the key commands also removes any things specific to my case (such as my naming conventions for containers, the fact that they’re in a certain place on a NAS, and so on).
2 Likes
OK, I finally did it: Here’s my long ramble on how to do it.
1 Like
You’re doing the Lords work 
Thanks. I’ll go thru it and see what I can implement.