I’m trying to setup an appVM on an external hard drive, inside of a VeraCrypt container.
I’m reading the documentation here:
I don’t have a storage.conf file in etc/qubes.
I can imagine this is because a storage driver was never setup?
How do I set one up?
Unfortunately that linked documentation page is obsolete since R4.0. There’s no longer any such config file. Best to ignore all that stuff completely and start with the qvm-pool manpage in dom0.
Assuming e.g. that you’ve formatted your unlocked VeraCrypt container with a filesystem that supports reflinks (currently Btrfs, or alternatively XFS formatted with -m reflink=1), and it’s already mounted at /mnt/somewhere:
$ qvm-pool -a yournewpoolname file-reflink -o dir_path=/mnt/somewhere
Here’s a more detailed HOWTO that creates a new lvm_thin pool (instead of a new file-reflink pool): Secondary storage | Qubes OS
Veracrypt out of the box supports: Ex2,3,4, FAT, NTFS, exFAT. So I would have to make the vault with no format then re-format with another tool?
…Then follow that guide.
Question:
Let’s imagine Veracrypt is a hidden vault. I open to one outer volume and get one set of files when launching the appVM… close doen the appVM… dismount/remount with into the hidden vault…start the appVM again…
…Will the state change between the outer/inner layer mess up the appVm? Or could it handle such a setup with no problems?
I haven’t used VeraCrypt but that sounds right. The tool would be mkfs.btrfs.
Qubes will refuse to start the VM when its volumes are missing, but after remounting, you can start it again. It shouldn’t cause any corruption.
What I’m curious about is state change between the overt vs the hidden inner layer. Having the appVm with the same name, in effect sharing 2 separate sets of files/folders, depending on if the vm is mounted with to the outer or inner layer. Will that break the vm? Is the vm sandboxed… are there dom0 files I need to consider that change from appVm start to start.
Oh I think I might understand your ghost layer thing now. You want to have anti-forensic secondary storage, so that someone analyzing your decrypted dom0 would not be able to tell that the secondary storage even exists? Specifically, if it’s currently not hooked up then the affected VMs should still be able to start but with decoy data from primary storage?
I was thinking that I could set it up to either using a Veracrypt 2 layer vault (hidden vault), or better yet, the overt layer is on the primary drive, and the hidden layer is in the Veracrypt drive.
If I use the later approach, wouldn’t I just simlink the appVM root folder from dom0 script, with the Veracrypt hidden layer mounted, rather than setup a separate storage pool for the appVm?
If I want the appVm to load normally, when the external drive is not connected, it would seem I should create a standard appVm, with no storage pool tag?
Then have a script that shuts down the appVm if running, mounts the Veracrypt drive, symlink the root folder, then launches the appVm normally.
My qs for the pros: I can see this working unless there are changes in Dom0 files for that appVm that the symlink cannot reach? Or maybe I need to symlink a Dom0 folder that feeds the appVm?
To access the ghost layer the external drive would need to be mounted and attached to the appVm? Or maybe this is where storage pools come in. How to attach the external drive to the appVm before it starts up?
I am really interested to hear how this went, or what types of constraints you encountered, etc.
I am new to Linux, first time user and diving into QubesOS. A lot to handle and learn, but stuff like this interests me a lot! Were you able to maintain security and data integrity with your approach? Let me know! I wish there were a private messaging feature on here, I would love to collaborate or pick your brain a little 
Could you possibly just have two AppVMs (sharing the same template), one each on the hidden and non-hidden volumes?
Essentially all an AppVM is (at least the way I’ve been doing things) is a place to put your user account, and that’s primarily data.
I ask because I’ve been moving my e-mail client back and forth between two boxes, by backup and restore. There are identical (well I hope they are) templates on the two boxes each with Thunderbird (and not much else) installed. I haven’t tried the experiment of creating a second AppVM with a different email account on it, yet (though perhaps I should!).
I am interested in how this hardens security or what the goal is. Could you give me a high-level overview of the concepts I should know to understand this?