Copying QVM Features in Salt Pillar: any reason not to do that?

TL;DR

Does the intent behind the QVM features feature (:grimacing:) make it safe to add them to the Salt pillar?

Context

I am currently experimenting with a few different ways to target Salt states.

As part of doing that, Iā€™ve added QVM tags to the Salt pillar. (Iā€™m using @brianā€™s example ā€“ gist.)

Because I needed a value to hold a list, Iā€™m also using QVM features in dom0. (And defining a space-separated string that I interpret as a list of VM names, like the AppMenu feature seems to do.)

In order to use that list from Salt, I added all QVM features to the pillar, with code thatā€™s very similar to he one that extends pillar with QVM tags.

Question

I donā€™t see anything in the currently defined QVM features that I think should be kept out of pillar, so Iā€™m adding all features to the pillar.

Am I missing something?

More generally: what is the intention behind QVM features, is it likely that some features (current or future) shouldnā€™t be published in the pillar?

The trade-off that I identify is: adding all features at once makes for (a smaller amount of) more general code; putting in pillar only the features I currently need requires more code and more maintenance but makes less assumptions about other features.

I donā€™t want to be over-optimizing for imagined security risks, hence my question about the intent behind QVM features. If theyā€™re aready considered like ā€œpublicā€ information as far as the corresponding VMs are concerned, then Iā€™m less worried about about putting them all at once in the Salt pillar.

(Note: Iā€™m broadly assuming that anything in the Salt pillar is visible to the VMs being managed, which might not be true, but my question about the intended use of QVM features still stands. :slightly_smiling_face:)

1 Like

By the way, for further context: this question is loosely related to What's the Future Of Multi-VM Applications? (SecureDrop Workstation-Inspired) - #13 by cfm

1 Like

@marmarek @unman Pardon the direct mention: I suspect this might not have been the best place to ask about development intent, but maybe it was only a bad time.

Do you have thoughts on including QVM tags and features to the Salt pillar, or thoughts about who might have some? :slightly_smiling_face:

Thanks, @gonzalo-bulnes, I have the same questions.

Using tags for this purpose has the same issue as features. They are both for Qubes usage and end-user usage. The Admin API will add tags that arenā€™t intended for users to modify, and we donā€™t know whether those Qubes-defined tags are sensitive.

It would be great to know whether Qubes will add any data to features or tags that shouldnā€™t be exposed to VMs through Salt. But it would be better to have a place to set attributes on VMs through admin CLI tools that only the end user controls.

1 Like

Yep. I havenā€™t seen any feature or tag that was (to me) obviously an issue to expose to the VM. Most information I find can either be inferred from the packages installed in the VM, or from generic knowledge about what a default Qubes OS installation looks like.

I feel a bit uneasy about asking any kind of committment to not define new tags or features that should noy be exposed to the VM. The future is the future (that is essentially unknown), and it seems somewhat unfair to me to over-constrain the use of those tools.

On the other hand, I also feel uneasy about asking for new tools to be added for this specific purpose when features and tags do the job reasonably well.

So that leaves me keeping an eye on the features / tags that my VMs use and deferring any further decision to change on my side until such a decision MUST be made.

1 Like

Iā€™ve Saltā€™d exposing QVM features and tags in pillar (separately) so that I can make that a requisite in states/formulas that require it.

I havenā€™t packaged any of that yet, but it seems those would be simple packages with no dependencies themselves.


On the bigger picture I still need to validate my plan to package those and define them as RPM dependencies of packages that contain states that include/require them. That seems like a good approach to me in theory but I suppose I wonā€™t be sure until I validate what it feels like to maintain in practice. Iā€™ll drop a note here when I get there :slightly_smiling_face:

1 Like

To be fair, there is definitely a world where each formula that relies on a tag or a feature includes a state that selectively exposes that tag or feature in pillar. So thatā€™s another avenue worth exploring if it becomes desirable to keep some of the Qubes OS-maintained information out the pillar. Maintainability trade-offs!

Another tangentially related aspect to keep in mind is the potential for naming conflicts. There, namespaces come to my mind immediately, and could be an alternative to creating entirely separate tools. If qvm-features and qvm-tags had a notion of namespace, most of the risks weā€™ve been identifying around exposing unwanted information in pillar when cutting that maintainabiltity trade-off potentially go away.

A package for this would be fantastic. Canā€™t wait to test it :wink:

To be fair, there is definitely a world where each formula that relies on a tag or a feature includes a state that selectively exposes that tag or feature in pillar. So thatā€™s another avenue worth exploring if it becomes desirable to keep some of the Qubes OS-maintained information out the pillar. Maintainability trade-offs!

