update for Whonix 14

[adrelanos]

There might be a more clever way so we don't have to update this for Whonix 15?

[codecov]

Codecov Report

Merging #214 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #214   +/-   ##
=======================================
  Coverage   55.75%   55.75%           
=======================================
  Files          56       56           
  Lines        9121     9121           
=======================================
  Hits         5085     5085           
  Misses       4036     4036

Flag	Coverage Δ
#unittests	55.75% <ø> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 39a9e4e...43d6414. Read the comment docs.

[marmarek]

Add a whonix-template tag?

[adrelanos]

We don't have a whonix-template tag in salt yet?

[marmarek]

I don't think so, there is only whonix-updatevm tag. I'm not sure what is better approach here:

1. create one more tag, like whonix-template, or open-in-whonix - generally - narrow definition what it's about, which can be reused for other VMs
2. use just one tag for every feature whonix-related (updates via whonix, opening documents in whonix etc)

The first one is more flexible - for example you can assign whonix-updatevm to any template to have its updates downloaded via Tor. On the other hand, multiple tags are harder to maintain. We could add that to https://github.com/QubesOS/qubes-core-admin-addon-whonix, so whonix-ws/whonix-gw feature would automatically add all relevant whonix tags. That would be effective, but not necessary simpler.

[adrelanos]

Are tags inherited or not inherited when creating a TemplateBasedVM based on a TemplateVM that has tags?

[marmarek]

No, tags are not inherited. Generally settings are not inherited from TemplateVM by TemplateBasedVM. Where needed, core-admin-addon can be made to copy selected settings from TemplateVM to TemplateBasedVM.

[adrelanos]

Let's take a)?

$tag:whonix-updatevm allow,target=anon-whonix

Or b)?

$tag:whonix-updatevm $default allow,target=anon-whonix

Both would work but b) is a bit better?

Actually, I saw the syntax with $default only once in qubes.UpdatesProxy.

https://github.com/QubesOS/qubes-core-admin/blob/master/qubes-rpc-policy/qubes.UpdatesProxy.policy#L7

$type:TemplateVM $default allow,target=sys-net

[marmarek]

$tag:whonix-updatevm allow,target=anon-whonix

This is invalid syntax - there always must be source, destination, action.

[adrelanos]

On a second thought this would introduce a minor attack vector in rare cases.

• Rare cases: people using cloned Whonix TemplateVMs that where a Whonix based TemplateVM gets compromised.
• Attack vector: a compromised TemplateVM not being used for anon-whonix could be abused to DDOS (spam qubes.OpenInVM).

Reason enough to not use tags and to hardcode this?

---

The secure and non-hardcoded version would be difficult to technically implement, I think. We mustn't hardcode anon-whonix then.

• For Whonix-Workstation TemplateVMs: That would be "only a Whonix-Workstation TemplateVM can only use qubes.OpenInVM in an AppVM which it serves as TemplateVM".
• For Whonix-Gateway TemplateVMs: Even more obscure to even formulate for Whonix-Gateway TemplateVMs.

[marmarek]

What this is used for? Isn't it better to use DispVM (based on Whonix) instead? That would avoid the risk of compromising any persistent VM.

[adrelanos]

Glad we discuss this! Marek Marczykowski-Górecki:

What this is used for?

When the user either accidentally (can happen by accident in a graphical terminal emulator) or purposely clicks any links in a TemplateVM then https://github.com/Whonix/open-link-confirmation will open the link in anon-whonix (hardcoded due to DispVM limitations back in R3.2). https://github.com/Whonix/open-link-confirmation/blob/master/usr/lib/open_link_confirmation

Isn't it better to use DispVM (based on Whonix) instead? That would avoid the risk of compromising any persistent VM.

Yes, much better! Also avoids hardcoding `anon-whonix`. So just using `qvm-open-in-vm` should do the right thing, right? (In worst case, doing nothing is not that bad.) I haven't tested yet what happen when using `qvm-open-in-vm` when whonix-ws-14-dvm isn't set up.

[marmarek]

You can keep it as qvm-open-in-vm anon-whonix ... on the template side (for R3.2 compat), but add target=$dispvm here. It will use VM's default_dispvm, which should be set to whonix-ws-dvm by salt.

[adrelanos]

Not important enough to keep R3.2 compatibility. Would take me a long time and lots of pull requests figure out. New plan: only rely on qvm-open-in-dvm and remove all policy exceptions.

QubesOS/qubes-mgmt-salt-dom0-virtual-machines#12 is part of this plan.