I have a standalone vm named research-work. It uses fedora 37. I already have disk encryption and dom0 user authentication setup.
But I want to have a third authentication on my model for research-work vm. Preferably with encryption of some kind. I have no trust in the screen locker.
What is the my best option in terms of stability and speed?
While I’m thankful for your response, my scenario is different,
Imagine that I’m logged into my personal VM, doing some personal browsing at a library. I lock the laptop and walk towards a shelf to grab a book. The screen locker doesn’t encrypt the disk. So a dedicated attacker, in my case it would be a private investigator hired by some high profile politician I’m doing research on, he could snatch my laptop and use skilled individuals to bypass the screen lock.
The same could happen due to a direct snatching while I’m doing personal browsing, I use qubes for personal and work. I don’t want my research-work VM to be compromised. Data at rest in my case needs to be encrypted.
Could you explain in what way your scenario is different?
If I remember that thread dealt with exactly the scenario you outline,
and proposed some solutions.
Different in the way that my research-work VM is vulnerable because of my use of personal-vm. Not because of my use of research-work. Simply because qube os’s disk is decrypted.
If I’m not wrong, the thread suggests a per-vm Luks encryption?
No, it’s the same - that thread explores ways to encrypt a qube. If you
are using it the qube data will be decrypted. If you are not, it will be
encrypted on the decrypted Qubes system.
One solution.
Dont ignore the value in securing your data where possible in every
qube. You dont need to have “encrypted qubes” to get this significant
increase in security.
(If you are concerned with forensic analysis consider issues on
encrypted volatile volumes and swap, and running qubes processing your
research-work data in ramdisk based qubes.)
That’s the point. I’m not using research-work qube. I’m using personal vm qube and dom0 by extension. Research-work is at rest and is not running.
I think we are talking past each other.
Whatever solution you choose to use to secure the data in Research-work
will work.
Can you explain in what circumstances Research-work would not be protected
if personal is running and you have used an encrypted pool?
Equally, if you have encrypted the data in Research-work, in what
circumstances would it not be protected when you are using personal?
Note that encrypting the data has the advantage that you have a far more
granular solution. You could still be running Research-work but the data
would be protected: you could be accessing “generic data” in Research-work
while “specific data” was still encrypted.
Of course, depending on where you are and what threats you are
considering, all this might just be theatre. Do not under estimate the
importance of an informed threat analysis.
I understand. I’ll clarify. I’m looking to have not only the specific data protected but also generic data as that would link me to the research work.
I’m looking for a solution which doesn’t involve an external storage.
I didn’t try, but you could use LVM to create a disk encrypted with LUKS. Unlock it on your dom0, use qvm-block to attach it to your AppVM, run the AppVm and work on it.
If you need to get away, close the VM, close the LUKS volume.
You can create separate partition on your Qubes drive to use for new encrypted VM pool:
I only have a single internal SSD. It’s possible to do this on that, right?
Yes, you can shrink your current Qubes LUKS partition and create a new one using freed space.
Isn’t it possible to create a volume using LVM? 
I don’t think LUKS(LVM(LUKS(LVM))) is a good idea.
That would be LUKS on LVM on LUKS, it’s not that bad IMO, and require less work for users.
To create a 10 GB disk from the VM storage pool
lvcreate -T -V 10G -n secure_disk qubes_dom0/vm-pool
cryptsetup luksFormat /dev/mapper/qubes_dom0-secure_disk
qvm-block list | grep secure_disk
qvm-block attach --persistent MyVM $first_column_of_previous_command
You will have to unlock it from the VM. You could unlock it from dom0, and then attach the unlocked partition to the VM, as you prefer.
As mentioned by @disp6252 , this setup has an overhead because you encrypt on top of encryption, but it’s easier than repartitioning your disk IMO.
I was referring to creating a new VM pool as stated in link above. For just encrypted container it’d be as you’ve said.
It’ll depend on SSD speed and CPU. If you have very high speed SSD with something like 7000-8000 MB/s speed then you’ll feel the hit.