Fix architecture diagram on Admin API

[woju]

The diagram https://www.qubes-os.org/attachment/wiki/AdminAPI/admin-api-architecture.svg is wrong in that policy query directly parses policy files (this is not done via qubesd), but from qubesd it only gets all vm's state dumped.

Cc: @marmarek @andrewdavidwong

[andrewdavidwong]

@rootkovska: Are you the correct assignee for this task? If not, who is?

[andrewdavidwong]

@rootkovska: Are you the correct assignee for this task? If not, who is?

[rootkovska]

I will make a new diagram as part of my upcoming new post about Core3.

[rootkovska]

I will make a new diagram as part of my upcoming new post about Core3.

[rootkovska]

I've created a new diagram :) This is mainly intended for the upcoming post on core3, but should work for this page also.
Cc: @woju @marmarek

[rootkovska]

I've created a new diagram :) This is mainly intended for the upcoming post on core3, but should work for this page also.
Cc: @woju @marmarek

[woju]

• Policy check dashed arrow ("query about VMs [...]") should end at bot qubesd.sock and qubesd.internal.sock. It calls admin.vm.CreateDisposable and admin.vm.Start from qubesd.sock. I think this is an important detail that this is not just "query" but this can initiate some non-trivial actions, irrespective of the fact that this won't happen in typical AdminAPI scenario, which doesn't have $dispvm as permitted policy destination.
• Currently qrexec services use qubesd-query-fast, not qubesd-query(.py).
• Third case is when someone is using AdminAPI-enabled tools (like qvm-* CLI) from dom0 itself). Then the tool calls /etc/qubes-rpc/admin.* scripts via subprocess module and the policy is not evaluated.

[woju]

• Policy check dashed arrow ("query about VMs [...]") should end at bot qubesd.sock and qubesd.internal.sock. It calls admin.vm.CreateDisposable and admin.vm.Start from qubesd.sock. I think this is an important detail that this is not just "query" but this can initiate some non-trivial actions, irrespective of the fact that this won't happen in typical AdminAPI scenario, which doesn't have $dispvm as permitted policy destination.
• Currently qrexec services use qubesd-query-fast, not qubesd-query(.py).
• Third case is when someone is using AdminAPI-enabled tools (like qvm-* CLI) from dom0 itself). Then the tool calls /etc/qubes-rpc/admin.* scripts via subprocess module and the policy is not evaluated.

[rootkovska]

And here comes another iteration :)

[rootkovska]

And here comes another iteration :)

[woju]

Ymmm, the third point from my previous comment is still pending. qvm-tools from dom0 run those yellow scripts (/etc/qubes-rpc/admin.vm.*), not the qubesd-query* tool. This is for those calls that have some logic in those scripts. Currently some storage calls have non-trivial scripts, for example *.volume.Import does not pipe the whole payload through qubesd like every other call, but saves it directly. (For simplicity of parser qubesd buffers whole call before handling it, so it is clamped at IIRC 64KiB, so we can't process multiple GB image).

For subconscious clarity, I'd also move the "AdminVM internal scripts..." node to the left of the yellow box, because those scripts run "in parallel" to "the other qvm-tools" from "GUI VM".

In every other respect, the graph is perfect. :)

[woju]

Ymmm, the third point from my previous comment is still pending. qvm-tools from dom0 run those yellow scripts (/etc/qubes-rpc/admin.vm.*), not the qubesd-query* tool. This is for those calls that have some logic in those scripts. Currently some storage calls have non-trivial scripts, for example *.volume.Import does not pipe the whole payload through qubesd like every other call, but saves it directly. (For simplicity of parser qubesd buffers whole call before handling it, so it is clamped at IIRC 64KiB, so we can't process multiple GB image).

For subconscious clarity, I'd also move the "AdminVM internal scripts..." node to the left of the yellow box, because those scripts run "in parallel" to "the other qvm-tools" from "GUI VM".

In every other respect, the graph is perfect. :)

[rootkovska]

There are some limits to how much details one can put on a diagram, before its value diminishes greatly (after all the whole point of a diagram is to be some kind of a simplification of the sources, or else we would just link to the sources ;).

For the diagram above I've even debated whether to depict the qubesd-query* tool, as it really changes nearly nothing for the (security) arch (unlike e.g. qrexec vs socket calling, which implies policy protection or not), but I left it since it might be useful in debugging/playing with the qubesd API manually, so wanted it to be obvious that there is a tool for this.

(Yet your comment about policy check being able to create/start VMs was an important one).

[rootkovska]

There are some limits to how much details one can put on a diagram, before its value diminishes greatly (after all the whole point of a diagram is to be some kind of a simplification of the sources, or else we would just link to the sources ;).

For the diagram above I've even debated whether to depict the qubesd-query* tool, as it really changes nearly nothing for the (security) arch (unlike e.g. qrexec vs socket calling, which implies policy protection or not), but I left it since it might be useful in debugging/playing with the qubesd API manually, so wanted it to be obvious that there is a tool for this.

(Yet your comment about policy check being able to create/start VMs was an important one).