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?

[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?

[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

[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.

[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.

[mfc]

are we actually targeting R4.1 for this? I've moved to R4.2.

once there is an agreed-upon data structure, @ninavizz it would be great to get your input on what that could look like. also i'm not clear exactly where it should live -- yes referenced from the Qubes Manager but should there also be a dedicated widget or it being linked from some other existing widget? just as all other functionality is decomposed elsewhere.

and once there is basic agreement, i would be happy to work with community to draft some example recipes.

[ninavizz]

Where is the value in a GUI for Salt recipes? I honestly don't even really know what Salt is (I have a vague understanding that it has to do with package management and config scripts), and suspect that anyone who would, would be comfortable managing that in the CLI?

TL;DR, there are A LOT of things that Qubes needs GUI'd and made more usable. I'd like to get a centralized pool of such things, so that we can maybe better prioritize?

@andrewdavidwong could this get a UX tag? :D

[unman]

On Wed, Mar 31, 2021 at 05:20:27PM -0700, Nina Eleanor Alter wrote: Where is the value in a GUI for Salt recipes? I honestly don't even really know what Salt is, and suspect that anyone who would, would be comfortable managing that in the CLI? TL;DR, there are A LOT of things that Qubes needs GUI'd and made more usable. I'd like to get a centralized pool of such things, so that we can maybe better prioritize? @andrewdavidwong could this get a UX tag? :D

Salt is a configuration tool - you use it when you update your system, and you used it (behind the scenes) when you first set up your Qubes system. You can use Salt to easily setup qubes, or to install particular capabilities in to templates or qubes. You can install salt states using a standard fedora package - whether you would want this to *automatically* implement the state is worth discussing.There's been discussion in the Forum - I prefer to allow users to review the state before running it, but then I mostly want users to understand what they are doing ,( and learn more), rather than just click and install. This doesn't make me a wonk, security or otherwise.

[ninavizz]

@unman I won't tell anyone you're a wonk, promise! ;) The SecureDrop team (whom I also work with) use Salt to configure our bespoke Qubes Workstations, so it's a term I'm familiar with... I just somewhat suck at comprehending things I can't visualize. But it's worth it to understand those things to me, if it can help me give things a visual framework for others to better understand them with.

@mfc Honestly, the best GUI would come from the designer working with a handful of formulas the community agrees are good/solid to use as a basis for building a GUI from. Data structuring, how exceptions/rules are established, etc. Do you press "Go" on them, or what actions get taken? Stuff like that.

Also, something like this I envisioned going into the proposed #6483, likely under the "Advanced" pulldown (or in place of it).

[mfc]

ok makes sense, i will try to coordinate the creation of some example salt recipes. would someone at FPF be interested in contributing some more general journalist example recipes? any interest from @unman @tlaurion @tasket ?

FYI this is an old mock-up but i think starting from scratch more systematically as you describe is the way to go.

[ninavizz]

I don't think any of FPF's journalist users have ever actually used Salt? Most are non-technical Mac users. Less curious/excited about technology that doesn't come with an 800 number to call when help is needed, and simply wanting stuff "to work" so they can focus on their investigative projects. Which I say with no doubts of Salt as a great opportunity, but more in acknowledgement of it as a current strange-unknown to our core users (and, heck, to me!).

Libre software's appeal is in its trustworthiness wrt security. The decentralized community-driven part of it of course "why" that is, yet it also imposes new behavioral and expectations shifts for end users that can feel abrupt and burdensome.

I really love the idea of creating an app-store like experience (wrt ease/access) for browsing, consuming, and sharing recipes! It feels like a terrific vehicle to present the libre ecosystem's roots in community support as an appealing thing, vs a draining thing in its otherness.

Back to Salt, tho— @conorsch is a huge Salt fan, and I mentioned this ticket to him earlier today. I definitely think he'd be a great contributor to this thread!

[andrewdavidwong]

I just suspect that it won't be productive to try to UX workshop something that doesn't exist enough to be UXed yet. We at least need to know for sure what all the technical requirements will be (or have someone who does in the workshop).

And I didn't mean "lean" as in specifically following some Agile methodology; just in the sense of minimal overhead.

[SvenSemmler]

I don't know if we need to make this all so complicated (including this giant discussion thread).

I agree, it seems we are talking past each other. Nina saw this thread from the perspective of designing a store UI (which at some point later would surely be awesome). You seem to think about it from the perspective of developing something. But the way I understand this ticket is "design and create [...] distribution method". This is asking primarily for a process. How can less skilled users download, trust and apply salt formula? If it comes from unman and there is a description how to apply it, many might choose to trust since he is a core Qubes OS team member. But what if maybe I want to contribute a formula? How can users that doesn't understand salt formula trust? So what we need is a process. Something like: * a central repository * very limited number people with commit rights * some form of review process Kind of like how it is with the HCL reports right now. Everyone can send you a pull request but only you and maybe a small number of others can commit and thereby publish on the website.

[SvenSemmler]

I just suspect that it won't be productive to try to UX workshop something that doesn't exist enough to be UXed yet. We at least need to know for sure what all the technical requirements will be (or have someone who does in the workshop).

Ok, maybe I misunderstood you too. Seems we are on the same page. Process and tools first. UI later. When I read workshop I thought "come up with process/tools" not "come up with UI". Sorry for the confusion.

[ninavizz]

I just suspect that it won't be productive to try to UX workshop something that doesn't exist enough to be UXed yet. We at least need to know for sure what all the technical requirements will be (or have someone who does in the workshop).

Workshops are for needs-finding, and to co-create processes. Please don't assume a thing I might be proposing might be to exclusively hone-in on presumed limitations of "UX."

Broadly, UX cannot succeed without a lot of other things falling into place. Historically, because of that, UX designers have often stepped-up and into product development roles to resolve the myriad of open questions that need to be solved for, in order for tools we develop to succeed.

So while I see very little UI design being actually needed for this product to succeed, I do see user research factoring into it—as well as a lot of "product development" around roles, processes, etc. for the human system behind the store. If that makes sense. Please see this article on Service Design. This is much more of a service design project, than a "UI" design project; and Service Design is more than half the work, that most UX designers do.

[ninavizz]

Sidenote: I see a LOT of time spent by folks, rabbit-holing on Issues here in GitHub, that do not seem to align with actual priorities for the QubesOS project to succeed beyond the walls of its existing community.

The goal of a Workshop, is to get requisite tasks done, done thoroughly and well, and to get them done fast—then closed (or put into the hands of an individual contributor to get to work 'building stuff').

Otherwise, actual priories never receive the attention they need, and everything suffers. This project just does not feel like a priority, but it is clearly desired—so then how to gather requisite information for a community member to build something on their own with all the information they need, is the goal of the workshop.

[SvenSemmler]

rabbit-holing on Issues here

Proposal to change that: https://qubes-os.discourse.group/t/design-and-create-salt-formulas-distribution-method-1939/3592

[ninavizz]

Thank you @SvenSemmler! I've also pinged UX colleagues who regularly do workshops, to get some ideas going for async workshop formats so that everyone could potentially contribute, over the period of a week or something. Whatever we do, this is @andrewdavidwong's realm and I want to be mindful to not step on his toes. Workshopping is a common tool used by UX folks to gather requirements and find alignment on products that I'd love to be able to put to work w/ this community if possible.

[ninavizz]

31 March, I asked:

"Where is the value in a GUI for Salt recipes? I honestly don't even really know what Salt is (I have a vague understanding that it has to do with package management and config scripts), and suspect that anyone who would, would be comfortable managing that in the CLI?"

I never really got the answer I'd hoped for at that time. Which is ok! UX designers often don't get those answers, for quite a while. :)

I finally got my answer: Enable easy installation (and updating capabilities) of apps to qubes.
Boom! More granular as well, is a desire to facilitate easy installation of apps configured to security needs unique to a user's circumstances.

I'm personally using a machine, that was 99% configured by other people. The only app I've installed to date, was Signal, and it took me about a week to figure-out having to do that. Which, as a UX person, I would wag my finger-at and say "No user should have to go through that!" Yet having been the person who endured that, I shrugged and said "Eh, I'm not a Linux native, I guess I needed to learn how to do that?" The correct answer should lie somewhere in between, and should be easily discoverable by any user.

Big thanks to @tlaurion for helping me understand this, in an hour+ meeting we had a couple of weeks ago.
From the the appmenu survey:

Most importantly, the issue to be tackled here as said in previous meeting is how the user is supposed to install applications. I spoke about Wire as a typical example.
Let's follow the rabbit a little.

user goes to : https://wire.com/en/download/
Then if knowledgeable enough, understands that Ubuntu=debian, and chooses to click on the repository link.
He then lands here: https://github.com/wireapp/wire-desktop/wiki/How-to-install-Wire-for-Desktop-on-Linux

Follows instructions, transferring inner knowledge of QubesOS, launches debian-10 terminal and then:
sudo apt-get install apt-transport-https
wget -q https://wire-app.wire.com/linux/releases.key -O- | sudo apt-key add -

Which fails. Because TemplateVMs are not able to exit outside of the whonix proxy for apt/dnf.
So the user here has two options, give debian-10 network access and forget about it, or if knowledgeable enough, will block all internet connection and put exclusion for the next 5 minutes. Still, he is playing with the TemplateVM configuration, which he should not be doing.

wget -q https://wire-app.wire.com/linux/releases.key -O- | sudo apt-key add -
should be replaced by
curl --proxy http://127.0.0.1:8082/ --tlsv1.2 --proto =https --max-time 180 https://wire-app.wire.com/linux/releases.key | sudo apt-key add -

And then user can continue to follow other application installation that has a repository available. We are not talking here about installing snap, nor qubes-os-snap-helper. The user needs to know a lot of the background workings to be able to install an app, where, prior of being able to use it.

One UX focus should be to permit installation of applications by salt provided and validated repository, downloaded and made available through QubeSOS updates. The installer should propose to deploy such personas, attached to the applications per se. And/or, the repositories should be made available, but deactivated, so the user can launch Template relative GUI for software installation, and activate/deactivate possible channels to be able to be independent in installation of the softwares. he needs to use on a daily basis. Otherwise, we are loosing users or need to assist them a lot, while documentation are not making those ""translations"" (wget to curl to have internet access through proxy)."

[andrewdavidwong]

I'm personally using a machine, that was 99% configured by other people. The only app I've installed to date, was Signal, and it took me about a week to figure-out having to do that. Which, as a UX person, I would wag my finger-at and say "No user should have to go through that!" Yet having been the person who endured that, I shrugged and said "Eh, I'm not a Linux native, I guess I needed to learn how to do that?" The correct answer should lie somewhere in between, and should be easily discoverable by any user.

This is a hard problem because, even if the UX-finger-wagging is correct, most of the target of that wagging is probably stuff we merely inherit from upstream projects, including entire gigantic Linux distros. The reason this is a hard problem is because we (the comparatively tiny Qubes OS Project) don't stand a chance of trying to fix the UX problems of gigantic upstream Linux distros, and it'd be foolish of us even to try. At best, we can get our own UX house in order, but that will still leave a lot of stuff in the "you need to learn some Linux" realm.

[DemiMarie]

I'm personally using a machine, that was 99% configured by other people. The only app I've installed to date, was Signal, and it took me about a week to figure-out having to do that. Which, as a UX person, I would wag my finger-at and say "No user should have to go through that!" Yet having been the person who endured that, I shrugged and said "Eh, I'm not a Linux native, I guess I needed to learn how to do that?" The correct answer should lie somewhere in between, and should be easily discoverable by any user.

This is a hard problem because, even if the UX-finger-wagging is correct, most of the target of that wagging is probably stuff we merely inherit from upstream projects, including entire gigantic Linux distros. The reason this is a hard problem is because we (the comparatively tiny Qubes OS Project) don't stand a chance of trying to fix the UX problems of gigantic upstream Linux distros, and it'd be foolish of us even to try. At best, we can get our own UX house in order, but that will still leave a lot of stuff in the "you need to learn some Linux" realm.

When it comes to software installation, Flatpak tries to solve the problem and does an okay job at it. We can also make installing some particularly common applications easier by shipping Salt formulas to securely install them.

[ninavizz]

@andrewdavidwong Nope, "the problem" was that I tried installing Signal in the VM, and not the Template; and then once I installed it on the Template, I did not know that I had to manually refresh the Apps list in the app vm. None of that is a single-environment mental-model, which comes back to the core usability issue with Qubes. A very hypervisor-specific problem we absolutely can/should speak to in a Simple User Guide, and should the funding becomes available, speak to in an Installation Manager.

Repeating CLI prompts on a software package's installation page, is cake. When an org like Signal makes it so easy, and the user is working with a common distro like Debian or Fedora, we should be able to pick up from that to keep it smooth.

[tlaurion]

@DemiMarie I replied to your comment #1939 (comment) under #2766 (comment). I would love to have your insights about the current state of flatpak/snap since I am not yet comfortable recommending it.

[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