sys-whonix starts unintentionally

Qubes-Whonix
1

Hello Users,

I have recently updated to Qubes 4.1.1 and tested some things.

Nevertheless, I have a question.

Overall it runs very well, but I noticed one bug that has been discussed many times here and on the Qubes forum, namely starting sys-whonix when you have cloned this VM and want to update or install something, etc.

I repeated the test from back then by cloning a) sys-whonix, b) whonix-gw-16, c) whonix-ws-16 and d) anon-whonix and naming them differently. In addition, I based a whonix-16-dvm-2 on whonix-16-ws-2.

I connected the cloned Qubes in the same way as the originals, so that quasi a parallel independent system was created and should behave in the same way.

This also works.

But only if you

  1. start the cloned Qubes from the app menu or

  2. activates the, say anon-whonix-2 from the Qube manager.

It does not work if you

starts the cloned Qubes (i.e. whonix-ws-16-2 and whonix-gw-16-2) from the Qube manager, for example to update them or to install or program something.

In this case the original, i.e. sys-whonix, always starts too!

I then went through all the known links and sources in the forums describing the problem and tried everything (including creating a 50_user.confi file with the known lines), but the problem persists.

I also tried (on Marmarek’s suggestion in the corresponding Github topic) to add a corresponding line with rules in the new policy guideline for Whonix, but it’s of no use.

Hence my questions:

Am I doing something wrong?

Or is the problem persistent and one of the big unsolved problems?

How does it behave with the Qubes updater? There is no way to check if the update of e.g. whonix-ws-16-2 is now done via sys-whonix-2 or via sys-whonix.

Or do I have to create a special kicksecure-16-Qube and then disable the autostart for sys-whonix? It is not clear from the instructions in which Qube to disable autostart (I assume for sys-whonix).

I raise this issue because I consider it a not insignificant security risk. Assuming sys-whonix would be compromised and the new clones are not yet, a user in the background would run the risk that when sys-whonix is activated, a temporal correlation analysis is possible (because both “sys-whonixes” are running in parallel), not to mention the possible updating of the clones via a compromised sys-whonix.

I thought of a way that might work to get around the problem if it can’t be solved any other way (yet), and if it’s just updating the clones.

You simply set the original sys-whonix to the cloned gateway (i.e. whonix-gw-16-2) for an update of the clones. Since sys-whonix turns on when you update anyway, you would then have the gateway from the cloned system.

This is not ideal, but a start. What do you think?

Thank you already for interesting information!

2

Did you follow instructions?

3

Yes, I did.
The only point I am not sure about is in which VM the swdate-gui.d folder and the 50_user.conf file must be created along with its contents. I had tried it in the clones (sys-whonix 2) and the sys-whonix itself and in the workstations but it never worked.

Thanks again.

4

That documentation chapter has been updated just now. Does that answer your question?

https://www.whonix.org/wiki/Multiple_Whonix-Workstation#Qubes-Whonix_%E2%84%A2

Don’t add a space between sys-whonix and 2.

wrong:

sys-whonix 2

correct:

sys-whonix2

Link would be useful.
But none of that is required. A fully updated Qubes already has the correct version.
If it was required, it would be mentioned in the wiki.
Even if instructions are incomplete, there would be at least a notice and a link.
The instructions in the wiki are currently complete as is.
→ Wiki is the Primary Source of Information vs Forums

Manually changing files in /etc in dom0 can actually lead to issues if done incorrectly. Next time the file is updated, there will just an additional .rpmnew file in that folder. (That is Qubes / Fedora behavior. Unspecific to Whonix.) The actual file isn’t updated.

Github issues and recommendations are probably valid at the time for the user but once the issue is resolved, the source code updated, copying interim ideas from the developer discussion to the system could lead to issues.

Added in the same wiki chapter documentation on how to check in which files what content is expected.

In case of issues, see footnote.

That’s a Qubes issue:

5

To avoid any unexpected autostart of sys-whonix, you could consider to delete the default sys-whonix.

It’s an issue for sure, it’s mentioned in the footnotes of the same wiki pages.

Qubes for security, sure, however Qubes has many issues which prevent it from being a perfect choice for a split VM design anonymity distribution such as Whonix running on top of it. Listed here:
Why use VirtualBox over Qubes?

6

Thanks for the tips - I’ll try the updated version of the chapter again and then report back here. Maybe I have overlooked something. The problem with the Qubes updater must of course be solved by Qubes itself. By the way, in this context I have tested - just by the way - updating via “Onionizing”. It is too slow and works only very rarely.

Then this link is not necessary?:

https://www.kicksecure.com/wiki/Swdate-gui#Disable_Autostart

I know about the space; I had inserted it here in the text for better readability.

I can’t find the link to Marmarek’s suggestion anymore, he suggested a line in the 80-policy where you set the autostart of sys-whonix to “no”. I had tested that and written it into the new policy for whonix, with no effect.

Deleting sys-whonix is a possibility, but would contradict an intention to use the two systems for different purposes, since there would be only one sys-whonix VM. As a test, however, it could be done.