How would the tag/feature selection state work? Would it require the end user to edit pillar data for this state after installing a dependent formulas?

Another tangentially related aspect to keep in mind is the potential for naming conflicts. There, namespaces come to my mind immediately, and could be an alternative to creating entirely separate tools. If qvm-features and qvm-tags had a notion of namespace, most of the risks weā€™ve been identifying around exposing unwanted information in pillar when cutting that maintainabiltity trade-off potentially go away.

Right, I have no desire for another tool. Namespace capabilities in features or tags would be great if it came with some guarantee that Qubes wonā€™t create or remove data in user-defined namespaces.

Is the supported-service. prefix in features prior art? Since tags only support hyphen separators, could we (ab)use the dot separator to add a user-defined prefix to features right now? Then /srv/salt/_pillar/qvm_features.py could filter out non-user-defined features. What in Qubes, besides the qvm services functionality, cares about dot-separated prefixes in features?

Let me see if I can get some code out. Unless Iā€™m missing something while thinking about this in abstract, it should be quicker to show than to describe in words.

1 Like

No idea!! I had never noticed the dot prefix! :open_mouth:

1 Like

The manpage for qvm-features makes it sound like Qubes makes no guarantees about feature purpose or naming conventions:

Warning: This list of features may be incomplete, because extensions are free to use any values, without registering them anywhere.

What are ā€œextensionsā€ for qvm-features?

It looks like many features also use a dot prefix. So a lot of things in Qubes care about it.

I think ā€œextensionsā€ is what weā€™re doing: defining our own features and relying on them for our own purposes. :slightly_smiling_face:

1 Like

I was hoping youā€™d say that! :partying_face:

I did some preliminary work on this today, and opened an issue to help you keep track of progress. (It may take me a little while to find the time to do it. :grimacing: )

Edit: Iā€™ve opened a draft pull request that contains the two formulas so you can take a look now. There are no supporting files, README but I donā€™t doubt youā€™ll find your way browsing the code for now. The PR is linked in the issue.

Temporary shorcuts:

This is fabulous. Thank you, @gonzalo-bulnes! I incorporated these into my Salt files and they work as we expect. It will be great to seamlessly migrate to the RPM versions.

Iā€™m obviously motivated to help with packaging the new formulas. And Iā€™d love to learn RPM packaging. Maybe Iā€™ll find time before you do :sweat_smile:

1 Like

Iā€™ve set up packaging for the qvm-features-in-pillar formula! :slightly_smiling_face: And I forgot adding a direct link in the README :woman_shrugging: next time.

The packages are not reproducible, so I donā€™t really recommend anyone to get the package that Iā€™ve published for my own use, because there is little way to confirm itā€™s been built from the source you see in GitHub (unless maybe if youā€™re very familiar with the internal structure of an RPM package and can make sense of a diffoscope report, at this point I canā€™t.)

However, with the setup done, creating the packages yourself can be as straightforward as (eighteen steps follow :sweat_smile:):

  1. clone the repo
  2. there are a few dependencies to make sure are there (see pre-requisites in README)
  3. add a signed tag so that the packaging tooling can verify the integrity of the sources (youā€™ll see mine gb_8e1f8f82 there, so itā€™s all about creating a similar one locally thatā€™s signed with a key you control, see below for how to do that)
  4. set a few (simple) environment variables (same README)
  5. run make packages

If you want to test the package in a dispVM:

  • make sure RPM knows about the signing (public) key for the purpose of verifying signatures: sudo rpm --import <mykey.gpg>
  • install the package youā€™ve just built: sudo dnf install ./qubes-mgmt-salt-user-qvm-features-in-pillar-1.0.0-1.noarch.rpm
  • confirm that /srv was populated as expected

Once in dom0, donā€™t forget that:

  • user directories are assumed to be enabled (see below if needed)
  • the package installation will overwrite /srv/user_salt/qvm-features-in-pillar
  • top files need to be enabled, this one is no exception: sudo qubesctl top.enable qvm-features-in-pillar

Useful references:

2 Likes

The qvm-tags-in-pillar packaging setup is done as well, and this time the package should be reproducible, or very close to be. :slightly_smiling_face:

Otherwise, the same observations apply that I wrote in the previous post, and this time I added all relevant links to the main README.

This concludes the side-topic in this thread I think. For those whoā€™re curious, the next target is making the packages reproducible, but thatā€™s best discussed in:

Please join that conversation if youā€™re interested in testing / learning about reproducible builds with a Qubes OS, Salt-flavored motivation! :wink:

1 Like

Cross-posting: