$tag:whonix-ws-16-2 shouldn’t be used twice. At time of writing, these Qubes qrexec policy files have a comment on the top that parsing stops at the first match. (Which is a Qubes default. Unspecific to Whonix.)
Unless you’re adding tags using qvm-tags this isn’t what you want.
I have gone through all the suggested chapters again.
I noticed that in the chapter “sdwdate-gui qrexec” in the mentioned file path
/etc/qubes/policy.d/80-whonix-policy
the policy.d folder is not present, only the actual policy folder of the old system. Of course, 80-whonix.policy cannot be found in this folder.
Therefore I could not compare the file with the entry in github.
I then opened the files whonix.GatewayCommand, whonix.SdwdateStatus and whonixNewStatus and found the following entry there respectively:
Legacy. This file does nothing and will be removed in a future release. See:
/etc/qubes/policy.d/80-whonix.policy
This makes no sense, since the new policy should be there.
I then checked the qvm-tags of all whonix VMs.
Result: everything displayed correctly
I think the problem is in Qubes itself, as I went through all the suggested chapters, but the problem persists. I will also post this in the Qubes forum.
Then you have a general Qubes issue unrelated to Qubes-Whonix that must
be resolved first.
I will also post this in the Qubes forum.
Great!
Yeah. The issue is you got “Legacy. This file does nothing and will be
removed in a future release.” but at the same time you didn’t receive
the updated files supposeldy in folder /etc/qubes/policy.d/ (other
files are supposed to be there. Whonix is just 1 among many others
deployed by Qubes.)
Edit: (whonix-forum, qubes-forum): I made a mistake - the policy.d folder is of course there, I just didn’t find it due to wrong navigation.
Nevertheless, the question arises (with reference to the following links and the corresponding discussions), I posted it in the Qubes forum under “4.1”.
This I find messy. Should be a separate forum thread. I’d suggest to edit from there and create a new proper forum thread.
Note: I am not a Qubes forum moderator and that’s just my personal opinion.
Yes, you are right. I didn’t want to open too many threads on similar topics. But I will split the topic and then open a new thread in the Qubes forum.
There is no $tagwhonix-gw-16or whonix-ws-16. If it’s a tag, then the same is most likely generic and does not have a specific version. (That could be the case for some version migration but currently not on the horizon.)
If you cannot find a tag using qvm-tag then there’s no need to reference it in any Qubes policy files.
I have added the following line in qubes.UpdateProxy 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
Only then come the rules for whonix-ws-16-TEST, then those for the whonix templates and the “normal” templates, as described above.
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.
I will post this in the Qubes forum as well. It should work with any whonix clone.
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.
If you mean corresponding section in above link
“Multiple_Qubes-Whonix_Templates”
then I would suggest the following entry for users who want to create a complete clone of the Qubes-Whonix system (i.e. for sys-whonix, whonix-ws-16 and whonix-gw-16) and use it independently from the original Whonix:
## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect
## Please use a single # to start your custom comments
# Upgrade all Templates through sys-whonix.
#$type:Template $default allow,target=sys-whonix
# Upgrade whonix-gw-16-clone-1 through sys-whonix-cloned
whonix-gw-16-clone-1 $default allow,target=sys-whonix-cloned
# Upgrade whonix-ws-16-clone-1 through sys-whonix-cloned
whonix-ws-16-clone-1 $default allow,target=sys-whonix-cloned
# Upgrade Whonix ™ Templates through sys-whonix
$tag:whonix-updatevm $default allow,target=sys-whonix
# Deny Whonix ™ Templates using UpdatesProxy of any other VM
$tag:whonix-updatevm $anyvm deny
# Default rule for all Templates - direct the connection to sys-net
$type:Template $default allow,target=sys-net