My threat model: not letting government agents know about some sensitive workloads that I run, which is why I need to run them in a hidden volume.
The best advice I have come across is Split veracrypt. Very well written guide and covers some of my use cases too.
However, the problem that I see here is that such a container would come off as a disproportionately large file (because it will have VM images in it) and would elicit more effort into looking at it. Instead, I would have liked to have almost the entire disk (other than /boot because that’s only possible on Windows) encrypted by Veracrypt. I would run my usual VMs in the “normal” partition, including somewhat sensitive workloads but nothing too important for me, and then I’d create a hidden volume as usual and run sensitive workloads in that.
I am aware that I’d have to switch off logging in dom0, yet to go through that.
Now, installing third-party software in dom0 is frowned upon. Then, how would I manage a veracrypt partition (and hidden volume) and run VMs on it through a DispVM? I am unable to understand how I could make this work without installing veracrypt in dom0.
I would really appreciate any suggestions you might have for me! Thanks
Split veracrypt was actually intended to produce containers of data, which could be decrypted and attached to regular VMs. It wasn’t the intent to actually put VMs in the container (which is how I interpret what you want to do–If I misread you please disregard this).
On the other hand nothing in split veracrypt precludes using a hidden container…of course you have to create it in the first place (which split veracrypt won’t help you with; it assumes existing containers).
However, a lot of the info in there could probably help people figure out how to do the latter; I imagine you’d have to attach a decrypted container to dom0 somehow, and get it to recognize VMs in another pool.
Ah, nihilist’s blog. Always a favourite to read. Thanks for the link.
To implement what he does there with Veracrypt, I would likely need to install Veracrypt in dom0 (which is against the recommendations of the Qubes OS team). I do not think that Veracrypt is malicious, but the best way would have been to try it the “Split Veracrypt way” of using it in a DispVM, which I estimate would be a hard/hacky to do.
The second problem is that unlike LUKS, Veracrypt doesn’t actually do FDE on Linux (but does it on Windows). As a FOSS enthusiast this kind of logic baffles me, but I’m sure they have their reasons. Regardless, if I only encrypt a certain partition on my hard-drive instead of the entire thing, it’s actually more suspicious to government agents (because now it definitely looks like you have something to hide) instead of doing FDE, in which case you’re just a cautious user trying to get rid of the low hanging prizes (thieves).
I am looking at LUKS seriously now instead of Veracrypt for this very reason. It seems that with a little bit of effort, LUKS can be made to have plausibly deniable partitions too (it’s just that it’s a bit of DIY work rather than Veracrypt which has this built in). If Veracrypt could do FDE I’d jump on it right away.
Yes, I did realize that. Veracrypt containers would be a great way to hold data (and explain to government agents) - you’re just taking precautions as a concerned user.
But as you pointed out, it won’t work that well (well, it probably could technically but it won’t pass off so easily, socially speaking) with VMs running in it.
Pasting what I wrote to the other commenter:
if I only encrypt a certain partition on my hard-drive instead of the entire thing, it’s actually more suspicious to government agents (because now it definitely looks like you have something to hide) instead of doing FDE
This is why “Split Veracrypt” doesn’t help my use-case that well (I will be using its concepts for data storage, of course). Thank you for the wonderful guide, I hope more marginalized people and journalists find your post and secure themselves better.
