For an operating system based on the idea of compartmentalisation, it seems strange to completely dismiss the idea of only decrypting the app-vm you’re actually using in the current session.
Even before playing through various attack scenarios, it would seem better than only being able to decrypt everything at once at boot time.
I dislike simplistic analyses of the type “if X is compromised you can forget everything anyway because then a sophisticated adversary would be able in theory to do Y”. That reasoning is academic and the real world is messier. Not every attack is maximally efficient, nor is every intrusion necessarily permanent - they may be opportunistic and transient!
I’d much rather have encrypted data stolen than unencrypted data.
And even if, IF my dom0 is compromised by a sophisticated state level adversary today, my encrypted VM would still be safe until I use it next - possibly weeks or months later. In the interim perhaps the bug could be disclosed and the intrusion discovered/neutralised. So don’t tell me it makes me less safe and is a stupid idea.
I also feel the need to state that I dislike the lecturing and dismissive tone of this discussion.
At least I found that I am not alone in wishing for encrypted AppVMs.
However I also understand that it won’t be built and so I will continue to work around this limitation by hand.
i agree 100% with everything you have said i do not want to distract from the topic at hand but i also want to share my experience why i would like to see vm encryption. i am very well versed in the secondary screening experience. when i am not traveling i am traveling. here is what i have learned. it is not a good look to cross borders with a wiped device. its suspicious and you will be denied entry unless you are a citizen/resident. i like the idea of vm encryption it allows me to just delete the vm which has been compartmentalized for at risk activities and still retain all my normal day to day. worse case they image the device the vm enryption provide some measure of assurance the deleted vm data is not easily forensically recoverable. needless to say i have continuously wiping and reinstalling my qubesOS multiple times a month for this reason its a huge pain
Having qube level encryption has significant advantage over single layer full disk encryption methods mostly but not only in the case when the drive has been unlocked (as it often is) but also when it is locked. Especially if they adopt two different implementations you can greatly mitigate risk or reduce the likelihood of unauthorized access that may arise from a flaw being exploited in the implementation of a single layer of encryption… the chances are very low such vulnerabilities are available on both levels of encryption. You will find this is often a requirement for devices in US government and military use in classified deployments.
I don’t know if @Brad had the time to test my idea of hidden appVMs, and by the way it’s not really the same thing as simply encrypting appVMs, but I came with a crude suggestion to use an equivalent of encrypted AppVMs, manually though.
You can pop up any disposable VM and attach a disk via xl block-attach DOMID '/path/to/file.img,,xvdX' (changing capital X accordingly, also note this can’t be an hdX/sdX type, as only the PV interface is supported in domUs).
The “file.img” is containing TrueCrypt-like volumes (or even LVM/ZFS encrypted pools). You then mount it from inside your disposable, and can use encrypted data as you wish.
Of course this needs manual tweaking if using apps needing the data inside the encrypted file (symlinks, etc). Or just install the apps in the encrypted container.
I said in the related github issue, that I would expect users with
sensitive data to be storing it encrypted within a qube, and
decrypting it as and when needed.
What advantage would you expect an encrypted qube to provide over this?
I’m not a native english speaker so I may have misunderstood, but didn’t you mean the opposite : why this would be better than an encrypted qube ?
Depends if you’re talking about totally hidden appVMs or encrypted appVMs.
For hidden ones I already explained.
For encrypted ones, I agree, I only see one advantage : easy portability of data. Moving a file is easier/faster than exporting a volume. You shutdown the VM the file is immediately available. Also it would allow to share the file with different VMs, maybe more easily (not as the same time though).
But don’t hit me if I say crap, I’m still learning ^^
I meant what I said - in what way would an encrypted qube be better
than encrypted data within a standard qube?
It’s for those who say they want or need encrypted qubes to
explain what advantage they will bring.
(I am not saying that there are no advantages, but that people who press
for encrypted qubes should be clear about what it is that they want and
why.)
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Convenience. An encrypted qube means all customizations, installed software, autostart scripts and much more, easily backed up and inaccessible to an attacker unless decrypted. Not just data.
And, this is kind of a loop, or paradox. Prior to get to convenience, the one should be able to know a lot about Qubes (otherwise serious security damage, or a sense of a false security could happen), but then if the one would know a lot about Qubes, the one wouldn’t ask how to achieve it - he would know how.
Quick personal example, I’m a recently converted Quber, so I have a lot to learn.
In vanilla Xen, to boot a domU from a normal or a hidden volume, I just mount the corresponding volume containing the disk (ie the location of “disk.img”).
Now what would be the way to do it properly in Qubes ? Compared to my method, is it only about LVM handling and not especially Qubes ?
I read your instructions from a previous post which cleared things up.
I’ve also read the doc secondary HDD, which has some useful steps, but they need to be adapted.
But nowhere I found a doc like “Create your domUs and run them from custom locations” (Qubes air is that you ? ^^).
Does a guide like that exist ?
I need to test and maybe sleep on that, but I have preliminary questions :
can’t I mess things up by creating a new volume in the main “vm-pool”, and registering that with Qubes ?
won’t the Qubes tools freak out with un-mounted volumes or disks ? Provided you want the Qubes manager to show them to you.
I’m not clear on what you want that isn’t included in secondary-storage
As you know, the docs are a a collaborative effort, so feel free to
clarify/add matter if you think it is missing.
I need to test and maybe sleep on that, but I have preliminary questions :
can’t I mess things up by creating a new volume in the main “vm-pool”, and registering that with Qubes ?
No - they appear in Qubes manager.
I cant speak for the GUI tools but the command line tools fail
gracefully if the backing volumes are not available.
I’d be very interested in you elaborating on how you would personally go about encrypting data within a standard qube. I was looking at gocryptfs for this use case, but would love your opinion.
I like gocryptfs somewhat, but don’t use it.
I rarely use “cloud” storage, so the claimed advantages mean nothing to
me, and the disclosure of information about file sizes and structure is
unfortunate.
If I worked heavily in the cloud I would look at CrysFS, but not rely on
it at the moment.
I use veracrypt (from habit), and GPG - that combination fits my needs.
As always, you should be clear about your requirements, use case, and
set out your risk profile. Few people do this.
For most users there are some simple questions that help:
How sensitive is the information?
Will you store data in the cloud?
Will you need the encrypted data available in Windows or Mac?
After determining risk profile by considering adversary and likelihood
of targeting, and competency, you can take steps to propose a workable
solution. If the user cant use the tools they will bypass them.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Thank you! Totally agree about starting from threat modelling.
It seems like the two projects differ primarily in that file size is obfuscated in CryFS, I’ll start using it when it gets to 1.0. Here’s the comparison if anyone else is interested: https://nuetzlich.net/gocryptfs/comparison/
