If you want to be able to use sudo inside a minimal template […], then install the qubes-core-agent-passwordless-root package.
Further, the same document says:
default-mgmt-dvm: requiresqubes-core-agent-passwordless-root and […]
So, on one hand it is optional, but then it is suddenly required. Hence question 3 from above.
XY problem: I am working on a Debian template (starting from minimal) which I would like to use for all my VMs and for now I don not want to enable passwordless root in VMs, so I would prefer not to install things I won’t use.
(Yes, I am aware of all the arguments for and against it. We have discussed it in another thread)
To fix this problem, we are implementing two changes:
1. Adding the "management_dispvm" VM property, which specifies the DVM
Template that should be used for management, such as Salt
configuration. TemplateBasedVMs inherit this property from their
parent TemplateVMs. If the value is not set explicitly, the default
is taken from the global "management_dispvm" property. The
VM-specific property is set with the qvm-prefs command, while the
global property is set with the qubes-prefs command.
2. Creating the "default-mgmt-dvm" DVM Template, which is hidden from
the menu (to avoid accidental use), has networking disabled, and has
a black label (the same as TemplateVMs). This VM is set as the global
"management_dispvm".
I have read this before opening the thread. It is not quite clear to me what “management” means (except Salt configuration), i.e. what else does management include?
As I understand it - it’s just a DVM that is used to run different internal Qubes OS tasks outside of dom0. default_dispvm is for user to configure and use and it may not satisfy the requirements to be used for running management tasks so they created separate management_dispvm for this that is not supposed to be used by user.
The fastest way to know where it is used is to search for management_dispvm and default-mgmt-dvm strings in the whole Qubes OS github repo.
I think this one is unrelated to the topic and it’s better to create a new topic with a subject like “How to securely use in dom0 the result of a command executed in a qube”.
For what is worth, that’s my understanding as well.
I suspect that it is hidden from the menu via the internal flag, which is a clear cue to not use it, but haven’t checked so I may be wrong. That wouldn’t change my understanding either way.
I didn’t look into it.
The answers to your questions from my understanding:
It’s just a DVM that is used to run different internal Qubes OS tasks outside of dom0
User is not supposed to use it since it’s intended to be used for internal Qubes OS tasks only.
It’s not supported.
Maybe there are some possible workarounds or hacks to do this but developers are not interested in supporting them because it could take too much time for uncertain gains and it’s better to use this time on issues with more priority.
The problem is that since I don’t know what are the actual functions of that DVM, I don’t know how to test/compare how all of them work with/without passwordless root. So, it is all related.
AFAIK these particular VMs only run installation/configuration scripts, which is impossible without root. And you have to trust such (signed) scripts anyway, don’t you?
AFAIK these particular VMs only run installation/configuration scripts, which is impossible without root.
It is still not clear if it is only install/config. Yes, for the activity you mention root is required. However, that doesn’t necessarily mean that in-every-VM unrestricted root is required. Since I don’t know how exactly this works through the help of this special management DVM, it is difficult to have certainty about either. In any case, there is the contradiction between the possibility of (freedom to choose) something and the requirement for the opposite.
And you have to trust such (signed) anyway, don’t you?
You’ve been told what the functions are - the most obvious one being in
passing salt states to qubes for action, and passing results back to
dom0.
If you are concerned about this, create a disposable template without
passwordless root, and use it as base for the mgmt disposable. See what
happens.
If you do not want to use passwordless root there is a documented method
for using a dom0 prompt before applying sudo. Use that if you will.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
You’ve been told what the functions are - the most obvious one being in
passing salt states to qubes for action, and passing results back to
dom0.
Which are the others (the not so obvious ones)? That is what I am trying to understand.
To put it differently: What will break if one damages/deletes that special VM? How to re-create it from scratch? Is it possible to use Qubes OS without it and what will be the effects of that?
If you are concerned about this, create a disposable template without
passwordless root, and use it as base for the mgmt disposable. See what
happens.
Unfortunately, I don’t have a spare (non-production) system for tests involving modification of essential OS parts. So, before trying (and potentially breaking) anything, I prefer to understand how it works, what might the possible effects of modifying it be, and how to recover from unfortunate results, then decide how to proceed - based on knowledge, not based on trial and error. Since the documentation says nothing about it, I am asking in the forum.
If you do not want to use passwordless root there is a documented method
for using a dom0 prompt before applying sudo. Use that if you will.
I am aware of that method. My question is about whether passwordless root (installing the package for it) is required for the mgmt disposable or not, as the documentation is self-contradictory about that particular aspect.
I do not believe there’s special things in that qube’s private volume. You just need to create a disposable qube named “default-mgmt-dvm” based on a “full” template ( fedora-38 instead of fedora-38-minimal ) and that’s all.
I personally think you have reached somewhere that hardly anyone has explored before. So there might not be immediate and comprehensive answer to your question.
