Skip to content
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

Closed
mirrorway opened this issue Feb 3, 2018 · 19 comments
Closed

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

mirrorway opened this issue Feb 3, 2018 · 19 comments
Labels
C: core C: templates C: Whonix This issue impacts Qubes-Whonix privacy This issue pertains to data or information privacy through technological means. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. ux User experience

Comments

@mirrorway
Copy link

mirrorway commented Feb 3, 2018

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.

@mirrorway mirrorway changed the title template updates ignore UpdateVM setting templates update over clearnet even when UpdateVM set to sys-whonix Feb 3, 2018
@andrewdavidwong andrewdavidwong added T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. C: core C: templates labels Feb 3, 2018
@andrewdavidwong andrewdavidwong added this to the Release 4.0 milestone Feb 3, 2018
@andrewdavidwong andrewdavidwong added privacy This issue pertains to data or information privacy through technological means. C: Whonix This issue impacts Qubes-Whonix labels Feb 3, 2018
@marmarek
Copy link
Member

marmarek commented Feb 5, 2018

"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
Copy link
Member

marmarek commented Feb 5, 2018

Related: #3412, #3118

@adrelanos
Copy link
Member

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
Copy link
Author

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.

marmarek referenced this issue in QubesOS/qubes-policy-control Feb 12, 2018
Not tested. No packaging.
@TimFW
Copy link

TimFW commented Feb 13, 2018

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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
Copy link

sorandom commented Mar 27, 2018

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
Copy link
Author

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

@andrewdavidwong andrewdavidwong added the ux User experience label Mar 28, 2018
@sorandom
Copy link

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
Copy link

awokd commented May 6, 2018

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 templates update over clearnet even when UpdateVM set to sys-whonix #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
Copy link

awokd commented May 6, 2018

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?

@bigdx
Copy link

bigdx commented Oct 26, 2018

To be honest, I am not sure if I just missunderstood something or have a bug ...
Would a freshly installed template of fedora-28 automaticly use that UpdateVM (defined in /etc/qubes-rpc/policy/qubes.UpdatesProxy) for updates/installations from "inside" (for example using dnf/yum in a terminal running in the fedora-28 template)? Or is UpdateVM only relevant for updates via Qubes Manager?

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"?

@marmarek
Copy link
Member

This one is about /etc/qubes-rpc/policy/qubes.UpdatesProxy and it being separate thing than global updatevm property.

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.

Known issue: #3815
But yum/dnf should work. This is what Qubes Manager calls.

@bigdx
Copy link

bigdx commented Oct 26, 2018

Known issue: #3815
But yum/dnf should work. This is what Qubes Manager calls.

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?

@marmarek
Copy link
Member

just a proxy to for the connection?

This one.

If it is just proxy, setting NetVM makes no big difference, right?

Yes.

Anyway, shall I dump that template because it hade NetVM-Access?

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.

@DemiMarie
Copy link

I think this is already fixed in R4.2, inasmuch as the new global settings UI handles this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core C: templates C: Whonix This issue impacts Qubes-Whonix privacy This issue pertains to data or information privacy through technological means. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. ux User experience
Projects
None yet
Development

No branches or pull requests

9 participants