Add tags and features to pillar

[ben-grande]

Original version: https://github.com/gonzalo-bulnes/qubes-mgmt-salt-user

Opened discussion at https://www.mail-archive.com/qubes-devel@googlegroups.com/msg05459.html, no response, maybe a PR helps.

[marmarek]

Tags are probably fine, but all features I'd be more careful about. Including them in pillar means the VM will indirectly learn them. Some are explicitly published into qubesdb (see qvm-features man page), but not all, and this is the API for any 3rd-party extension to store extra data about the qube, which may include some secrets.

[ben-grande]

Then an enumeration/allow-list of features can be made. From the manpage, only vm-config features.

How to choose what is okay to be published? Are the ones listed in the manpage for qvm-features allowed to be published? If you think this will complicate too much the PR, I can separate the tags from the features on different PRs.

[marmarek]

How to choose what is okay to be published?

This is a very good question. Definitely vm-config.* and service.* are safe. Other currently defined might be safe too (but it would be behavior change, as VM didn't have this ability before. For example showing net.fake-ip will tell the VM it's not seeing its "real" IP, but that can be deduced indirectly too. Or internal will tell the VM its menu entries (and some other stuff) is hidden - another thing that VM didn't know before.

So, I'd go with the safe list above, and if anybody needs something else, it can be made configurable or such, to avoid having some long/complex list hardcoded.

[marmarek]

Oh, and just noticed the service.* is not really documented there. QubesOS/qubes-core-admin-client#290

[gonzalo-bulnes]

FWIW, when thinking about what features may be safe to expose to the VMs or not, I considered creating a custom namespace (as in service.*, not in the Salt sense).

That seemed to me more practical than allowlisting individual features, which felt like it would be pushing the problem one config file further.

Unless I'm wrong, the namespace implementation wouldn't require new code, only documenting the convention so that no-one accidentally creates features which name will make them be exposed to VMs. Of course, the name chosen for that namespace could also go a long way in preventing surprises.

[ben-grande]

FWIW, when thinking about what features may be safe to expose to the VMs or not, I considered creating a custom namespace (as in service.*, not in the Salt sense).

That seemed to me more practical than allowlisting individual features, which felt like it would be pushing the problem one config file further.

I agree it would be better to do that directly to qubesadmin rather than modify the _pillar/qvm_features.py.

Unless I'm wrong, the namespace implementation wouldn't require new code, only documenting the convention so that no-one accidentally creates features which name will make them be exposed to VMs. Of course, the name chosen for that namespace could also go a long way in preventing surprises.

I believe it would need new code on the qubesadmin side, at least to report via a new safe_to_share_features() for example, that gather only vm-config. and service..

My latest commit only covers those two classes of features, but in the future, it makes sense to do that directly to qubesadmin.

[marmarek]

I believe it would need new code on the qubesadmin side, at least to report via a new safe_to_share_features() for example, that gather only vm-config. and service..

That's interesting idea, but I think it's okay to defer adding it until there will be a need for a second user of such function.
For now, it just wants documentation which features are shared - see https://www.qubes-os.org/doc/salt/#the-qubes-pillar-module

[marmarek]

FYI QubesOS/qubes-core-admin#593