Qubesctl security


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

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”] :

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

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 ?


1 Like

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.

1 Like