Qubesctl security

dal · July 17, 2022, 7:07pm

Hi,

It seems that when the decision of using Salt has been took, there were
concerns about exposing dom0 via its output.

github.com/QubesOS/qubes-issues

Salt Managment Inter VM Communication

opened 04:44PM - 25 Dec 15 UTC

closed 02:09AM - 01 May 16 UTC

nrgaway

T: enhancement P: major release notes C: mgmt

On 25 December 2015 at 07:40, Marek Marczykowski-Górecki marmarek@invisiblething…slab.com wrote: ``` -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Dec 25, 2015 at 03:58:47AM -0800, Jason M wrote: > BTW, going to play around with bombshell next week :) That would be probably the easiest thing to do, but not sure if the most secure. ``` I totally agree. I was thinking of bombshell for vm to vm communication where there could be a SaltVM for user formulas where the SaltVM would have no network access or communication to dom0. That still may be risky though, but I wanted to at least experiment with a couple of different ideas to at least eliminate some of them. ``` I think the way to go, would be to package states/formulas/etc from dom0, send them to the VM using _simple_ mechanism (qvm-copy-to-vm?), then execute states there. And the most important part: do not parse anything coming from that VM back. This means for example do not render the output. Maybe only exit code ("success"/"failure") and point the user where to look for the logs. ``` I totally agree. What about dom0 sending configurations to a SaltVM master, which could communicate with TemplateVM's? Or would you rather not introducing a SaltVM in case it gets infected. ``` As for the state execution, I see state.pkg: https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.state.html#salt.modules.state.pkg But I can't find an easy way to create such package (other than digging deep into salt-ssh...). Any ideas? ``` I have not considered salt.modules.state.pkg, but will look into it as well. I was thinking of using either a modified salt-ssh or creating a simple client on the TemplateVM. The salt-master can reside in dom0 that will create specific states based on pillar configuration and tops, etc. Based on your comment, I will look into the best way of creating the required data and sending it to TemplateVM without any parsing. So, the salt-master will create some type of state package, upload it only, the templateVM will unpack and execute it and can notify Salt Master when completed with a result code. Another thing we can consider is using git to receive formulas from web which the TemplateVM can download and install which means we don't need to package it for each distribution. The formulas can be downloaded as a git repo or salt package (one file). Both methods have no existing security other than checksums, but we could verify git repos in a similar fashion to what qubes-builder does, but adding requirement and verification on each commit as well as tag and possibly a checksum on each file and overall? I have copied this reply to qubes-issues to allow further discussions.

Nowadays I seen the hint to start the command as usual and to check the
logs if something goes wrong.

1 Does this means that QubesOS filter that output ?

2 How can we can trust it to do it well ?

3 Assuming we can trust it well, do you have more objections to simply
use the --show-output flag instead of navigating log files ?

It is cited in the best practices to not use grains in pillar files,
especially for sensitive data, with the exception of grains[“id”] :
https://docs.saltproject.io/en/latest/faq.html#faq-grain-security

The only grain which can be safely used is grains[‘id’] which contains
the Minion ID.

When possible, you should target sensitive operations and data using
the Minion ID.
If the Minion ID of a system changes, the Salt Minion’s
public key must be re-accepted by an administrator on the Salt Master,
making it less vulnerable to impersonation attacks.

Knowing that QubesOS does not use a Salt Master, but only minions with
salt-ssh,

1 How qualitatively the exception of grains[‘id’] stand in this
context ?

2 My understanding is that salt-ssh will copy the files required to the
disp-mgmt-vm, at this point does the jinja2 references for grains[‘id’]
yet expanded ? Or the disp-mgmt-vm holds the whole template, maybe
containing sensitive data not strictly necessary for the VM, that will
be expanded here ?

Ty

marmarek · July 18, 2022, 2:12pm

Yes. But more importantly, it doesn’t try to parse it. The primary concern with standard salt is it tries to parse output of salt minion (from target VM/system) and then act on it (for example, it fetches all the grains, and then prepares on the server side final states to run). In master-minon setup, this process is highly interactive; with salt-ssh is less so, but still requires some processing on the server part. In Qubes, this processing is isolated in DispVM.

No salt part in dom0 receives any output from VM, so there is nothing to attack.

That’s something we have considered, but the output is a bit too cluttered to be enabled by default. If you use GUI updater (which also uses salt), you can see it in “details” section. It might be a good idea to add an option like --show-output-on-error so by default it will be hidden, but if it fails, it will show the output directly.

The DispVM will get all the states and formulas (and choose and render the right one itself). But for pillars, filtering is done in dom0, and the DispVM gets only pillars targeting specific VM. Dom0 doesn’t fetch grains from target VM at all, so the above rule of using only grains['id'] for targeting is enforced by simply not having other pillars from the VM at all.