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

qwhnx · June 6, 2024, 5:06am

Why is the Qubes UpdateVM when using torified updates sys-whonix and not say, a disposable Whonix Workstation based qube?

This seems like a major design flaw, and goes against everything Whonix tries to do. What was the rationality for implementing it this way?

Patrick · June 6, 2024, 1:33pm

I like none of

A) UpdateVM and
B) UpdatesProxy (tinyproxy)

on Whonix-Gateway.

Yeah. Would be better if that was in a separate VM. Perhaps that VM then could also function as a ClockVM. (Qubes-Whonix-Gateway as ClockVM)

It’s TODO. Contributions welcome.

Related (not exact) ticket:

github.com/QubesOS/qubes-issues

remove tinyproxy from Whonix-Gateway (`sys-whonix`) and make Whonix Templates networked by default with Net qube set to `sys-whonix`

opened 09:22AM - 05 Sep 22 UTC

adrelanos

T: enhancement C: Whonix P: default C: networking

I am suggesting to remove tinyproxy from Whonix-Gateway (`sys-whonix`) and make …Whonix Templates networked by default with Net qube set to `sys-whonix`. motivation for this change suggestion: * The current implementation is still basically mostly as implemented by nrgaway many years ago. nrgaway is no longer active. No co-maintenance / help / resources / hyper-vigilant auditing eyes available to keep maintaining it. * I don't like the extra complexity of having Qubes UpdatesProxy specific firewall rules in Whonix-Gateway firewall. ([here](https://github.com/Whonix/whonix-firewall/blob/master/usr/bin/whonix-gateway-firewall#L332-L373)) * It makes leak testing more complicated. * Requires complex torified UpdatesProxy check. * Primarily goal of Whonix is to route all traffic over Tor, leakproofness. Therefore any complexity / exceptions in its networking configuration is to be avoided. * Now a more complex solution is suggested on top of the current complexity. (https://github.com/tlaurion/shaker/pull/1) advantages of this change would be: * Better leakproofness. * Simplifies Whonix-Gateway firewall. * [Improves Qubes-Whonix Templates stream isolation.](https://forums.whonix.org/t/improve-apt-get-stream-isolation-for-qubes-templates/3315) * Makes Qubes-Whonix more similar to Non-Qubes-Whonix and hence easier to audit and maintain. disadvantages if this change is implemented: * Qubes-Whonix Templates being networked by default. Why do I as maintainer of Qubes-Whonix make this ticket? * I am not sure I'd have the authority to decide to make this change. Making a Qubes Template networked by default might be perceived as quite a conceptual level change. And orchestrating this change should be discussed beforehand for sure anyhow. Other alternatives? * Getting tinyproxy out of sys-whonix somehow... But how would that be implemented? Maybe a third VM but the effort to maintain that would be too high on my side. Perhaps Qubes would like to maintain a standalone tinyproxy / UpdatesProxy / cacher VM?

Patrick · June 8, 2024, 10:26pm

Ticket created:

github.com/QubesOS/qubes-issues

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

opened 10:25PM - 08 Jun 24 UTC

adrelanos

T: enhancement P: default

### 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](https://nvd.nist.gov/vuln/detail/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](https://www.whonix.org/wiki/Dev/Gateway#Whonix-Gateway). ### 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.

qwhnx · June 9, 2024, 3:40am

First thought, it will probably be difficult to have another always running Whonix VM that is not a sys-whonix NetVM by default simply because there may be friction having that approved.

What about a whonix-mgmt-dvm? See “Resolution” here, though it would have to be repurposed:

This however would fail to work for services needing it always running. Very good proposal however, I’m glad you considered it.

Patrick · June 9, 2024, 12:58pm

The naming will ultimately be up to Qubes and can be discussed in the ticket. Some thoughts on that:

Probably not because that implies Qubes management (Admin API) (Salt) and that is not done in that VM.

Also probably not because DVM is used for Disposable Template. Not for Disposables.

sys-net, sys-firewall, sys-usb can be Disposables. sys-ops-whonix could also be a Disposable (until someone repurposes it do so something which works better with persistence, for example cacher).

These VMs also do not have -dvm in their name.

I don’t think sys-ops-whonix will require a dedicated Disposable Template (DVM).

I don’t think Qubes would want to repurpose the terminology / overload for other tasks.

Right. Requires approval by Qubes. Let’s see.