Ssh to dom0

[corporateblush]

@qubist

This is the first time I read there can be a second admin VM.

How to create an AdminVM in R4.1?

Following an older post from Joanna https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/ that I invite you to read first in order to understand what is an AdminVM, in this little post I want to give you some hints on how to create an AdminVM as you would expect it to manage/create/delete VMs as if you would do usual actions in dom0. In the template that you will use to create the VM, ensure to have installed qubes-core-admin-client. This packages installs most of the qvm-* tools. Create a…

Introducing the Qubes Admin API

Will we again discover Qubes Air?

[rustybird]

@corporateblush

Jargon-ing while we still don’t know / aren’t sure is the goal reachable through [an admin client qube ] as per @fepitre’s post…

I don’t see why not. Forward an SSH port to some-qube, install qubes-core-admin-client in it(s template), and configure dom0 policy to give some-qube the appropriate permissions. E.g. if some-qube should be able to run qvm-run other-qube echo hello world, allow it to invoke qubes.VMExec on other-qube, and maybe some other necessary services. (I’m only using qvm-run as an example because @ssh1 mentioned it in their initial post. You don’t really need the qubes-core-admin-client package for this use case: qvm-run-vm would be more appropriate, although it still calls the old qubes.VMShell service.)

[qubist]

@otter2

I am not familiar with the intricacies of qrexec. My idea was to simply watch for “calls” generated inside the “admin qube” (a domU) and execute them (or not) in dom0 accordingly based on checks. I am not aware of a policy that allows such mechanism, as per the diagram.

[rustybird]

That’s the admin API!

A qube can make the same admin API method calls to dom0 that dom0 makes to itself, using the same qvm-foo and qubes-bar tools installed through the same qubes-core-admin-client package (or alternatively, using raw qrexec-client-vm invocations), and dom0 policy decides if those requests from the qube are granted.

[qubist]

@rustybird

That’s the admin API!

OK, so I have reinvented the wheel

Now, the question is what policy is necessary to allow e.g. “execute command X in dom0 and return to me (to ‘admin qube’) the result”.

[otter2]

Seems like @qubist wants arbitrary code execution in dom0 without direct ssh connection.
I wonder if it’s possible to somehow call the equivalent of qvm-run with --localcmd "bash -i" from admin client qube back to itself in order to get a reverse shell in dom0. That could be fun.

[rustybird]

That wouldn’t work with qvm-run in an admin client qube. dom0 can’t be used as a destination (it doesn’t offer qubes.VMShell or qubes.VMExec), and --localcmd would run in the admin client qube itself.

But the admin API isn’t needed at all to set up a dom0 qrexec service for arbitrary code execution in dom0 from a specific qube running SSH (forwarded over qrexec from sys-net to that qube)… A qrexec connection (in this case, from the SSH qube to dom0) is even enough to get a passable interactive shell using the script utility, like here:

dom0/bin/qvm-shell

[qubist]

@rustybird

You won’t be executing the qvm-foo or qubes-bar command in dom0 though, but it in the admin client qube. Then the command will make (often multiple) admin API calls to dom0.

But then the “admin client qube” won’t be able to function as “dom0 managed over ssh”. AFAIK, you can’t e.g. qvm-create ... in a domU, so the “admin client qube” will simply not function as such. Or am I missing other options?

@otter2

Seems like @qubist wants arbitrary code execution in dom0 without direct ssh connection.

Not completely arbitrary. The service in dom0 that reads the command queue through polling the “admin qube” domU can check if particular commands are allowed and act accordingly.

[corporateblush]

@qubist

you can’t e.g. qvm-create ... in a domU,

I can, and it is explained already? Insisting on dom0 is the wrong premise.

[qubist]

@otter2

You can use any admin client tool (all qvm- commands) from admin client qube as long as the policy required for their function allows it. Which is really a subset of you can request any qrexec service from dom0, which includes admin API by the way

So, that is what I have been missing in my earlier post and @rustybird is probably right - my idea could work with the existing tools.

[corporateblush]

It was the very first point in the topic I quoted from @fepitre around 40 messages earlier:

@fepitre

1. In the template that you will use to create the VM, ensure to have installed qubes-core-admin-client. This packages installs most of the qvm-* tools.