-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
templates update over clearnet even when UpdateVM set to sys-whonix #3527
Comments
"updatevm" property is currently only about dom0 updates. Updates for templates can be configured in |
I suggest dom0 should also use config file |
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. |
Not tested. No packaging.
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. |
No, each template can have different one. For example whonix-* templates use sys-whonix. |
Proposal for dom0 UpdateVM (please rename (#3412) When setting, Qubes VM Settings -> Global Settings ->
When setting, Qubes VM Settings -> Global Settings ->
Does that sound good? |
Or so.
Doest that make sense? Would it even be acceptable for Qubes VM Manager to modify |
The thing is dom0 updates works totally differently than template updates:
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). |
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? |
What about the "Check for updates" option, does it use UpdateVM or the AppVM's NetVM? |
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. |
How about a single
|
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):
This approach would be easier to code too. I might even be able to manage it, if it looks reasonable? |
To be honest, I am not sure if I just missunderstood something or have a bug ... Because the App "Software" doesn't work without a NetVM set, though. It acts like the VM is offline, what is somehow correct ("Go Online"). dnf/yum same thing. Updates thru Qubes Manager worked fine all the time. I had NetVM set to sys-firewall for updates and installation (with dnf) of some tools for my fedora-28 template. Is it now still "secure"? |
This one is about
Known issue: #3815 |
Strange, like I said, dnf didnt work, now does. To get it clear: Normally (by default) using dnf in the template will use the defined updatevm the same way as dom0 (2 phases, see https://www.qubes-os.org/doc/software-update-dom0/) OR is it just a proxy to for the connection? If it is just proxy, setting NetVM makes no big difference, right? Anyway, shall I dump that template because it hade NetVM-Access? |
This one.
Yes.
Giving network access only to package manager is protection mostly against mistakes, like opening random web pages in the template. If you're careful, using template with netvm connected should be ok. |
I think this is already fixed in R4.2, inasmuch as the new global settings UI handles this. |
Qubes OS version:
R4.0 rc4, rc3
Affected TemplateVMs:
debian-9 at least
Steps to reproduce the behavior:
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.
The text was updated successfully, but these errors were encountered: