templates update over clearnet even when UpdateVM set to sys-whonix

[mirrorway]

Qubes OS version:

R4.0 rc4, rc3

Affected TemplateVMs:

debian-9 at least

Steps to reproduce the behavior:

1. Set UpdateVM to sys-whonix
2. Run apt update / apt upgrade in a debian template

Expected behavior:

Downloads updates over tor.

Actual behavior:

Downloads updates over clearnet.

There is little traffic on sys-whonix's eth0, as can be seen by repeatedly running cat /sys/class/net/eth0/statistics/rx_bytes

General notes:

dom0 updates go through sys-whonix, as expected.

Related issues:

R3.2 also exhibited this behavior but you can work around it by setting netvm to sys-whonix.

In R4.0 netvm of templates is set to None by default, so you expect all update-related traffic to go out through the user's choice of UpdateVM.

[marmarek]

"updatevm" property is currently only about dom0 updates. Updates for templates can be configured in /etc/qubes-rpc/policy/qubes.UpdatesProxy (target= option for appropriate template).
But yes, this is something we need to improve.

[marmarek]

"updatevm" property is currently only about dom0 updates. Updates for templates can be configured in /etc/qubes-rpc/policy/qubes.UpdatesProxy (target= option for appropriate template).
But yes, this is something we need to improve.

[marmarek]

Related: #3412, #3118

[marmarek]

Related: #3412, #3118

[adrelanos]

I suggest dom0 should also use config file /etc/qubes-rpc/policy/qubes.UpdatesProxy. No special mechanism. (At least not user facing.) Otherwise too difficult for users, and way too easy to mess up.

[adrelanos]

I suggest dom0 should also use config file /etc/qubes-rpc/policy/qubes.UpdatesProxy. No special mechanism. (At least not user facing.) Otherwise too difficult for users, and way too easy to mess up.

[mirrorway]

IMHO UpdateVM should be used for both. Why would anyone want to get just their dom0 updates over tor but their template updates over clearnet? The latter also contacts qubes-os.org, identifying you as a qubes user, and provides eavesdroppers with the specific version of each of your installed packages.

[mirrorway]

IMHO UpdateVM should be used for both. Why would anyone want to get just their dom0 updates over tor but their template updates over clearnet? The latter also contacts qubes-os.org, identifying you as a qubes user, and provides eavesdroppers with the specific version of each of your installed packages.

[TimFW]

Maybe I a am misunderstanding but with qubes.UpdatesProxy do all templates have to use that single target for updates? If so then I would much rather than both the qubes.UpdatesProxy and UpdateVM so we can have a choice. I can see scenarios where I what to ensure all dom0 updates are tor and templates are thru clear or vpn etc. To me its as simple as having the documentation. You could even have a warning popup if need be.

[TimFW]

Maybe I a am misunderstanding but with qubes.UpdatesProxy do all templates have to use that single target for updates? If so then I would much rather than both the qubes.UpdatesProxy and UpdateVM so we can have a choice. I can see scenarios where I what to ensure all dom0 updates are tor and templates are thru clear or vpn etc. To me its as simple as having the documentation. You could even have a warning popup if need be.

[marmarek]

Maybe I a am misunderstanding but with qubes.UpdatesProxy do all templates have to use that single target for updates?

No, each template can have different one. For example whonix-* templates use sys-whonix.

[marmarek]

Maybe I a am misunderstanding but with qubes.UpdatesProxy do all templates have to use that single target for updates?

No, each template can have different one. For example whonix-* templates use sys-whonix.

[adrelanos]

Qubes VM Settings -> Global Settings

Global Settings implies "global", "default", "for everything". Currently UpdateVM should be replaced by dom0 UpdateVM. But that's not perfect either.

---

Proposal for Qubes VM Settings -> Global Settings:

dom0 UpdateVM (please rename UpdateVM to dom0 UpdateVM)
ClockVM
Default netVM
Default UpdateVM (please add)
Default template

