search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
533 stars 46 forks source link

Rethinking Qubes update proxy VM arrangement #5023

Open brendanhoar opened 5 years ago

brendanhoar commented 5 years ago

The problem you're addressing (if any) Use of sys-firewall is baked into the current update proxy topology. This presents some issues.

  1. It has led many of us to increase the memory and/or disk space allocated for sys-firewall to allow for large dom0 updates (e.g. templates/ISOs/salt-invocations) and/or multiple parallel update requests. The firewall doesn't need these additional resources most of the time but sometimes ends up consuming additional resources unnecessarily.

  2. Users who maintain two or more separate sys-net-* end up multiplying the wasted resources above by a factor of two or more.

  3. Users of alternate firewalls such as the mirage firewall now have to maintain +1 firewall configs.

Describe the solution you'd like I am suggesting that Qubes 4.1 include defaults or options for an update-specific sys-updates VM:

  1. sys-updates would be used by dom0 for all updates.
  2. sys-updates would be set to shutdown on idle.
  3. sys-firewall would be configured for even more minimal resource usage (for a "supported" firewall), perhaps even using a -minimal template (if there are memory or security PROs that beat out the distro size increase CON). Users may also feel more free to implement mirage (self-supported) for most minimal resource usage.*
  4. sys-updates could be configured as a named dispVM for automatic disk-space recovery after use.
  5. sys-update could alternately be extended for dnf/apt caching of template updates w/o interfering with separation of duties for the firewall (obviously, not using a named dispVM).

Stretch-ask ( :) ): *6. Incorporate mirage in 4.1 as well, if it meets security standards (e.g. currently PV instead of the PVH of sys-firewall).

Where is the value to a user, and who might that user be? Memory usage reduced under most scenarios, perhaps temporary increase above current usage during updates and for a few minutes afterward (mitigate: adding mirage option would likely keep below baseline always).

Disk space usage only likely to be reduced under named-dispVM approach and increased w/ dnf/apt caching options.

Describe alternatives you've considered Manually configuring Qubes in this manner is the alternative approach, which I have done, sans suggestions such as package caching or dispVM.

Related, non-duplicate issues

unman commented 5 years ago

I like all of your proposed solutions - one reason I like them is that that is exactly how I run my updates at the moment, including caching. But I dont recognise your "issues".

Use of sys-firewall is baked into the current update proxy topology

"Baked " is over-stretching it: it's the configurable default. Given that you can set another qube to act as default updateVM in /etc/qubes-rpc/policy, and that you can set any qube to act as updateVM for dom0, I dont see any significance in this. I didnt find that there were "wasted resources" in ordinary use of sys-firewall - disk space and memory seemed to be recovered after use. If your experience is different then it looks like some issues with memory and space recovery.

Since you dont have to use the updateVM as a firewall, there are no extra firewall configurations to maintain. Nor would you have to use both of the firewalls configured with the separate netvms for updates: just select the optimal route you want to use.

I'm not convinced that points 1-3 are major issues at all, and that the added value would be significant. Open to being convinced otherwise.

In order for Mirage to become the default, you also will have to incorporate the easy configuration of qubes-firewall.