When a compromised VM runs in Qubes OS, all data that belongs to that VM is exposed to the attacker.
That’s a problem. Though my main concern is having an attacker with physical access to the disk retrieve unencrypted data from it.
Luks runs in the VM and encrypts the data with the VM-specific key. The data then travels to storage domain via adresses /dev/xvda2 or /dev/xvda3. The encrypted data is finally written to vm1-cow.img or vm1-priv.img in the storage domain . If I got this right…
Can a VM write unencrypted data to disk when compromised? It’d be good then, to isolate the encryption process to a separate VM, have it do nothing more than encrypt and decrypt VM1’s data. The encryption key would never have to leave VM2 so if VM1 is compromised the attacker won’t know the encryption key. And VM1 can’t send unencrypted data to the storage domain…
I considerd to run a live OS from cdrom but there were drawbacks to it.
Why not just use the Qubes backup utility to perform the backup into the storage domain? It will encrypt it. It shouldn’t matter if the VM is compromised or not.
Also, here you’re talking about per-VM encryption this is NOT what happens by default in Qubes. It’s something you configured, right? Because if not, you may be confusing it with full disk encryption, which it has by default and should address your concern of physical access (as long as it the computer is fully shut down and you never boot it afterwards)
Also, I renamed the topic to make it more concise. Let me know in case it is not adequate.
So here’s the gist of it: in Qubes by default enables full disk encryption. This is why you need to type in two passwords to access your computer: the first one is for the full disk encryption and the second one is for your user.
So whenever you use Qubes, it automatically has that full disk encryption. This means that anything you do under Qubes is saved to the physical hard drive / SSD in an encrypted form.
So if someone stole your computer they wouldn’t be able to see anything inside your system (including any qube) as long as your computer was shut down. If it was suspended or with the screen locked, you’d only need to worry if you believe your attacker is extremely sophisticated.
So each qube doesn’t get encrypted individually (AFAIK). They just simply do their thing and dom0 (the adminVM) does that encryption process for them.
Of course this security is assuming your FDE password is strong and the attacker cannot see you type it over your shoulder.
If I got this right .an AppVM wants to write to disk…
AppVM sends data unencrypted to dom0 .dom0 encrypts data with a key that only dom0 knows about.
dom0 writes data to disk,finally
so,the key is isolated to dom0 where FDE runs. an attacker with physical access to disk nned to compromise dom0 first or know the password to retreve unencrypted data from disk
I miss the role of the storage domain still. it was mentioned in the arch specfication. .
That document is outdated. No storage domain exists currently. Quoting from the docs:
(For those interested in the history of the project, Architecture Spec v0.3 [PDF] is the original 2009 document that started this all. Please note that this document is for historical interest only. For the latest information, please see the rest of the System Documentation.)
The following image is how the current architecture is (except for the GUI VM which will only be available on the next 4.1 version). Taken from the docs:
I’ve looked through the system section of the documents that were mentiond by deeplow
The picture thats shown in deeplows post was in the documentation and it suggests that Full Disk Encryption runs in the AdminVM .
Nothing was mentioned about Full Disk Encryption in TEXT in the System section of the documentation but there was an article discussing the handling of VM data at ‘Template Implementation | Qubes OS’
Finally I looked at ‘Introducing the Next Generation Qubes Core Stack | Qubes OS’ .The last sentence here mentions an upcoming post about device and volume management in Qubes OS 4.0 but I can’t find it as I look through the news archives.
If someone could find a source that confirms that FDE runs in the AdminVM Idd be happy !
To me it seems the easiest way to implement FDE is to run a single prcess in the qube with disk access whuile In theory you have FDE if theres encryption in all VM except AdminVM ?
The image is the source But maybe it could be added somewhere in the documentation. It’s a community effort. If you or anyone else feel like they can contribute, feel free to improve it:
In a hypervisor, any full disk encryption need to be handled at the lowest level.
But maybe it could be added somewhere in the documentation. It’s a community effort. If you or anyone else feel like they can contribute, feel free to improve it: