Whonix templates and update issues (also crash)

User Support
1

Hi, I have been using Qubes for a while, I like it, but updating and networking makes me puzzled

I wanted to upgrade my Whonix templates so I opened the Qubes updater tool. Updating whonix-gw went just fine after I set up Tor connection.

Then whonix-ws update. First time the whole computer crashed. No kernel panics or errors or anything, just black screens and instant reboot.

Second try, the upgrade failed and there were errors of failed connection or unable to fetch stuff and so on. Third try, failed too but this time the Qubes updater announced new updates for Whonix-ws. On my fourth try the upgrade was finally successful.

The crash was very suspicious, like how would that happen just during Whonix template updates and why did it reboot instantly? Maybe Iā€™m paranoid but I instantly thought about some weird exploits going on??

Also the whole update process for whonix templates looks very complex. First it starts the disposable mgmt VM like any other update. Then the template itself, then sys-whonix. So the update happens over Tor, via sys-whonix I see, but how does the template or mgmt VM know that it must use sys-whonix for network?

I mean, anon-whonix has sys-whonix as NetVM but the templates only have ā€œn/aā€ as their NetVM. The setting to use sys-whonix is hidden somewhere?

How does the update system work overall? Dom0 updates are downloaded in sys-firewall and moved into Dom0 but how about standard templates updates, or whonix templates?

What if you want Tor over VPN and set up another qube for VPN routing, set sys-whonix use this qube as NetVM: can you be sure that all whonix updates go over Tor and this VPN still?

ANd how about installing or updating software in normal templates? You start a terminal in the template and use dnf/apt, but NetVM of templates is N/A. How are the packages downloaded?

One more thing, the whonix system check dialog tells you to update via commands - open terminal in the whonix template and use ā€œupgrade-nonrootā€. Not Qubes updater tool. In Qubes documentation itā€™s recommended to use the Qubes updater.

2

There are many topics about it on this forum. In short: yes, itā€™s possible to be sure (but Iā€™m no expert here). Also, Tor over VPN (or vice versa) is not always desirable.

This is more relevant to Whonix forums by the way, there are more experts on this.

1 Like
3

Thanks for your answer @fsflover, so updates proxy is what handles the update downloading. Still plenty of stuff to learn about Qubes, itā€™s quite a bit more complex than ordinary Linux OSā€¦

Butā€¦ Iā€™m still a little puzzled, because the template VM doesnā€™t have any IP address except loopback address, how does the proxy work then? I mean, shouldnā€™t there be an IP address for qube to qube communications anyway? :face_with_diagonal_mouth:

My qrexec policy only had lines for the whonix templates, those were configured to use sys-whonix. In my use case it would not be necessary to update over Tor but I think Iā€™ll leave it as it isā€¦

The crash was weird, not serious maybe but I get easily stressed when something like that happens. i checked journalctl and this is the last line before the crash I Thinkā€¦

Feb 12 16:02:20 dom0 qubesd[2476]: vm.whonix-ws-16: Starting whonix-ws-16

4

maybe you might want to narrow down your question, or see if you can read this, I canā€™t, so Qubes is Qubes, its not really ā€œlinuxā€ per se

https://www.qubes-os.org/doc/dom0-secure-updates/

https://www.qubes-os.org/doc/salt/

yeah, you could edit qrexec policy / but wise to not to , depending on your abilities

5

Hm, yeah, Iā€™ll let the Whonix templates update over Tor for nowā€¦ as it is by default I thinkā€¦

But still confused, how is the updates/packages transfered into templates? Thereā€™s no netVM for templates so it canā€™t go over the network stack, right? Documentation tells me ā€œThe updates proxy uses RPC/qrexec.ā€

No crashes since my first post, but I wonder, how can one VM starting crash the whole system like that.

6

The proxy is running in selected VMs (by default all the NetVMs (1)) and intercepts traffic directed to 10.137.255.254:8082.

See here: updates-proxy

7

yes, yesā€¦ but how does the template get connection to netVM (where the proxy is) when it doesnā€™t even have a net access configured? It doesnā€™t have NetVM, no IP address, nothing. Thereā€™s some other way it communicates to the NetVM?

8

And againā€¦

The updates proxy uses RPC/qrexecā€¦ This new design allows for templates to be updated even when they are not connected to any NetVM.

Why do you assume you need networking in order two VMs to communicate to each other (this is rather rethoric)?

And donā€™t forget that in between, as additional security mechanism we actually have default-mgmt-dvm

9

So itā€™s qrexec that also has the function to transfer files from qube to qubeā€¦ ok. I need to read that page carefully, thanks.

Today I updated whonix-gw-16, it went well. Updating whonix-ws-16 didnā€™t. Error message was something about ā€œcommand returned non zeroā€ā€¦ However it also showed that some packages were upgradedā€¦ so did it fail or not??

Then I tried to start the ā€œsystem checkā€ app in a disposable whonix, but started it accidentally in the Whonix DVM template instead. Didnā€™t want to wait until it really starts, so I hit shutdown on the template. It didnā€™t want to shut down and Qube manager freezed.

So yes, Qubes is awesome in many ways but some bugs exist, it seems :face_with_diagonal_mouth:

10

Bugs were ā€˜sold" to us as something normal from at least the early 80ā€™s. So itā€™s not Qubesā€™ exclusivity.
IOT will make it no device could be bought, you turn it on by pressing the power switch and it worked as declared until the end of days, and you shut it off by pressing the very same switch and it is gracefully.