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

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?

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:

Ticket created:

1 Like

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.

1 Like

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.