Qubes 4.2 -> 4.3 (Whonix 17 -> 18) - Denied sdwdate-gui.ConnectCheck from anon-whonix to sys-whonix

Qubes-Whonix
1

Rather than follow the qubes-dist-upgrade or release-upgrade approach to moving to Qubes 4.3 / Whonix 18 I decided to factory reset and rebulid my various qubes. Here are a couple Whonix-releated things I noticed during the process.

(1) Switching the template of an existing anon-vm qube from whonix-workstation-17 to whonix-workstation-18:

After starting the qube I saw looping notifications, Denied sdwdate-gui.ConnectCheck from <anon qube> to sys-whonix. Noted elsewhere on the forums, and expected. To ‘fix’ this I create a new anon qube and qvm-copy over the /home/user/.tb dir from the old qube. Seems to be working fine. I think there is nothing wrong in doing this? The browser session is intended to be persistent, not ephemeral/anonymous.

(2) Running update-torbrowser on a fresh whonix-workstation-18 template:

(See other post: `rm` errors when running `update-torbrowser` on a `fresh whonix-workstation-18` template)

Thanks!

1 Like
2

It might be lacking a dom0 some qvm-tags. How to check and how to add them, documented just now:
Denied sdwdate-gui.ConnectCheck from anon-whonix to sys-whonix

Please let me know if that can fix the issue.

This shouldn’t be related at all. sdwdate-gui.ConnectCheck has no relationship with tb-updater / update-torbrowser whatsoever.

1 forum topic = 1 issue please.

2 Likes
3

Yes, it’s as you said. Adding the sdwdate-gui-client tag to the anon vm fixes the issue. Thanks.

Something interesting I discovered:

[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
[user@dom0 ~]$ qvm-clone anon-vm-originally-ws-17 anon-vm-clone
anon-vm-clone: Cloning private volume
[user@dom0 ~]$ qvm-tags anon-vm-clone
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
sdwdate-gui-client

Cloning or renaming the ws17-origin anon vm will automatically add the missing sdwdate-gui-client tag to to the new qube (but not to the original qube).

2 Likes
4

You are running Qubes R4.3, right? (It sounds like you are, but I wanted to double-check.) qubes-core-admin-addon-whonix (which is preinstalled in R4.3) should automatically add the sdwdate-gui-client tag to any Whonix-Workstation VMs any time a domain-load event is triggered in qubes-core-admin. In concrete terms, this event gets triggered on every single VM when dom0 is restarted, or when the qubesd service is restarted.

If you run sudo systemctl restart qubes.service in dom0, does anon-vm-originally-ws-17 gain the sdwdate-gui-client tag? (Be warned that restarting qubesd can cause some odd behavior, for instance Qube Manager might crash, so make sure you aren’t doing any important work when you try this.)

3 Likes
5

It’s as you said. :+1:

[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17-other
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
[user@dom0 ~]$ sudo systemctl restart qubesd.service
[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
sdwdate-gui-client
[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17-other
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
sdwdate-gui-client
3 Likes
6

Perfect. I’ll see if I can find a good place to document that a qubesd restart is needed to “sync” tags in some instances.

2 Likes
7

So it will work for all whonix based app qubes? Including sys-whonix? Will it work for kicksecure based app qubes?

And if I understand you correctly, a system restart will also do the job?

1 Like
8

It should.

It should thanks to GitHub - QubesOS/qubes-core-admin-addon-kicksecure: Kicksecure core-admin plugin. For any Kicksecure specific issues, please use https://forums.kicksecure.com.

Yes. Restarting the system will also result in a restart of dom0 qubesd.service systemd unit.

2 Likes
9

Updated just now.

2 Likes
10

In Kicksecure, there is a unique issue: after an upgrade, all app qubes and disposable VMs work fine after a reboot, but named disposables based on a Kicksecure app qube do not automatically receive the qvm-tag on reboot, you have to add the tag manually.

1 Like
11

Known issue, the fix is already created though I haven’t checked if it’s in the Qubes OS repositories yet or not. See:

2 Likes
12

If the solution is implemented, it will not affect freshly installed Qubes OS when restoring named disposables from 4.2. A dom0 update will be rquired first. But will that be available in an in-place upgrade without additional dom0 update?

1 Like
13

I’m not quite sure what you mean by “additional dom0 update” in this context. dom0 will need to be updated in order for the fix to be installed, yes, but you should (indeed, must if you want to remain secure) be updating dom0 regularly along with the rest of your VMs, which should pull the fix in automatically. Once the fix is installed, rebooting should automatically tag the VMs.

2 Likes
14

Ofcourse I know We’ve to regularly install updates especially of dom0.

What I mean is that when a person freshly install QubesOS, this fix will not be there until the person update dom0. So on fresh install if a person restore previous named disposable of kicksecure, he will face the same issue.

1 Like
15

True, but once they update and reboot, the issue will go away. (And once R4.3.1 is published, the fix will be on the ISO itself most likely.)

2 Likes