I can only agree with the problems of Qubes mentioned in the last paragraph; especially it does not seem sensible to allow settings at all that endanger the security in the core, such as the possible switching of a whonix-vm to sys-net etc or also the Qubes updater.

7

Edit: I did everything again exactly as described in the wiki:

Created the appropriate folder in the cloned whonix-ws-16-2 on the appropriate path and set the gateway=sys-whonix-2. It has no effect; opening whonix-ws-16-2 in the Qube manager starts sys-whonix.

Otherwise, everything is as described in my first post above: if you start anon-whonix-2 or whonix-16-dvm-2 in the Qubes manager or in the app menu, sys-whonix-2 also starts correctly.

But if you start whonix-ws-16-2 from the app menu (e.g. to use the terminal), sys-whonix starts instead of sys-whonix-2.

If one starts whonix-gw-16-2 from the app menu, only this started at a first attempt, but could not be shut down normally, but only with kill command. On the second attempt, sys-whonix started instead of sys-whonix-2.

All in all, a rather unsatisfactory situation; however, in contrast to Q 4.0.4, it is already progress that at least the anon-whonix-16-2 and the whonix-16-dvm-2 can be started from the app menu and from the Qube manager with sys-whonix-2 (without having made a file change as above).

8

This is probably this issue:

Unrelated to sdwdate-gui settings.

Check UpdateVM settings.

dom0 file:

/etc/qubes-rpc/policy/qubes.UpdatesProxy

That’s the file that is probably mis-configured since I guess you weren’t aware of it which I am not surprised about. That’s difficult to guess. Hence, above Qubes bug report.

Documentation:

Delete sys-whonix (the default one which auto starts unexpected) and use sys-whonix2, sys-whonix3, sys-whonix3, etc. instead.

9

I experimented with the UpdatesProxy-file and implemented the suggestions:

Here is the sample configuration:

Initial state:

$tag:whonix.updatevm default allow,target=sys-whonix
$tag:whonix.updatevm $anyvm deny

State after the change:

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

Then under Global-Settings I set the update for dom0 to sys-whonix-2.

Before that, I cloned sys-whonix-2, renamed it to sys-whonix-TEST, coupled all VMs depending on this VM to sys-whonix-TEST and then deleted the original “sys-whonix” file as suggested and ran above tests.

Result: no change in behavior.

Maybe it is also related to the new policy structure introduced with 4.1 and there are logical contradictions. But I have to deal with this new system first, so these are just guesses.

I then test started anon-whonix from the Qube manager, which was now assigned to the newly created and renamed sys-whonix-TEST (for security reasons I had completely disconnected the system from the router).

The following error message was displayed:

A red warning icon and the message:

DENIED: whonix.NewStatus
Denied whonix.Newstatus+status from anon-whonix-2 to sys-whonix

Then I repeated the whole thing, also from the Qube-Manager, with anon-whonix-2 (which is linked to sys-whonix-2), and the same error message appears with reference to sys-whonix - although sys-whonix-2 starts correctly.

I then did the same thing again with the internet enabled - each time the error message appears several times, even though the net connection is present.

I conclude that sys-whonix still appears in the corresponding status file instead of sys-whonix-TEST despite the change of assignment and that there is an error somewhere here as well or the problem is even deeper in the system.

Edit: I just renamed sys-whonix-TEST back to sys-whonix.
As a result, all the assigned VMs also automatically renamed themselves from sys-whonix-TEST to sys-whonix, that is, without me having to change anything in the menu of each machine. I wonder if such behavior is intentional or even good.

10

2 components are related here.

  • A) Qubes dom0 UpdateVM settings
  • B) Qubes dom0 sdwdate-gui qrexec settings

That is sdwdate-gui Qubes dom0 qrexec related. Could be a missing qvm-tag issue.

New wiki chapters being written just now.

$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.

See documentation here:
https://www.whonix.org/wiki/Multiple_Qubes-Whonix_Templates#Additional_Settings

This is yet another Qubes component that is indeed related here. Some documentation that maybe also needs some writing improvement here:

That is a Qubes dom0 behavior that would have to be discussed at / reported to Qubes as per What to post in this Qubes-Whonix forum and what not.

11

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.

12

/etc/qubes/policy.d/80-whonix-policy
/etc/qubes/policy.d/80-whonix.policy

/etc/qubes/policy.d/80-whonix.policy

the policy.d folder is not present

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.)

13

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”.

14

You could post the link. Would make it easier.

15

Of course, here it is:

especially last paragraph

16

Question Where is policy.d-folder? Cannot find it - General - Qubes OS Forum was answered. That forum thread is completed.

Nevertheless the question arises,

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.

17

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.

Please see this link for the new thread:

18

$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

There is no $tag whonix-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.

$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

That is - not ..

That is:
whonix-updatevm

Not:
whonix.updatevm

19

Updated just now:

Specifically:
UpdatesProxy Settings

There is now a complete example.

20

Thanks for the revised instructions and tips.

I will try this according to these instructions and then report here about the results.