Cannot deactivate automatically start sys-whonix on boot.

[buquser]

Qubes OS version:

R3.2

Affected TemplateVMs:

sys-whonix (whonix-gw) / dom0

---

Steps to reproduce the behavior:

Remove sys-whonix VM.
Create VM:
- Type ProxyVM
- Name sys-whonix
- Template whonix-gw
- NetVM sys-firewall
Disable "Start VM automatically on boot"
There is no VM that depends on sys-whonix and starts automatically on boot.
Reboot.

Expected behavior:

sys-whonix doesn't start at boot.

Actual behavior:

sys-whonix starts at boot.

General notes:

This can weaken the anonymity, if one connects automatically to different Networks with the same sys-whonix VM because of the same entry guards.

[andrewdavidwong]

The same bug applies to sys-net and, IIRC, sys-firewall.

[andrewdavidwong]

The same bug applies to sys-net and, IIRC, sys-firewall.

[buquser]

The same bug doesn't apply to sys-net and sys-firewall. If I set the NetVM of sys-whonix to none only sys-whonix will start automatically.

[buquser]

The same bug doesn't apply to sys-net and sys-firewall. If I set the NetVM of sys-whonix to none only sys-whonix will start automatically.

[andrewdavidwong]

The same bug doesn't apply to sys-net and sys-firewall. If I set the NetVM of sys-whonix to none only sys-whonix will start automatically.

Did you do something special to prevent sys-net and sys-firewall from autostarting? Even after I uncheck "Start VM automatically on boot" for both of them in Qubes Manager on 3.2, they both still autostart. Other users have reported the same.

[andrewdavidwong]

The same bug doesn't apply to sys-net and sys-firewall. If I set the NetVM of sys-whonix to none only sys-whonix will start automatically.

Did you do something special to prevent sys-net and sys-firewall from autostarting? Even after I uncheck "Start VM automatically on boot" for both of them in Qubes Manager on 3.2, they both still autostart. Other users have reported the same.

[marmarek]

In Qubes 3.2, default netvm is started by separate service. You can disable this behavior by: systemctl disable qubes-netvm.service

[marmarek]

In Qubes 3.2, default netvm is started by separate service. You can disable this behavior by: systemctl disable qubes-netvm.service

[andrewdavidwong]

In Qubes 3.2, default netvm is started by separate service. You can disable this behavior by: systemctl disable qubes-netvm.service

Then that's exactly what deselecting "Start VM automatically on boot" in sys-net's VM settings should do. Filed separately as #3606.

[andrewdavidwong]

In Qubes 3.2, default netvm is started by separate service. You can disable this behavior by: systemctl disable qubes-netvm.service

Then that's exactly what deselecting "Start VM automatically on boot" in sys-net's VM settings should do. Filed separately as #3606.

[buquser]

sys-whonix is my default netvm so systemctl disable qubes-netvm.service works for me. But why this service exists anyway? It should be the purpose of the "Start VM automatically on boot"-option. Maybe this is more related to #3606.
Should I create a new Issue for the possibility of selecting "none" as default-netvm? This could prevent starting the netvm as well and it could prevent leaks by mistakenly setup a VM with the wrong netvm.
What are the features of the default-netvm?
- It starts automatically
- It's selected automatically when creating a new vm
- anything else?

[buquser]

sys-whonix is my default netvm so systemctl disable qubes-netvm.service works for me. But why this service exists anyway? It should be the purpose of the "Start VM automatically on boot"-option. Maybe this is more related to #3606.
Should I create a new Issue for the possibility of selecting "none" as default-netvm? This could prevent starting the netvm as well and it could prevent leaks by mistakenly setup a VM with the wrong netvm.
What are the features of the default-netvm?
- It starts automatically
- It's selected automatically when creating a new vm
- anything else?

[marmarek]

What are the features of the default-netvm?

Those you mentioned + used for all the VMs that use default netvm (see qvm-ls - netvm marked with star). So changing default netvm will change netvm for all those VMs.

The default-netvm service exists to workaround poor handling of concurrent VM startups in Qubes 3.x. In most cases starting a VM will trigger also starting its netvm and when multiple such VMs are started (with autostart=True), some of those netvm startup will end up with "already running" error and may fail the actual VM startup. At least that was the case a long time ago, I'll verify, maybe it isn't needed anymore.

[marmarek]

What are the features of the default-netvm?

Those you mentioned + used for all the VMs that use default netvm (see qvm-ls - netvm marked with star). So changing default netvm will change netvm for all those VMs.

The default-netvm service exists to workaround poor handling of concurrent VM startups in Qubes 3.x. In most cases starting a VM will trigger also starting its netvm and when multiple such VMs are started (with autostart=True), some of those netvm startup will end up with "already running" error and may fail the actual VM startup. At least that was the case a long time ago, I'll verify, maybe it isn't needed anymore.

