Disposable VMs on Qubes 4.0

418 views
Skip to first unread message

Patrick Schleizer

unread,
Sep 11, 2017, 12:50:58 PM9/11/17
to qubes...@googlegroups.com, Whonix-devel, Patrick Schleizer
(Was written by Marek. Forwarding this to qubes-devel in hope someone
will have better answers than I might have. :)

Hi,

Disposable VMs in Qubes 4.0 are much more flexible. The major difference
is possibility to use different Disposable VMs "templates" (which in
fact can be any AppVM) for different purposes (different services,
different calling VM etc). All settings of Disposable VM are inherited
from its "template", including private image (IOW, it isn't required to
create /home/user/.qubes-dispvm-customized file for that anymore).
This "all settings" include also netvm - it is no longer inherited from
calling VM, but from Disposable VM "template". But since it's possible
to create multiple such templates, it is possible to achieve the same
behavior.

What is used where is configured using qrexec policy.
I'm preparing the policy for Whonix-related VMs for Qubes 4.0. Here are
possible options I see:

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.

2. Prevent starting Disposable VMs from any of Whonix VMs. This is safe
option, but also it limit functionality.

3. Allow creating Disposable VMs based on anon-whonix, then allow only
such DispVMs be started from Whonix VMs.

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.

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.

What about templates?

I think preferred is point 3a, but it require that Whonix-based
Disposable VMs works. 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.


-------- Forwarded Message --------
Subject: [Whonix-devel] Disposable VMs on Qubes 4.0
Date: Sun, 10 Sep 2017 15:28:15 +0200
From: Marek Marczykowski-Górecki <marm...@invisiblethingslab.com>
Reply-To: whonix...@whonix.org
To: whonix...@whonix.org

Patrick Schleizer

unread,
Sep 11, 2017, 1:17:34 PM9/11/17
to qubes...@googlegroups.com, Whonix-devel, Patrick Schleizer
> 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.

> 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?)

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

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.

> 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!)

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

> 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

Marek Marczykowski-Górecki

unread,
Sep 11, 2017, 1:50:50 PM9/11/17
to Patrick Schleizer, qubes...@googlegroups.com, Whonix-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
"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-----

Patrick Schleizer

unread,
Sep 12, 2017, 9:04:16 AM9/12/17
to Marek Marczykowski-Górecki, qubes...@googlegroups.com, Whonix-devel
Alright, so after your follow-up explanations, I think 3a is the best
option for now.

Some more inline replies.

Marek Marczykowski-Górecki:
Great!
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

Patrick Schleizer

unread,
Sep 14, 2017, 2:37:39 PM9/14/17
to Marek Marczykowski-Górecki, qubes...@googlegroups.com, Whonix-devel
whonix-ws-dvm or anon-whonix-dvm - which is the better name? Is it
consistent with the other dvm naming in Qubes?

I have no idea. Just pointing to it so we don't use something we later
want to change.

Cheers,
Patrick

https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/pull/5

Marek Marczykowski-Górecki

unread,
Sep 14, 2017, 3:00:22 PM9/14/17
to Patrick Schleizer, qubes...@googlegroups.com, Whonix-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Sep 14, 2017 at 06:39:00PM +0000, Patrick Schleizer wrote:
> whonix-ws-dvm or anon-whonix-dvm - which is the better name? Is it
> consistent with the other dvm naming in Qubes?
>
> I have no idea. Just pointing to it so we don't use something we later
> want to change.

Specifically for consistency with fedora-XX-dvm, I've used whonix-ws-dvm
there.

> Cheers,
> Patrick
>
> https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/pull/5

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

iQEcBAEBCAAGBQJZutHAAAoJENuP0xzK19cs/uQH/jPCSOjaDiNfZ21g12I/rTq+
XlNzh+fE1d6VUMeoKVMmakRc2iGH7eCHAoc4VOdt7Huo1irZLYVMna6MNvvP+MwX
iPMRC67nXkCWIT9cCYH9YG0DyLclen28dGtFetojdlP5Wg+NHqqhbXFPmBJF7HtW
x6GxkcCXXxWRvHkxaMo2FTcsVe1KQ06sKSJXwuIRWoE/0aGeS6D7FsMLCuQbBN73
l9Pr1wfeZimUrL6Hxsiai6E+QPak645nuRfmykhNEwHeiWkq6pJ2wpeKGpyDUwpo
8jmP5zryDhW6eA9CthAxclz4Y/nI9t0jjxV8ntVmMMBGjBCHod146qg6EbrzZ3o=
=ExQq
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages