[Whonix-devel] [qubes-devel] Disposable VMs on Qubes 4.0

Tue Sep 12 15:06:00 CEST 2017

Alright, so after your follow-up explanations, I think 3a is the best
option for now.

Some more inline replies.

Marek Marczykowski-Górecki:
> On Mon, Sep 11, 2017 at 05:20:00PM +0000, Patrick Schleizer wrote:
>>> 1. Allow starting default Disposable VMs from both Whonix Gateway
>>> (sys-whonix) and Whonix Workstation (anon-whonix or other). This is the
>>> default (if you don't modify policy for Whonix), but it's a very bad
>>> idea, since such Disposable VM most likely will have access to clearnet
>>> directly.
> 
>> True. There would have to be a rule "default NetVM for whonix-ws based
>> VMs AppVMs should always be a whonix-gw based ProxyVM". Doable?
> 
>> That should be covered by 'Whonix default VM settings fixes - salt
>> management' - https://github.com/QubesOS/qubes-issues/issues/1954 -
>> which won't be available in time so we'll still need a solution 1-4 that
>> you suggested?
> 
>>> 2. Prevent starting Disposable VMs from any of Whonix VMs. This is safe
>>> option, but also it limit functionality.
> 
>> Yes, would be a very sad limitation of functionality.
> 
>>> 3. Allow creating Disposable VMs based on anon-whonix, then allow only
>>> such DispVMs be started from Whonix VMs.
> 
>> Also quite limited in functionality.
> 
>>> 3a. Similar, but create separate anon-whonix-dvm for that. Major
>>> difference is that DispVMs based on anon-whonix-dvm will not have access
>>> to private image of anon-whonix here.
> 
>> If it's somehow possible, I'd like to avoid another template that needs
>> to be separately upgraded. (If that would be the case?)
> 
>>> 3a. Similar, but create separate anon-whonix-dvm for that. Major
>>> difference is that DispVMs based on anon-whonix-dvm will not have access
>>> to private image of anon-whonix here.
> 
>> Yes, not too bad.
> 
> "template" for DispVM is in fact an AppVM, not a separate TemplateVM. So,
> it does not require separate TemplateVM.
> 
> It's this way here:
> 
> TemplateVM   ->   AppVM             -> DispVM
> 
> whonix-ws    ->   anon-whonix-dvm   -> dispXXXX

Great!

>>> 3a. Similar, but create separate anon-whonix-dvm for that. Major
>>> difference is that DispVMs based on anon-whonix-dvm will not have access
>>> to private image of anon-whonix here.
> 
>> Why not anon-whonix-disp being "simply" based on whonix-ws template? (I
>> guess it's not advisable for some reason?)
> 
> See above.
> 
>>> 3a. Similar, but create separate anon-whonix-dvm for that. Major
>>> difference is that DispVMs based on anon-whonix-dvm will not have access
>>> to private image of anon-whonix here.
> 
>> A Whonix DispVM having access to private image of anon-whonix doesn't
>> seem good. As a user starting a DispVM to do some more risky action such
>> as opening a pdf and links from an pdf, I would expect if that DispVM
>> gets compromised, that it can not access any other data.
> 
>>> Should the above be only about Whonix Workstation VM(s)? Whonix Gateway
>>> have access to the clearnet anyway (at least in theory), so it's much
>>> less important there.
> 
>> Yes.
> 
>> On a related note, a disposable Whonix-Gateway gets us closer to feature
>> completion. A disposable Whonix-Gateway in combination with a disposable
>> Whonix-Workstation would be more "Tails-alike".
> 
> Hmm, in theory it should just work right now. You just need to have an
> AppVM being a "template" for sys-whonix DispVM. 
> 
> Commands to setup it:
> 
> qvm-create --class AppVM --label purple --template whonix-gw sys-whonix-base 
> qvm-create --class DispVM --label purple --template sys-whonix-base sys-whonix
> qvm-prefs sys-whonix provides_network true
> 
> Then use sys-whonix normally. All its data (especially private image)
> will be discarded at the VM restart, and next startup will be from the
> state of sys-whonix-base.

Sounds good!

> What about entry guards? AFAIR you've said it's better to have them
> persistent?

True, that I said that. In most cases, that's still my best knowledge.
In specific cases however more control over entry guards is better. We
documented this here:

https://www.whonix.org/wiki/Tor#Entry_Guards

>> Then only - DispVMs: support for in-RAM execution only (for
>> anti-forensics) - https://github.com/QubesOS/qubes-issues/issues/904 -
>> would be missing on the Qubes side. Once #904 would be implemented, it
>> would be hard to point out any missing Whonix features with respect to
>> amnesia.
> 
> Yes. In theory it should also be possible with heavy usage of tmpfs
> (it's possible to place all volatile.img there, using separate storage
> pool). But in practice it may require some modifications. And since
> limited amount of RAM, probably just tmpfs isn't the best option, better
> use LUKS with some disposable key. Which require slightly more work.

Alright. One day. :)

>>> What about templates?
> 
>> Starting the template as DispVM? I wouldn't know what that would be
>> useful for except for testing. (Which sounds very useful as for a
>> developer!)
> 
> No, starting DispVM _from_ templates.

Alright.

>>> I think preferred is point 3a, but it require that Whonix-based
>>> Disposable VMs works.
> 
>> Is there any work left on the Whonix side to make them work as DisposableVM?
> 
> I don't know. The first step would be testing what is missing (if
> anything). There is a chance it will just work.

Yes.

Cheers,
Patrick