sys-whonix starts unintentionally

Qubes-Whonix
21

I entered the above script and applied the latest updates to debian, whonix-ws-16 and whonix-ws-16-TEST and got the following results:

debian updates via sys-net

whonix-ws-16 via sys-whonix

whonix-ws-16-TEST via sys-whonix-TEST

If you now call whonix-ws-16-TEST or whonix-gw-16-TEST in the Qube-Manager, sys-whonix-TEST will now start correctly.

This is a very good result!

The only error I still detect is the following:

If I call whonix-ws-16-TEST with any function in the app menu (e.g. tor-browser-downloader or terminal), sys-whonix-TEST starts correctly.

With whonix-gw-16-TEST this does not succeed, here sys-whonix starts incorrectly.

I am not sure whether I can configure this extra with a rule in qubes.UpdatesProxy.

22

Could be qrexec.

In dom0. Watch journalctl and see qrexec calls.

sudo journalctl -f
23

Thank you, IĀ“ll try this and summarize the results, perhaps there is any solution.

24

I think I have found the solution.

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.

25

Is this already correct in the existing documentation?

26

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
1 Like
27

Addendum: For some reason, when copying, the diamond symbols in the comment lines are deleted and the font is too large.

28

Code tags can fix that.
https://www.kicksecure.com/wiki/Forum_Best_Practices#Code_Tags

29

Thanks! Wiki updated.

30

Thanks too, also for the tag-tip!

Note on the last line:

$anyvm $anyvm deny

It seems to cause fedora not to connect via the qubes.UpdatesProxy in the Qubes updater.
Originally I did not have it in my proposal, but since it seems logical, I took it from you.
After reboot and an attempted fedora update via the Qubes updater, no connection to the mirrors could be established in several attempts. Only after deleting the line it works again.

So I edited the script above and took out the line.

Maybe it is a coincidence and needs to be reproduced elsewhere, but I will test this further.

31

$anyvm $anyvm deny

Thatā€™s the default fallback rule. I am not sure thatā€™s a good idea to
remove it. Goal should be to have strong rules that cover everything and
then have the fallback rule for leak / unexpected behavior protection.

Not sure. You could ask Qubes about that.

Depends on how it should be updated. Over Whonix / Tor or otherwise?

Maybe

$type:Template $default allow,target=sys-whonix

at the end (before $anyvm $anyvm deny) wold be better?

32

I agree, I also had a stomach ache at the omission of this rule. So I will test this again when the next Fedora rule comes out, as well as insert the rule you suggested.

If the failure of the last Fedora update turns out to be a coincidence, then everything would be fine. Otherwise you have to search further for the cause (in the Qubes forum etc.).

In principle I also think it is better to update via sys-whonix than via sys-net, as well as via onion-channels. I had also tested this several times, but it takes a very very long time, especially when onionizing.

33

I have tested it several times with fedora and also debian and it is always the same negative result:

Only removing the last line

$anyvm $anyvm deny

allows updating both via the Qubes updater and via the menu.

Adding the rule as penultimate line to update via sys-whonix does not change anything.

But this is a case for the Qubes forum. If there are results, Iā€™ll write it briefly here too.

1 Like
34

We discussed at the following link:

  1. the last two lines before

Ā§anyvm $anyvm deny

must be swapped.

  1. in the default rule for all templates it must be

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

and not only template (without VM).

This should work.

1 Like
35

Thanks! Documentation has been updated just now.

Thanks to Security: Important policy rule blocks fedora/debian updates - General Discussion - Qubes OS Forum on the same wiki page there is now also documentation on how to use Qubes /etc/qubes/policy.d folder. Could you test that please?

36

Yes, I will, but it will take a few more days. I will report when it is ready.

1 Like
37

related:

38

I read through the thread on Github. It addresses the most important issues from my point of view:

  1. How do we manage to integrate the solved problem from this thread into a new policy in such a way that qubes.UpdateProxy becomes redundant. So far it always seems to be the case that so far qubes.UpdatesProxy overwrites the 90-default.policy or the 80-whonix.policy.

It is imperative that security be maintained, but still be able to save individual settings, such as we use when cloning whonix in this thread.

If I understood it correctly, according to Marmarek, changes made by the user should be preserved, but can be moved to the new policy.

  1. Deleting qubes.UpdatesProxy and just using the new policy does not seem to be possible without problems so far.

  2. In my estimation the creation of a policy with lower number is meaningful only if in it the individual attitudes from qubes.UpdatesProxy can be converted and qubes.UpdatesProxy becomes completely superfluous.

Regarding the penultimate link from the Qubes forum (Security: important ruleā€¦), everything is clarified. The updates work without problems, even on fedora and debian.

However, I will test in the near future if transferring or adding the rules from qubes.UpdatesProxy to 90-default.policy has exactly the same effect as the solution from this thread.

39

I attest that Multiple Qubes-Whonix Templates works.
I edited to remote the ā€œUntestedā€ status.
Methodology: tor-ctrl-stream, watching for deb.* requests.

I commented the /etc/qubes-rpc/policy/qubes.UpdatesProxy, donā€™t know if removing it affects something.

Qubes uses first match, not last match. This is why 30-user.policy overrule 90-default.policy.

1 Like