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
start the cloned Qubes from the app menu or
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!