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

Mon Sep 11 19:48:46 CEST 2017

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

> > 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.

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

> 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.

> > 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.

> > 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.

> > OTOH, it should be much easier there, because in
> > Qubes 4.0 there are no more savefiles - DisposableVM is started the
> > same way as AppVM.
> 
> Improved Whonix DispVM support should certainly not come before Qubes
> 4.0. Certainly not in R3.2 if you meant that.
> 
> Cheers,
> Patrick
> 

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZtsx8AAoJENuP0xzK19cshiIH/04Ugu/dRkKpGolH4BwePgh8
amsXxTZzoODTzUbmX+Z2DzRw0JMJ50KLgeh0VTitwaGPAYb3SZ2AC3h8niMvXxSZ
WGcDGaZ8GJpiQaNf31myjz7rollhCVhe2tiVtoI/5VxNxWbZ5vHNM3kn6KgpRbkW
8jERETfDVMbwCXxruXMoyZSYzizuDZ4QOVcIigiNNg/ybqijB8TkSwj8zPPNKonx
xykIW2MYrwFl2jRUzQEVCcvv4ENYvHaiGUytd+ztWW7j4s1gQXt7UgjBhyIsdnPh
soiwOO2slMi1qwIEzEkCe3sQJlYDfZDnCEBa7s3B7CgWOa1v2cTvTfEybh2kmPA=
=sXNE
-----END PGP SIGNATURE-----