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
Ok I have an idea; what about inverting this step here:
Enable the qubes.user-dirs top file:
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
qubesctl
that should be run instead ofsalt-call --local
. It accepts all the same arguments of the vanilla tool. (permalink)
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:
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.
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.
Thatās how Salt works. You define a state you want to see enforced. Then you ask Salt to enforce it. If changes are necessary, Salt applies those changes to put the system in the state you defined. If no changes are necessary, it reports that no changes were necessary.
In this case, the user directories are already disabled, so no changes were necessary. The system was already in the state you desired.
Hint: you can use backticks around code and console output to make it more readable in the forum.
If that was the case, the Qubes OS team would have made a huge mistake setting up Salt, donāt you think? I donāt think thatās the case, but Iād recommend reading the documentation to understand why. Iām not the right person to explain Qubes OS setup of Salt in detail. I use it, and understand enough to feel safe doing so, but explaining the implementation details is something I donāt feel qualified to do.
I didnāt understand this, but my answer above applies
This is just noise, based on (deliberate?) ignorance.
I donāt know where to start.
You need to understand what are minions, top files and states. This is
basic background knowledge which you failed to acquire before launching
on this thread. @gonzalo-bulnes has tried to point you in the right
direction.
Letās take this most recent comment - as so often, I recognise the
words, but not your meaning.
I think what you are saying (now) is that if someone were able to drop
a salt state file on to a qube, then this could be an attack vector.
But this is almost nonsense. If an attacker ( OEM or an evil maid)
had access to the system, why would they do that? Why not
just drop new binaries on dom0? What would use of Salt do?
Could you āinject a salt file into a VMā? What sort of file? What sort
of VM? How would it be triggered? What would be the intention?
You must do some basic research in to a subject before filling the forum
with these threads - they are no help to other users, and (I suspect) no
help to you.
Do some research.
Ask informed questions.
Give enough detail so that others can understand your intentions and
questions.
In the present case, on the face of the words you have used, you are
right: āa single malicious salt file will not necessarily penetrate
dom0ā.
But I suspect that was not what interested you here.
And the new binaries would do what? Create a network connection to exfiltrate data? or call out to a command and control server?
How would I know? Itās your scenario.
What did you imagine your mysterious salt state would do?
If there was a benign Salt minion in your VMs, youād find its configuration in /etc/salt/minion and its logs under /var/log/salt. It would run as process named salt-minion
. This program is not installed to be running on a qube by default, since Qubes Salt does not use the minion at all (Qubes Salt is a different beast, and it uses qrexec-based āsshā to set up VMs).
I am qualified to explain this, since I have used Salt in a professional capacity for over ten years, same goes for my usage of Qubes OS as well, and I even wrote some Regular Salt-based software for Qubes (which also doesnāt use the minion). Check my Github for receipts.
Of course, a malicious Salt minion would (1) not use those files at all (2) not appear on a process list, since the whole point of a malicious process is to hide its execution. Whatās more ā an attacker would not use Salt as an attack vector at all, because there exist much more sophisticated software, which far greater self-hiding capabilities, to perform attacks and exfiltration against a machine. If an attacker wanted to compromise you, it would be the dumbest thing for the attacker to (1) compromise your VM template to permanently enable Salt minion and configure it to connect to his Salt server (2) compromise your networking so that the minion can connect to his Salt server (3) rewrite the software to hide its obvious execution indicia. There are more efficient ways to compromise you than this.
All of this I wrote as a preamble to say, if you are honestly concerned about a compromise through a Salt minionā¦
ā¦lol.
What would be a better attack tool? A rootkit?