(#3412)

---

When setting, Qubes VM Settings -> Global Settings -> Default UpdateVM to let's says sys-firewall

• should work similar to Default netVM setting
• dom0 should use sys-firewall as UpdateVM (If dom0 UpdateVM is set to default.)
• all TemplateVMs except those with explicitly configured UpdateVM settings (i.e. except Whonix VMs!) should use sys-firewall as their UpdateVM

---

When setting, Qubes VM Settings -> Global Settings -> Default UpdateVM to let's says sys-whonix

• should work similar to Default netVM setting
• dom0 should use sys-whonix as UpdateVM (If dom0 UpdateVM is set to default.)
• all TemplateVMs should use sys-whonix as their UpdateVM

---

Does that sound good?

[adrelanos]

Qubes VM Settings -> Global Settings

Global Settings implies "global", "default", "for everything". Currently UpdateVM should be replaced by dom0 UpdateVM. But that's not perfect either.

---

Proposal for Qubes VM Settings -> Global Settings:

dom0 UpdateVM (please rename UpdateVM to dom0 UpdateVM)
ClockVM
Default netVM
Default UpdateVM (please add)
Default template

(#3412)

---

When setting, Qubes VM Settings -> Global Settings -> Default UpdateVM to let's says sys-firewall

• should work similar to Default netVM setting
• dom0 should use sys-firewall as UpdateVM (If dom0 UpdateVM is set to default.)
• all TemplateVMs except those with explicitly configured UpdateVM settings (i.e. except Whonix VMs!) should use sys-firewall as their UpdateVM

---

When setting, Qubes VM Settings -> Global Settings -> Default UpdateVM to let's says sys-whonix

• should work similar to Default netVM setting
• dom0 should use sys-whonix as UpdateVM (If dom0 UpdateVM is set to default.)
• all TemplateVMs should use sys-whonix as their UpdateVM

---

Does that sound good?

[adrelanos]

I suggest dom0 should also use config file /etc/qubes-rpc/policy/qubes.UpdatesProxy. No special mechanism. (At least not user facing.) Otherwise too difficult for users, and way too easy to mess up.

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

default=sys-firewall

$type:TemplateVM $default allow,target=default

dom0 $default allow,target=default

$anyvm $anyvm deny

Or so.

Default UpdateVM setting could change default=sys-firewall to default=sys-whonix or so.

Doest that make sense?

Would it even be acceptable for Qubes VM Manager to modify /etc/qubes-rpc/policy/qubes.UpdatesProxy or how could this be implemented?

[adrelanos]

I suggest dom0 should also use config file /etc/qubes-rpc/policy/qubes.UpdatesProxy. No special mechanism. (At least not user facing.) Otherwise too difficult for users, and way too easy to mess up.

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

default=sys-firewall

$type:TemplateVM $default allow,target=default

dom0 $default allow,target=default

$anyvm $anyvm deny

Or so.

Default UpdateVM setting could change default=sys-firewall to default=sys-whonix or so.

Doest that make sense?

Would it even be acceptable for Qubes VM Manager to modify /etc/qubes-rpc/policy/qubes.UpdatesProxy or how could this be implemented?

[marmarek]

The thing is dom0 updates works totally differently than template updates:

• template updates: package manager run in template, process metadata on its own, access the network through proxy
• dom0 updates: dom0 have no network at all, use selected VM to run package manger there, process metadata, resolve dependencies and download packages, then transfer them to dom0 (where signatures are checked)

This means totally different mechanisms are needed for providing "UpdateVM" function for those. UpdatesProxy (which is basically http proxy) will not work for dom0 updates.

While the same VM could provide both features, configuration (at low level) needs to be different. But it doesn't mean we couldn't provide consistent GUI for both settings (maybe even merged into one).

[marmarek]

The thing is dom0 updates works totally differently than template updates:

• template updates: package manager run in template, process metadata on its own, access the network through proxy
• dom0 updates: dom0 have no network at all, use selected VM to run package manger there, process metadata, resolve dependencies and download packages, then transfer them to dom0 (where signatures are checked)

This means totally different mechanisms are needed for providing "UpdateVM" function for those. UpdatesProxy (which is basically http proxy) will not work for dom0 updates.

While the same VM could provide both features, configuration (at low level) needs to be different. But it doesn't mean we couldn't provide consistent GUI for both settings (maybe even merged into one).

[sorandom]

I have found the reverse is also true. Selecting "updates run over tor" in the 4.0-RC4 installer, then later wanting speed and changing UpdateVM back to clearnet, caused templates to continue updating over the tor connection. That was frustrating, until I found this post.

I agree with @adrelanos' proposal to make them both visible. Would it also make sense to make them visible in the Qubes Setting screen, perhaps advanced tab, near Default DispVM?

[sorandom]

I have found the reverse is also true. Selecting "updates run over tor" in the 4.0-RC4 installer, then later wanting speed and changing UpdateVM back to clearnet, caused templates to continue updating over the tor connection. That was frustrating, until I found this post.

I agree with @adrelanos' proposal to make them both visible. Would it also make sense to make them visible in the Qubes Setting screen, perhaps advanced tab, near Default DispVM?

[mirrorway]

What about the "Check for updates" option, does it use UpdateVM or the AppVM's NetVM?

[mirrorway]

What about the "Check for updates" option, does it use UpdateVM or the AppVM's NetVM?

[sorandom]

In my experience, neither, however I was using dnf/apt from the template command line. All templates would still use sys-whonix to update even when Global Settings -> UpdateVM was set to clearnet. It did not matter if the template's NetVM was set to none or clearnet.

(dom0 was indeed using clearnet which supports the above posts.)

I was only able to resolve the issue by manually editing the file as mentioned above to change the default from sys-whonix to clearnet.

[sorandom]

In my experience, neither, however I was using dnf/apt from the template command line. All templates would still use sys-whonix to update even when Global Settings -> UpdateVM was set to clearnet. It did not matter if the template's NetVM was set to none or clearnet.

(dom0 was indeed using clearnet which supports the above posts.)

I was only able to resolve the issue by manually editing the file as mentioned above to change the default from sys-whonix to clearnet.

[awokd]

How about a single qubes-prefs updatevm setting that controls both dom0 and template updates, with the following logic:

1. Update parsing of /etc/qubes-rpc/policy/qubes.UpdatesProxy to include dom0 per #3527 (comment)
2. Changing the qubes-prefs updatevm setting to a different VM will result in a fresh /etc/qubes-rpc/policy/qubes.UpdatesProxy with the appropriate ruleset
3. Changing the setting to none results in fresh ruleset denying all updates
4. Further customizations can be made to /etc/qubes-rpc/policy/qubes.UpdatesProxy, for those who want granular control over it

[awokd]

How about a single qubes-prefs updatevm setting that controls both dom0 and template updates, with the following logic:

1. Update parsing of /etc/qubes-rpc/policy/qubes.UpdatesProxy to include dom0 per #3527 (comment)
2. Changing the qubes-prefs updatevm setting to a different VM will result in a fresh /etc/qubes-rpc/policy/qubes.UpdatesProxy with the appropriate ruleset
3. Changing the setting to none results in fresh ruleset denying all updates
4. Further customizations can be made to /etc/qubes-rpc/policy/qubes.UpdatesProxy, for those who want granular control over it

[awokd]

Or a variation, if a file about "Qubes UpdatesProxy RPC Policy" is not the correct place to store dom0 related settings (like #3527 (comment) seems to suggest):

1. Leave current usage of qubes-prefs updatevm unchanged, but hook into the code so if it gets modified:
2. Changing the qubes-prefs updatevm setting to a different VM will result in a fresh /etc/qubes-rpc/policy/qubes.UpdatesProxy with the appropriate ruleset
3. Changing the setting to none results in fresh ruleset denying all updates
4. Further customizations can be made to /etc/qubes-rpc/policy/qubes.UpdatesProxy, for those who want granular control over it

This approach would be easier to code too. I might even be able to manage it, if it looks reasonable?

[awokd]

Or a variation, if a file about "Qubes UpdatesProxy RPC Policy" is not the correct place to store dom0 related settings (like #3527 (comment) seems to suggest):

1. Leave current usage of qubes-prefs updatevm unchanged, but hook into the code so if it gets modified:
2. Changing the qubes-prefs updatevm setting to a different VM will result in a fresh /etc/qubes-rpc/policy/qubes.UpdatesProxy with the appropriate ruleset
3. Changing the setting to none results in fresh ruleset denying all updates
4. Further customizations can be made to /etc/qubes-rpc/policy/qubes.UpdatesProxy, for those who want granular control over it

This approach would be easier to code too. I might even be able to manage it, if it looks reasonable?