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 #1836 (comment):
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]

Would it be possible to adapt Split-GPG for signature verification?

[andrewdavidwong]

Would it be possible to adapt Split-GPG for signature verification?

[marmarek]

I don't think it would be good idea - in the end we need dom0 to verify the signature, otherwise some VM may in practice gain control over dom0 (if you compromise formulas verification path, you can configure dom0 to do anything). Also Splig-GPG is mostly useful for using privatekeys, not just verification.

[marmarek]

I don't think it would be good idea - in the end we need dom0 to verify the signature, otherwise some VM may in practice gain control over dom0 (if you compromise formulas verification path, you can configure dom0 to do anything). Also Splig-GPG is mostly useful for using privatekeys, not just verification.

[andrewdavidwong]

So, basically, it's the same problem as the one faced in designing the backup-restore model, right? We have some input which has to be verified in dom0, but we don't want anything in dom0 to parse potentially malicious input before it gets verified. Would it make sense to approach this in the same way?

[andrewdavidwong]

So, basically, it's the same problem as the one faced in designing the backup-restore model, right? We have some input which has to be verified in dom0, but we don't want anything in dom0 to parse potentially malicious input before it gets verified. Would it make sense to approach this in the same way?

[marmarek]

In case of backup it is additionally encrypted. Here we want only signature (not simple HMAC).

[marmarek]

In case of backup it is additionally encrypted. Here we want only signature (not simple HMAC).

[bnvk]

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.

I'd been assuming we'd a UI for the browsing / installing / removing of salt formulas from a users machine, thus this would involve more than just the key management, and by keys I assume PGP keys correct @marmarek ? In both cases, I was thinking making this engaging and welcoming with icons and names.

Since the .sls files appear to just be YML format, are they flexible enough to just add values to the existing fields like:

martus:
  recipe:
    - title: Martus
    - description: Martus is a free, open source, secure information collection and management tool that empowers rights activists to be stronger in their fight against injustice and abuse.
    - icon: path/to/logo.png
  qvm.vm:
    - present:
      - template: debian-8-martus
      - label: blue

And then to improve the usability of the key handling could we also store that data in same .sls file or some other file with the package?

maintainer:
  - name: Emma G.
  - email: emma@anarchy.org
  - website: https://anarchy.org
  - keyid: 0x3B0F8CCA
  - fingerprint: 1B5BAEEA01DBE9EC8420E5B668B2C4A23B0F8CCA 
  - avatar: path/to/avatar.jpg

My reasoning is that users tend to understand the concept of interacting with people, companies, or projects a bit better than importing a cryptographic key and of course we could still show the full fingerprint under a hidden menu (for developers we've established trust with) or shown for untrusted sources

As per my work on the New "Qubes Manager" in #1870 I envisioned calling these Recipes and clicking on the button would launch a separate window that. Now that I've got the hang of Gtk + python a bit I could pretty easily make a little interface showing these concepts with test data

[bnvk]

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.

I'd been assuming we'd a UI for the browsing / installing / removing of salt formulas from a users machine, thus this would involve more than just the key management, and by keys I assume PGP keys correct @marmarek ? In both cases, I was thinking making this engaging and welcoming with icons and names.

Since the .sls files appear to just be YML format, are they flexible enough to just add values to the existing fields like:

martus:
  recipe:
    - title: Martus
    - description: Martus is a free, open source, secure information collection and management tool that empowers rights activists to be stronger in their fight against injustice and abuse.
    - icon: path/to/logo.png
  qvm.vm:
    - present:
      - template: debian-8-martus
      - label: blue

And then to improve the usability of the key handling could we also store that data in same .sls file or some other file with the package?

maintainer:
  - name: Emma G.
  - email: emma@anarchy.org
  - website: https://anarchy.org
  - keyid: 0x3B0F8CCA
  - fingerprint: 1B5BAEEA01DBE9EC8420E5B668B2C4A23B0F8CCA 
  - avatar: path/to/avatar.jpg

My reasoning is that users tend to understand the concept of interacting with people, companies, or projects a bit better than importing a cryptographic key and of course we could still show the full fingerprint under a hidden menu (for developers we've established trust with) or shown for untrusted sources

As per my work on the New "Qubes Manager" in #1870 I envisioned calling these Recipes and clicking on the button would launch a separate window that. Now that I've got the hang of Gtk + python a bit I could pretty easily make a little interface showing these concepts with test data

[adrelanos]

In my view, users do not understand well to decide to trust various
individuals or companies. They want to get task x, y, z done. For the
goal towards mass adaption of Qubes, rather than inventing a key and
trust scheme, I would suggest to have some well tested, well supported
official recipes for common cases we want to support.

[adrelanos]

In my view, users do not understand well to decide to trust various
individuals or companies. They want to get task x, y, z done. For the
goal towards mass adaption of Qubes, rather than inventing a key and
trust scheme, I would suggest to have some well tested, well supported
official recipes for common cases we want to support.

[marmarek]

In my view, users do not understand well to decide to trust various individuals or companies. They want to get task x, y, z done. For the goal towards mass adaption of Qubes, rather than inventing a key and trust scheme, I would suggest to have some well tested, well supported official recipes for common cases we want to support.

Yes, on the second thought it seems to be a better option.

As for enhancing formulas with additional metadata - it isn't that simple, because salt would try to parse it and obviously will fail. Anyway we definitely need some GUI with name, description, icon of a formula to install. That metadata can probably go as a separate file.

[marmarek]

In my view, users do not understand well to decide to trust various individuals or companies. They want to get task x, y, z done. For the goal towards mass adaption of Qubes, rather than inventing a key and trust scheme, I would suggest to have some well tested, well supported official recipes for common cases we want to support.

Yes, on the second thought it seems to be a better option.

As for enhancing formulas with additional metadata - it isn't that simple, because salt would try to parse it and obviously will fail. Anyway we definitely need some GUI with name, description, icon of a formula to install. That metadata can probably go as a separate file.

[bnvk]

@adrelanos @marmarek what i'm envisioning would look and feel like a normal "app store" experience, e.g. Apple App Store, Google Play, etc... for the trusted recipes. I think it would be nice to down the line offer installing recipes that are not official, but are still secure :)

As for enhancing formulas with additional metadata - it isn't that simple, because salt would try to parse it and obviously will fail.

I'll just make a small example with the metadata and how I see it being implemented toward the above goal.

[bnvk]

@adrelanos @marmarek what i'm envisioning would look and feel like a normal "app store" experience, e.g. Apple App Store, Google Play, etc... for the trusted recipes. I think it would be nice to down the line offer installing recipes that are not official, but are still secure :)

As for enhancing formulas with additional metadata - it isn't that simple, because salt would try to parse it and obviously will fail.

I'll just make a small example with the metadata and how I see it being implemented toward the above goal.