Create `sys-ops-whonix` VM for Enhanced Security and Isolation in Qubes-Whonix

[adrelanos]

The problem you're addressing (if any)

Currently the Whonix-Gateway sys-whonix,

• 1) is being used as the service qube for UpdatesProxy (Qrexec service) for Qubes-Whonix,
• 2) can be used as UpdatesProxy for other Templates,
• 3) can be used as updatevm (global preference for dom0 updates),
• 4) can in the future be used as clockvm (global preference).

This is non-ideal for security and anonymity.

The main issue of having these services running is it undermines the proxy isolation of Whonix-Gateway and Whonix-Workstation separation.

In case of non-Whonix, clearnet use, where it is fine to use sys-firewall for those tasks, even though it is a Net Qube, sys-firewall is not the qube for proxy settings as well as sys-whonix is not the qube for running Qubes services, which is a task for a Whonix-Workstation, not a Whonix-Gateway, for better leak-proofness.

A vulnerability in tinyproxy marked as CVE-2023-49606 states that a specially crafted HTTP header could lead to remote code execution. In the Qubes case of using sys-whonix for hosting the tinyproxy, compromise of the Gateway means compromise of the user identity.

The solution you'd like

sys-ops-whonix - UpdatesProxy, UpdateVM, ClockVM - a new, dedicated service VM.

Proposal: An App Qube or named Disposable Whonix-Workstation with the name sys-ops-whonix

The sys-ops-whonix would be based on the Whonix-Workstation Template and its Net Qube will be set to sys-whonix by default.

The value to a user, and who that user might be

Better security and higher leak-proofness of Qubes-Whonix.

Details

• Why not use anon-whonix as sys-ops-whonix (UpdatesProxy, UpdateVM, ClockVM)? Because anon-whonix is intended for user interaction with applications such as Tor Browser. It is an App Qube.
  • On the other hand, sys-ops-whonix would be a service qube.
  • App Qubes and service qubes have different threat models, attack surface. A compromised Tor Browser should not lead to a compromised Qubes UpdatesProxy (tinyproxy) and vice versa. That is why these should run inside different VMs.
• sys-ops-whonix default Qubes dom0 AppMenu: User applications would be removed from the app menu and Tor Browser would be prevented from starting.
• App Qube vs named disposable: The qube can be a named disposable, configured just like sys-net and sys-firewall can be disposables with Salt declarations. A persistent sys-ops-whonix can be interesting for caching purposes of UpdatesProxy, but that is not a Qubes default and is unnecessary for clockvm and updatevm. Making sys-ops-whonix persistent for the purpose of cacher would be a task for a cacher Salt state.

The name sys-ops-whonix

To make clear what the VM's function is, the VM's name should probably start with sys- and should also include whonix.

sys-whonix-ops would perhaps be more easily confused with sys-whonix.

ops standing for operations. What operations? UpdatesProxy, UpdateVM, ClockVM.

If the name is non-ideal, suggestions are welcome.

Completion criteria checklist

The migration would involve:

[ ] Creation of the sys-ops-whonix qube with Salt. [ ] Make sure that Salt state is also called when using the Anaconda installer when installing Qubes-Whonix. [ ] Rename of mentions in Qubes source code that hard code sys-whonix for sys-ops-whonix when appropriate. [ ] Possibly other modifications that will be discovered when implementation starts.

[adrelanos]

There's a contributor available to implement this security enhancement.

However, since this would involve the creation of an additional VM that would be installed by default for users who opt-in to install Qubes-Whonix and therfore some extra system resource use, I suppose this feature might require approval by the Qubes core team before it's worth implementing this?

In other words... Currently maybe blocked by: Qubes core team approval

[adrelanos]

Ping @marmarek.