Creating qubes from domU. Management qube?

General Discussion
1

Hi,

i am working on a thing.

Specific problem now, long story short: I want to automatically create onion vanity addresses. For this i have a separate qube, that i don’t want to have.

To solve this without the extra qube on standby i would love to create it on demand from a domU.
Also for other projects of mine[1] that feature would be very awesome. Something like a management qube that starts the stuff i want done in other qubes. What i want is an management qube.

The management domU:
No network obviously. My shell, my everything i want it to have (compared to dom0). Should manage my qubes, Autostarts the stuff i want autostarted in the way i want it autostarted. (that way my config stuff could be in one place for ease of use. At least i hope). Usability features like being able to copy stuff into it from the clipboard.

Capabilities the management VM should have:

  • Create new qubes
  • Modify qubes preferences (CPU cores, network-vm, …)
  • Start qubes
  • Run (predefined) programs in the qubes via qrexec
  • (Maybe even mount block devices into qubes to specific places, not sure about that tho)

Why not control stuff from dom0?
Usability. I need to give arguments to the stuff i am calling. Long arguments like 50 character passwords in extreme cases that i will not type into dom0.

Security: Don’t put more software that could explode into dom0.

Availability: I know i will fuck up at one time tinkering. I don’t want to fuck up in dom0 if possible.

So far i think the worst that could happen would be a DOS of the system (if implemented securely, so the “management” qube cannot gain RCE in dom0).

What do you think? How bad of an idea is that?

[1]: Other stuff i want to do from my management qube:

  1. archiveBox qube: Issue a command to archive a website
  2. download qube: Issue a command to download something of the internet and safe it in an storage qube
  3. server management: ssh into all my machines and do “stuff”
  4. On demand services: like “Give me a dispVM with a running drawio docker running and sync all i did afterwards with my storage”

All of the above in dispVMs that

2

Just a note about terminology: In the context of Qubes OS, the term admin qube already has a specific meaning, which is different from the one you’ve assigned to it here. This is likely to cause confusion and make it more difficult for people to help you, so I suggest sticking with our established terminology.

3

You are right, i have corrected my post. Thanks!

I have read a bit about “stuff” and i am starting development. It seems like this is the way qubes wants to go anyways and there is an API to support this.

I am not sure if i should switch to 4.1 now and develop it there, or wait for the final and adapt what i will have done by then.

4

Your “correction” is no better - management qube also has a specific
meaning in Qubes.

Just to be clear - there has been remote management in Qubes for over 5
years, and capabilities for remote access for longer.
Everything that you mention below can be done within the existing
framework.
(I’m not saying it isnt clunky at times, but it works.)
You might also like to look at the remote-support package which you
could leverage.

I haven’t looked at the “thing” you’re working on, but it seems to be
relatively easily attainable, if this is the outline.
The “other stuff” looks like straight forward scripting.

I don’t think it’s a bad idea, and could be fun to implement.

5

Thanks for the clarification.

mgmt qubes do for example updates, the adminvm at this stage is dom0. Ok so i think i go with the name “cockpit”.

The goals i have should be possible to script with qrexec. At the moment i am thinking of a way to do this very securely without using too much resources.