Design and create salt formulas distribution method

[marmarek]

Since we've completed VM configuration stack, we need some method for distributing salt formulas. Currently the base formulas (default VMs, Whonix etc) are installed as rpm packages. But this doesn't scale well, especially for community-developed formulas (because rpm package can do a lot more than putting a simple text file in /srv/salt, so one should install packages in dom0 only from ultimately trusted places).

Standard approach for Saltstack is using git or Salt Package Manager. We may use something based on either of them, but need to add a "qrexec proxy", which will verify signatures (similar to qubes-dom0-update) (it isn't clear to me whether SPM support signatures at all...). Or we may design/use something different.

Then, we'd need some UI to import/select trusted keys. The whole point here is to support 3rd-party formulas, not only those provided by ITL. While Salt formula can do whatever it like to the system (same as rpm package), it is much easier to audit, because it is just a text file, usually very short.

A single formula may consists of multiple files. Example formula for installing Martus, based on https://github.com/QubesOS/qubes-issues/issues/1836#issuecomment-213575740: https://gist.github.com/marmarek/29f9a4a1f3a7a457cf2b449ab0b0e2f4 (place those files in /srv/salt/martus, then execute qubesctl top.enable martus && qubesctl --all state.highstate - only in Qubes 3.2)

cc @mfc @bnvk @andrewdavidwong

[andrewdavidwong]

@unman has just shared some great work on this in the forum:

https://forum.qubes-os.org/t/simple-set-up-of-new-qubes-and-software/13064/

[tlaurion]

@ninavizz @DemiMarie @fepitre yesssss!

https://qubes.3isec.org/tasks.html

Deploy apt-cacher (caching proxy; download once, install in all templates clones) as a package: https://github.com/unman/shaker/blob/main/cacher.spec Fixes issue: #1957

Deploy split-gpg as a package: https://github.com/unman/shaker/blob/main/gpg.spec

Deploy mullvap VPN as a package(@unman: spec file missing)

The use case installer/persona installer exists in its basic form: https://github.com/unman/qubes-task and also exists as a package: https://qubes.3isec.org/3isec-qubes-task-manager-0.1-1.x86_64.rpm

Current repo packages: https://qubes.3isec.org/rpm/r4.1/current/dom0/fc32/

[ben-grande]

@SvenSemmler said

So what we need is a process. Something like:

• a central repository
• very limited number people with commit rights
• some form of review process

A central repository for contributed packages with the criteria you mentioned above already exist, QubesOS-Contrib, but hardly new packages are added, only small ones, only having 11 repositories in total, the others are skeleton, status, logs, issues etc.

Unman has made available his formulas for ~2 years and a lot of people have used them, but it has not been thoroughly reviewed by the Qubes Team, possibly due to time constraint. It is not the difficulty to copy files to dom0 that is stopping the users to do that, either by copying the whole repository, an rpm or adding key key and repo configuration to dom0. If the user wants, he will have it, there is not stopping that.

In theory, it would be nice to have a trusted repository, in reality, it is very limiting of the packages that are included. In theory, the review process would be nice, but in reality, there was no deep review of the external formulas most used by qubes users, Shaker and it was also never added to Qubes repos.

I don't believe this issue is solely of Salt Formulas in Qubes, but of all kinds of package contribution, although said that reading YAML is easier, the issue I see is missing reviewers, but it can't be any reviewer, because it wouldn't increase Qubes OS Team trust if any reviewer did it, it has to be reviewers apointed by the Qubes OS Team, a trust that should be on the same height of contributed packages, not the main repo.

So in the bigger picture, it is a policy issue, Qubes doesn't want to include unreviewed formulas and as they don't have the bandwidth to review, they don't include any formula. Although this is not a blocker for the design of the tool/method to be implemented, it can influence on how the formulas will be provided, via Dom0 extra repo or by copying file from DomU (which is currently the case).

[marmarek]

So in the bigger picture, it is a policy issue, Qubes doesn't want to include unreviewed formulas and as they don't have the bandwidth to review, they don't include any formula. Although this is not a blocker for the design of the tool/method to be implemented, it can influence on how the formulas will be provided, via Dom0 extra repo or by copying file from DomU (which is currently the case).

Yes, this is significant part of the issue indeed. There may be a technical solution for some cases (like, enforcing what qube can be targeted with 3rd-party formulas), but that wouldn't work for others (like modifying some config in dom0).

In practice, I guess formulas that can operate only on specific qubes (created by the very same formula?) would cover a lot of cases already (for example #8774), and would be much safer than allowing arbitrary formula. But also more complex to implement... One could create an Mgmt VM with appropriate permissions to admin. services (and a few qubes. services, like qubes.VMRootShell) and deploy salt from there. May be an overkill (exchange one tricky problem to another tricky problem), but in theory would be more scalable.

[ben-grande]

Yes, this is significant part of the issue indeed. There may be a technical solution for some cases (like, enforcing what qube can be targeted with 3rd-party formulas), but that wouldn't work for others (like modifying some config in dom0).

One thing AdminVM qubes needs to place in Dom0 is the Qrexec policy, but currently, it can't restrict which qubes can be in the source, destination and target, considering that the policy is in include/*, so the service is already fixed. This, I would say, would be a requirement that policy.Replace is extended to do this check

In practice, I guess formulas that can operate only on specific qubes (created by the very same formula?) would cover a lot of cases already (for example #8774), and would be much safer than allowing arbitrary formula. But also more complex to implement...

In this scenario, the user would install a policy packaged for dom0 and the salt formula of the aforementioned policy in the AdminVM? Should the policy for allowing the formula be introduced by the formula itself? Because else the AdminVM willl have too broad permissions.

The qubes-builder for example has to use admin.vm.volume.Resize, which should not be made available for every AdminVM, so a custom policy for it has to be made. I am not considering the services that will be provided by the builder formula, such as admin.vm.Kill.

One could create an Mgmt VM with appropriate permissions to admin. services (and a few qubes. services, like qubes.VMRootShell) and deploy salt from there. May be an overkill (exchange one tricky problem to another tricky problem), but in theory would be more scalable.

One thing I learned with Qubes is that there is no overkill. You may trust one formula made by someone more than others, having them with the same permissions in Dom0 does not seem great.

This seems more scalable, yes, it limits the damage that the formula can do by limiting the Qrexec call much better than no restriction (in Dom0). The AdminVM reduces some burden of the problem but not completely. The formula has to still has to be placed in the AdminVM and validated, at least signature verification.

[marmarek]

One thing AdminVM qubes needs to place in Dom0 is the Qrexec policy, but currently, it can't restrict which qubes can be in the source, destination and target, considering that the policy is in include/*, so the service is already fixed. This, I would say, would be a requirement that policy.Replace is extended to do this check

This touches broader topic of multi-VM applications, something we discussed with SecureDrop and DangerZone teams. I have some half-backed ideas for this issue, like narrower scope includes that apply only to some subset of source/target (effectively, add "and" condition to every rule included from such file). Syntax-wise, it would be include action, instead of !include keyword. But TBH, I'm not sure if this is the way to go, the limits of the current policy format are showing and patching things on top might not be the best idea.

[gonzalo-bulnes]

This touches broader topic of multi-VM applications, something we discussed [...]

For community discussion on this topic, see https://forum.qubes-os.org/t/whats-the-future-of-multi-vm-applications-securedrop-workstation-inspired/18649