> Then attach the encrypted containers to disposable VMs only. Problem 100% 
> solved.

Sadly it's not. When you start working with files from these containers, data 
will eventually be written to harddrive "unencrypted" (let it be swap, 
temporary files, persistent work related files, ...). Once they are written to 
the harddrive there is always a risk of data leakage.

I found a discussion, which describes part of the problem quite good:
https://github.com/QubesOS/qubes-issues/issues/904

Also David already posted another link, which is also worth to read:
https://github.com/QubesOS/qubes-issues/issues/1293

Fortunately once DVMs are encrypted, persistent VMs can be encrypted aswell, 
which will eventually solve all problems.



> Yeah, I didn't describe it clearly. I meant that VMs are protected with some 
> auth scheme, for example: password. But, obviously, the result is used to 
> encrypt/decrypt the VMs, not in the currently active state. So you could 
> change state rapidly, if a paranoid restore isn't needed. And this is totally 
> different concept, because different context.
> In this way the user will change password frequently (good behavior), he/she 
> doesn't need to remember 30 password, the user isn't forced to take quick and 
> bad roads (like the previously mentioned degenerated model). What the user 
> need is at his disposal, unnecessary data no. With good compartmentalization 
> this separation is practically already done.

So at first you are against vm-encryption with the possiblity to use unique 
passwords since it was too hard for you to remember multiple passwords. At the 
same time you refused to use the same password for more than one VM.
Now you say, your "state" model also relies on ENCRYPTED VMS, which are 
encrypted/decrypted with ONE PASSWORD all together. *sigh*
Not gonna argue with you anymore, it's useless...

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/82e07fcd-4a98-498b-8fb7-1ccb19adbbd3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to