How to program "sys-whonix"-clone in 4.1.1?

User Support General
1

Related to the following discuss-link see the following problem:

How to program which file in which policy to update the original-whonix-system via sys-whonix as before, on the other hand the clones (I call them here whonix-ws-16-TEST and whonix-gw-16-TEST) via sys-whonix-TEST?

And how can I prevent (in the new policies) that when starting these clones in the Qubes manager always starts sys-whonix and not the clone sys-whonix-TEST?

On a trial basis, I have renamed the target in “qubes.UpdatesProxy” to sys-whonix-TEST for this purpose:

$tag:whonix-updatevm $default allow,target=sys-whonix-TEST (instead of sys-whonix).

This works - shutting everything down and starting the update (e.g. from whonix-ws-16) will also start sys-whonix-TEST.

But adding a second line with a different rule to update/start the clones via sys-whonix-TEST and the originals via sys-whonix does not lead to success.

for example:

$tag:whonix-ws-16-TEST $default allow,target=sys-whonix-TEST
$tag:whonix-gw-16-TEST $default allow,target=sys-whonix-TEST
$tag:whonix-ws-16 $default allow,target=sys-whonix
$tag:whonix-gw-16 $default allow,target=sys-whonix
$tag:whonix.updatevm $anyvm deny

(I left out the whonix.updatevm line as it refers to whonix in general, but don’t know if that is correct).

I’m not sure if I wrote this correctly because it doesn’t work. Does anyone have any ideas? And most importantly:

Does this overlap with the entries in the policy.d files?

Thanks for opinions!

2

I think I have found the solution.

I have added the following line in qubes.UpdatesProxy as first (so before the others). It defines a rule extra for whonix-gw-16-TEST:

#Upgrade whonix-gw-16-TEST through sys-whonix-TEST
whonix-gw-16-TEST $default allow,target=sys-whonix-TEST

#Upgrade whonix-ws-16-TEST through sys-whonix-TEST
whonix-ws-16-TEST $default allow,target=sys-whonix-TEST

#Upgrade whonix Templates through sys-whonix
$tag:whonix-updatevm $default allow,target=sys-whonix

#deny whonix Templates using UpdatesProxy of other VM
$tag:$whonix-updatevm $anyvm deny

#Default rule for all Templates - direct connection to sys-net
$type:Template $default allow,target=sys-net

Only then come the rules for whonix-ws-16-TEST, then those for the whonix templates and the “normal” templates.

This not only fixed the update problem via QubesUpdater, but also causes the correct sys-whonix-TEST to now start in the app menu when calling any app.

It should work with any whonix-clone named in another way.

So obviously nothing needs to be changed in the new policy system. How it will be when qubes.UpdateProxy is no longer available, we will have to try then.