Saltstack Minion

Is it possible to check for a Saltstack Minion installation within a specific Qubes directory? What would be the name of the salt recipe?

Hi @librelifer,

I’m not sure I understand your question correctly, but you can find Salt definitions in dom0’s /srv/salt directory. Does that look like what you’re looking for?

yes it is, but if there were some untrusted salt minion state configured, where would it be and what would the filename be?

Also, how could this be linked to a running process? what would be the process name?

So far, I haven’t seen any Salt formulas stored elsewhere than dom0 in the context of Qubes OS’ use of Salt.

When state needs to be applied to a VM other that dom0, either the --targets and --skip-dom0 options are provided to qubesctl to specify that VM’s name, or a .top file is used and that file defines the targets.

That may differ from some of the patterns that are described in Saltstack’s documentation (there are different ways Salt can be set up, but you wouldn’t typically use all the ways at once). The docs about .top files do apply to Qubes OS. :slightly_smiling_face:

1 Like

I think you do not understand.

Generally, salt in Qubes uses salt-ssh, with dom0 running in masterless
mode. Salt calls using qubesctl are proxied to the qubes using a
disposable based on the management-dispvm from qubes-prefs

Salt state files are usually stored under \srv on dom0: you can name
them as you will and put them anywhere you like, (search paths configurable).

As states are (usually) in dom0, it doesn’t make sense to talk of
If you are talking of a file on a qube, that doesn’t make sense
either - who knows what the filename could be?

The salt environment is copied to the disposable, and enacted from
there. Would it be possible to place a malicious file on a qube and have
that subvert the process? Possible - I have not (yet) been able to do
Any state or call using grains could be subverted - grains come from
the minion, and should not be regarded as trusted.

If you mean something else, as always a concrete example is good, to
make sense of the (buzz) words.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
1 Like

how can a user check for salt-ssh connection? Would this be done from dom0?

The long winded way:
qubesctl --skip-dom0 --show-output --targets=QUBE

The easy way:
Since you control your system you should know this - follow this guide.
Any official template you install should work.
Any template you clone from them should work.
Any standalone you create from them should work.
Any other class of qube probably wont work unless you have actively
taken steps to make it work.

Also, of course, anything you can update from the GUI updater
(presently) demonstrates that qubesctl is working.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
1 Like

what if the target is dom0? You would omit “–skip-dom0”?

I believe so.

dom0 is always a target, by default, unless you specify --skip-dom0.

Which means that if you want dom0 to be the target, the command line is easy, but if you just want to make a change to my-silly-template you have to both: --skip-dom0 and --target=my-silly-template.

where is the output for this command is it piped to It just returns a boolean ‘true’ value at the moment.

A management VM is created and started for each of the targets. That machine is named using the pattern mgmt-A where A is the target name.

The corresponding logs can be found in dom0’s /var/log/qubes directory.

For example, say the target was fedora-32, then qubesctl will log into /var/log/qubes/mgmt-fedora-32.log.

For what is worth, if you’re looking for an example of going through the process of writing Salt states for Qubes OS, the following page contains notes I’ve taken when setting up Split-SSH for mysef. The example log file I gave above comes from there.

Corresponding forum thread: Packaging Salt states / formulas for use in Qubes OS


so the command would be qubesctl --show-output

There are two directories returned by the command:

qubesctl --show-output --targets=dom0



Are these directories not relevant?

I don’t fully understand your explanation I’m sorry. My objective is to check and see if ANY networked Qube has a minion installed, including dom0. I’m confused as to what the value would be for --targets=QUBE
and what the value “” refers to

In fact, here is the exact output to qubesctl --show-output --targets=dom0

[WARNING] Failed to open log file, do you have permission to write to /var/log/salt/minion?
[CRITICAL] Specified ext_pillar interface qvm_prefs is unavailable
Cannot write to process directory. Do you have permissions to write to /var/cache/salt/minion/proc/20230512030511841601 ?

My whole objective here is to check if there could have been an unauthorized salt minion created for one of the Qubes(including dom0) by way of injecting one as a file maliciously. It strikes me that this would be a pretty good attack vector which creates an SSH connection.

You could also potentially perform a supply chain attack this way, by loading a malicious minion file somewhere prior to giving the hardware to a target. I’m a bit surprised that Saltstack is not discussed in the documentation as a possible vector because it is such a capable IT automation system.

So the idea is to check for SSH network connections from any and all qubes. If that can be done using qubesctl I could use that but I’m unfamiliar with the function and how to use it to do this.

I think I understand better what you’re trying to do @librelifer.

My two cents is that if you want to test the way Salt is set up in Qubes OS, then becoming familiar with the tools that are used for that is a good investment.

The qubesctl command is very central to the use of Salt in Qubes OS, and understanding how it relates to Salt’s own salt command, and how they differ is likely a good way to get started.

1 Like