[adrelanos]

This can weaken the anonymity, if one connects automatically to different Networks with the same sys-whonix VM because of the same entry guards.

Reference: https://www.whonix.org/wiki/Tor#Entry_Guards

---

https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/sys-whonix.sls#L35 comes with

- autostart: true

[adrelanos]

This can weaken the anonymity, if one connects automatically to different Networks with the same sys-whonix VM because of the same entry guards.

Reference: https://www.whonix.org/wiki/Tor#Entry_Guards

---

https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/sys-whonix.sls#L35 comes with

- autostart: true

[adrelanos]

sys-whonix enabled autostart advantages:

Most users will have Tor fully connected by the time they start a Whonix based AppVM / DispVM.

sys-whonix enabled autostart disadvantages:

It makes things more difficult for users who understood the hard to digest information explained on https://www.whonix.org/wiki/Tor#Entry_Guards which will be a tiny minority.

sys-whonix disabled autostart disadvantages:

Tor using applications such as Tor Browser will show connection refused errors since Tor takes a while to connect and since the Qubes user interface sdwdate-gui-qubes is not ready yet (but we're getting closer to that).

---

Resolution? We'll recommend on https://www.whonix.org/wiki/Tor#Entry_Guards to use Qubes R4.0 and to disable autostart of sys-whonix. Opinions?

[adrelanos]

sys-whonix enabled autostart advantages:

Most users will have Tor fully connected by the time they start a Whonix based AppVM / DispVM.

sys-whonix enabled autostart disadvantages:

It makes things more difficult for users who understood the hard to digest information explained on https://www.whonix.org/wiki/Tor#Entry_Guards which will be a tiny minority.

sys-whonix disabled autostart disadvantages:

Tor using applications such as Tor Browser will show connection refused errors since Tor takes a while to connect and since the Qubes user interface sdwdate-gui-qubes is not ready yet (but we're getting closer to that).

---

Resolution? We'll recommend on https://www.whonix.org/wiki/Tor#Entry_Guards to use Qubes R4.0 and to disable autostart of sys-whonix. Opinions?

[andrewdavidwong]

I think https://www.whonix.org/wiki/Tor#Entry_Guards needs to explain things more clearly. Here's an example:

Consider the following scenario. A user connects to Tor via a laptop at their home address. Soon afterwards, the same user attends a prominent event or protest in a nearby city. At that location, the user decides to anonymously blog about what transpired using the same laptop. This is problematic for anonymity, as the Tor client is using the same entry guard normally correlated with the user’s home address.

In most cases, Tor users accept that their home ISPs can see that they're using Tor, but it's okay, because all the ISP sees is the entry guard. The ISP can't see beyond the entry guard, so the ISP doesn't know what the user is doing anonymously via Tor. Now, suppose I go to that protest in a nearby city and try to blog about it anonymously via Tor. I'm using the same entry guard that I normally use at home, but now I'm using it on a different network that can see the entry guard I'm using. Let's even suppose that they figure out that it's the same entry guard that I use at home. Again, the new network can see only that I'm using Tor by using this entry guard. They still can't see beyond the entry guard, because that's the point of entry guards, so they still can't see what I'm doing anonymously via Tor. Why exactly is this problematic?

Network adversaries who are monitoring traffic have a high degree of certainty that the “anonymous” posts from the city location are related to the same person who connected to that specific guard relay at home.

How? Why?

[andrewdavidwong]

I think https://www.whonix.org/wiki/Tor#Entry_Guards needs to explain things more clearly. Here's an example:

Consider the following scenario. A user connects to Tor via a laptop at their home address. Soon afterwards, the same user attends a prominent event or protest in a nearby city. At that location, the user decides to anonymously blog about what transpired using the same laptop. This is problematic for anonymity, as the Tor client is using the same entry guard normally correlated with the user’s home address.

In most cases, Tor users accept that their home ISPs can see that they're using Tor, but it's okay, because all the ISP sees is the entry guard. The ISP can't see beyond the entry guard, so the ISP doesn't know what the user is doing anonymously via Tor. Now, suppose I go to that protest in a nearby city and try to blog about it anonymously via Tor. I'm using the same entry guard that I normally use at home, but now I'm using it on a different network that can see the entry guard I'm using. Let's even suppose that they figure out that it's the same entry guard that I use at home. Again, the new network can see only that I'm using Tor by using this entry guard. They still can't see beyond the entry guard, because that's the point of entry guards, so they still can't see what I'm doing anonymously via Tor. Why exactly is this problematic?

Network adversaries who are monitoring traffic have a high degree of certainty that the “anonymous” posts from the city location are related to the same person who connected to that specific guard relay at home.

How? Why?