search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
541 stars 48 forks source link

Feature: Hidden AppVMs #4444

Open anon82649 opened 6 years ago

anon82649 commented 6 years ago

Hello,

I find it very useful to add a feature to create hidden app vms that can be unlocked with a passphrase and that the existence of can be deniable.

Thanks.

andrewdavidwong commented 6 years ago

Somewhat related: #2402

andrewdavidwong commented 6 years ago

This is unlikely to happen, since the specific functionality described here is only useful when an adversary already has access to dom0. (Hiding AppVMs from adversaries who do not have access to dom0 can be handled more easily and, in many respects, is already handled by FDE.) Moreover, since an adversary who has access to dom0 can do pretty much anything, it would be very difficult to hide the existence of certain AppVMs. One way to do it might be to store them on a hidden encrypted volume, but all traces of their existence outside of the hidden volume would have to be eliminated, which would be very difficult. Practically speaking, it would probably make more sense just to have a second physical machine.

anon82649 commented 6 years ago

No, you are missing the point, this is indeed very practical to do for as long as Qubes OS's control is concerned, and that comes to counter key disclosing laws, that force you to give up your encryption keys else you go to prison. Or being searched at the border of another country, being able to pretend to have given your keys, when there's more, that you can't tell is there or not, thus deniable.

Having a second physical machine does not solve the problem, if the police raids your home and sees both machines encrypted, it will ask the key for both, if you had deniable encryption, you could give away your key to the main disk and then pretend you don't have any hidden app vms, or less than there actually is, and they could not prove against that, unable to put you in jail for it.

anon82649 commented 6 years ago

Please see https://www.veracrypt.fr/en/Hidden%20Volume.html for similar functionality.

andrewdavidwong commented 6 years ago

No, you are missing the point, this is indeed very practical to do for as long as Qubes OS's control is concerned, and that comes to counter key disclosing laws, that force you to give up your encryption keys else you go to prison. Or being searched at the border of another country, being able to pretend to have given your keys, when there's more, that you can't tell is there or not, thus deniable.

Having a second physical machine does not solve the problem, if the police raids your home and sees both machines encrypted, it will ask the key for both, if you had deniable encryption, you could give away your key to the main disk and then pretend you don't have any hidden app vms, or less than there actually is, and they could not prove against that, unable to put you in jail for it.

This is all covered by #2402. None of it requires the specific functionality you're requesting in this issue beyond deniable encryption.

Please see https://www.veracrypt.fr/en/Hidden%20Volume.html for similar functionality.

Did you read my previous comment? I specifically mentioned hidden volumes.

anon82649 commented 6 years ago

I am thinking about a dialog that you enter a passphrase in, and depending on that passphrase, it adds an app vm or multiple to your list, which you can remove by hidding it again.

This is made deniable by achieving a similar encryption scheme for app vms, that is enabled even if there is hidden app vms or not.

By default, encryption of apps vms is enabled with a default or empty passphrase, and using another passphrase would allow existence of hidden app vms.

anon82649 commented 6 years ago

It is not difficult to ensure there is no traces left by an hidden app vm on the rest of the system, all the stack is FOSS and works in a predictable way.

andrewdavidwong commented 6 years ago

It is not difficult to ensure there is no traces left by an hidden app vm on the rest of the system, all the stack is FOSS and works in a predictable way.

Hm, that sounds like a misconception based on an oversimplified view of how operating systems like Qubes work. I'd think that traces of the hidden AppVMs would be left in memory, in logs, and in histories and preferences of other tools. Seems like it'd be painstaking and meticulous work to go through everything to make sure that no evidence of the existence of an AppVM can be found after it's (re)hidden.

anon82649 commented 6 years ago

Zero'ing chunks of memory is not hard, system logs don't need to contain app vm names, nor there is a need for system logs at all concerning hidden app vms, other tools can do the same and not log information when app vm is marked as hidden.

It is not an over simplification, no.

Unless Xen has memory leaks, when an app vm is deleted, there's no traces of it kept by Xen.

You usually solve the problem by not writing any data to disk in the first place, or writing the logs/etc in the hidden region directly.

marmarek commented 6 years ago

It is not an over simplification, no.

It is, a big one. There are about hundred things that can reveal existence of a VM, even when not all of them directly reveal VM name, one could tell there is something you're trying to hide. Just a few examples:

I'm not saying it's impossible. I'm saying it's definitely a hard task. You'd be much better with a separate system (maybe even booted from the same disk, from a hidden volume, or from a USB stick).

anon82649 commented 6 years ago

What you described does not represent any non-trivial problem, I don't like someone labeling this as hard when it is not, it looks like incentive to not implement such a feature, you should be as enthusiast as me when it comes to seeing this in Qubes OS and not assign it to "Far in the future", better do it now than have bigger work about it later.

marmarek commented 6 years ago

Patches welcome.

anon82649 commented 6 years ago

Then please go on with the list (you have more knowledge of what could leak in Qubes OS simply because you're used to the project).

And I will write patches.

anon82649 commented 6 years ago

To add on this feature being important, security with Qubes OS is as important as avoiding liability for jail time when you refuse to break your own security by providing keys.

The model becomes flawed when the state actively threatens your life vs your computer security, anyone chooses their life over that.

marmarek commented 6 years ago

Start with choosing VM name and grepping it over:

That should give you some approximation of things to be redacted. After dealing with this, we can go with detailed review of each place that know of VM existence.

anon82649 commented 6 years ago

Okay, will begin work ASAP.

arkenoi commented 2 years ago

no progress here?

DemiMarie commented 2 years ago

Not yet. Current work is focused on shipping R4.1.