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 @huaopeng,
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. 
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
āuntrustedā.
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
it.
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.
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 test.ping
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.
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 test.ping? 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
2 Likes
so the command would be qubesctl --show-output test.ping
There are two directories returned by the command:
qubesctl --show-output --targets=dom0 test.ping
/var/log/salt/minion
/var/cache/salt/minion/proc/
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 ātest.pingā refers to
In fact, here is the exact output to qubesctl --show-output --targets=dom0 test.ping
[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 ?
local:
True
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 @huaopeng.
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