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?
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.
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).
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.
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.
2 components are related here.
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.
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.
/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.)
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”.
You could post the link. Would make it easier.
Of course, here it is:
especially last paragraph
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.
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:
$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
Thanks for the revised instructions and tips.
I will try this according to these instructions and then report here about the results.
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.
Could be qrexec.
In dom0. Watch journalctl and see qrexec calls.
sudo journalctl -f
Thank you, I´ll try this and summarize the results, perhaps there is any solution.
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.