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
Ok I have an idea; what about inverting this step here:
Enable the qubes.user-dirs top file:
dom0
sudo qubesctl top.enable qubes.user-dirs
The Salt page in the Qubes OS docs (that you may have already been reading!) provides an entry point to understanding how Salt commands and qubesctl commands are related:
Because we use some code that is not found in older versions of Salt, there is a tool called
qubesctlthat should be run instead ofsalt-call --local. It accepts all the same arguments of the vanilla tool. (permalink)
1 Like
Yes that was helpful. I see that dom0 uses a dispVM to apply Salt states so as not to directly interact with a potentially compromised VM.
I have another question, and that is, is it possible to completely disable Salt? In your docs you have this
Enable the qubes.user-dirs top file:
dom0 sudo qubesctl top.enable qubes.user-dirs
As long as the top file is enabled, applying the state will ensure that the user directories exist.
→ So if this file is note enabled, does that mean Salt is effectively disabled for dom0, and thus the rest of the QubesOS system?
No. Top files are part of Salt. Disabling a top file tells Salt that you don’t want the corresponding state to be enforced when Salt runs.
It does nothing to either enable or disable Salt itself.
I don’t think so.
1 Like
The command sudo qubesctl top.disable qubes.user-dirs returns:
local:
unchanged:
- qubes.user-dirs.top
I think Salt has the potential to be used as a supply chain attack vector, either by the OEM or by an evil maid attack. I guess If you inject a salt file into a VM, it still communicates with dom0 via a dispVM, so a single malicious salt file will not necessarily penetrate dom0; correct me if I’m wrong.