Move `/srv/user_salt/` to `~/.local/salt/`

[zaz]

Qubes OS release

4.2.0

Brief summary

In the interest of making SALT more accessible to end users (#8218), I propose allowing easy backup and restore of SALT states.

The Qubes backup tool backs up the dom0 home directory. A lot of the use of SALT for the end user comes from allowing them to smoothly migrate privileged modifications to a fresh install. So we should move /srv/user_salt/ to ~/.local/salt/ so that a user's SALT states are backed up.

Of course, we still allow custom usernames in dom0, so we would have to detect the username when qubes.user-dirs is activated, but that should be straightforward: just use the name of UID 1000: id -nu 1000

Steps to reproduce

Run

qubesctl state.sls qubes.user-dirs

Expected behavior

~/.local/salt/ is created.

Actual behavior

/srv/user_salt/ is created.

[ben-grande]

You can specify more directories with a file in /etc/salt/minion.d/SOMETHING.conf

---
file_roots:
  base:
    - PATH

There are some important files and directories that may be important to some users and not to others:

/etc/qubes/rpc-config/
/etc/qubes/policy.d/
/etc/qubes/backup/
/srv/user_salt/
/srv/user_pillar/
/srv/user_formulas/
...

But they have these paths for a reason, they follow a directory hierarchy, are root owned and some are owned by the qubes group, all of them have fixed paths to these exact directories. Why should some be backed up an others not? This is a personal preference, for you, it is user_salt, for others, might be anything else, Xorg configuration for example.

I have a script to backup dom0 files important to me, it is very simple, a much simpler solution than deal with file permissions in the user home directory for a process run as root.

[zaz]

I believe we should do the same, wherever feasible, for any directories that are specifically for user configuration.

Files that could be updated by the system or the user are up to personal preference. But /srv/user_salt/ is specifically designed to only be modified by the user after creation, so it doesn't make sense not to back it up and restore it by default.

Alternatively, we could add a section to the default backup script that works similarly to your script, but it is important that the backup should not lose important data by default. An even more robust option would be to backup all files that have been modified by the user, but I'm not sure we have a way to tell if a file has been modified by the user on Fedora.

We could use a symlink to link /srv/user_salt/ → ~/.local/salt/ if the /srv/user_salt/ path is important. As for permissions, we could either:

1. Keep the same permissions, and have some files with root permissions in the home directory. This is unusual, but I don't believe it causes issues; or
2. Use user permissions. Each Qube is intended to be a single-user system with passwordless root, so this should not harm security in any way.

[quantumpacket]

I write my salt config in a vault qube named salt-dev. I do this for a few reasons, one I don't believe development work such as writing salt states should be done directly in dom0. Secondly, dom0 doesn't come with a default GUI-based text-editor. I have a sync script I run in dom0 to sync up the contents of my state files in salt-dev with that in dom0 using qvm-run --pass-io .... Lastly, when I backup my salt-dev vault qube I backup my salt states.

I'd suggest rather instead of creating and configuring a new directory in dom0 we encourage people to do their development in a vault qube and sync it with /svr/user_*. This perhaps would be as simple as creating a salt-dev vault qube and running the sync command when qubesctl state.sls qubes.user-dirs is ran.

What are your thoughts on this approach?

[zaz]

@quantumpacket It's not clear to we how developing the SALT scripts in a separate VM enhances security.

If the GUI-based Qube is compromised, then your SALT states will be compromised and then copied over to dom0 and run, compromising dom0. Even if you limited the SALT states to only be ones that can affect non-dom0 VMs, it would still result in all your VMs being compromised.

[quantumpacket]

If a vault qube is being so easily compromised then there are much bigger issues at hand. It's more about discouraging using dom0 for development work, and keeping dom0 minimal-use as it was intended according to the docs:

"That’s why everything in Qubes OS is specifically designed to protect dom0 and ensure that doesn’t happen. Due to its overarching importance, dom0 has no network connectivity and is used only for running the desktop environment and window manager. Dom0 should never be used for anything else. In particular, you should never run user applications in dom0. (That’s what your app qubes are for!)"

I understand what you are saying about if the qube is compromised it will have a cascade effect, but that's why it's using a vault qube, which is a highly trusted qube. Using dom0 would encourage people to install additional packages to it for convenience sake for development and actively use it for development purposes, and that would be more dangerous than using a trusted vault qube in my opinion.

[zaz]

Thanks for getting back to me so quickly. You're right about almost all of that, but I am confused about this:

that would be more dangerous in my opinion.

Why would this be the case? Am I wrong in thinking that if the vault qube is compromised, then that would result in dom0 being compromised? If the vault qube has the capability to indirectly run code in dom0, you may as well have just installed all that editor software directly in dom0.

The only argument I can see against this is if the attack is not targeting Qubes. Is that your logic? If not, what prevents the vault qube from infecting dom0 with malicious SALT states?

[quantumpacket]

Why would this be the case? Am I wrong in thinking that if the vault qube is compromised, then that would result in dom0 being compromised?

You are correct about that, but we have to look at the likelihood of a vault qube getting compromised. What actions would one have to take to inadvertently compromise a vault qube? We would be using it solely for the purpose of development of state files. One would have to go out of their way to introduce malicious code to their salt-dev vault qube. Also, if you can't trust the template the vault qube is based on then all of your other qubes based on it would be compromised too.

If the vault qube has the capability to indirectly run code in dom0, you may as well have just installed all that editor software directly in dom0.

True, but this is more about making sure we are not encouraging the behavior of using dom0 for purposes it's not intended for such as development work. A lot of using QubesOS is a change in behavior in how we normally do things. I'm under the impression that dom0 should be minimal-use and development work should be done in its own qube, in this case a vault-based one.

Maybe @marmarek can provide a better insight into what would be best practice? I'm happy to support whatever is recommended.

[unman]

[quote] If the vault qube has the capability to indirectly run code in dom0, you may as well have just installed all that editor software directly in dom0. [/quote] I dont follow. As I understand this the vault qube is used to produce text files, which are then transferred to dom0. In no way is the vault qube able to run code in dom0. The user runs the state files, and bears the responsibility for checking them before doing so. The same goes for any qube or global configuration, or service policy.