Allow users to attach arbitrary free-form metadata to qubes for their own use

[DemiMarie]

The problem you're addressing (if any)

I would like for users to be able to attach arbitrary freeform metadata to qubes for their own use. This metadata is not machine readable, but it should be editable in the GUI, and qubes should be able to be grouped based on it. Furthermore, it must support fairly arbitrary UTF-8 strings, since users need to be able to set it in their native language.

Describe the solution you'd like

I suggest reserving the human.* namespace of features for use by humans. Such features are to be considered opaque to programs, and have no meaning beyond what the human user gives them.

Where is the value to a user, and who might that user be?

Users will be able to assign arbitrary freeform metadata.

Describe alternatives you've considered

Additional context

Relevant documentation you've consulted

Related, non-duplicate issues

[ninavizz]

This reads an awful lot like a follow-up to #6560... may I ask, is it @DemiMarie?

Also: I love this issue so much, just because it proposes a designation for things in the code to be meaningful to human eyes, only. <3

[DemiMarie]

This reads an awful lot like a follow-up to #6560... may I ask, is it @DemiMarie?

No, but it is a follow-up to #6555 and thus to #2949.

Also: I love this issue so much, just because it proposes a designation for things in the code to be meaningful to human eyes, only. <3

Thank you <3

In practice, such features will likely wind up being base64-encoded (or otherwise escaped) at some point, so that they can fit within the restrictions imposed by other parts of QubesOS. Those restrictions are there for legitimate security reasons and I do not want to remove them. But they will be unescaped in the GUI.

[andrewdavidwong]

Related to or possible duplicate of: #899, #952

[ghost]

In practice, such features will likely wind up being base64-encoded (or otherwise escaped) at some point, so that they can fit within the restrictions imposed by other parts of QubesOS. Those restrictions are there for legitimate security reasons and I do not want to remove them.

Good Idea using base64! However, it could still be used as an attack vector; being able to put a binary blob in qubes.xml that is auto-decoded by qubes-manager, or other trusted software is problematic. #899 (comment) .

But they will be unescaped in the GUI.

Auto-decoding base64 in any trusted environment risks breaking the nice property of "The ultimate goal for qvm-backup-restore should be that, even if the backup was made on a compromised Qubes system, than the new system" #899 (comment) . Perhaps by default only using ascii, but add an addition to enable UFT-8 (behind the scenes that would use base64 and validate the UTF-8), similar to allow_utf8_titles #899 (comment) . Additionally adding a setting in qubes-manager to change whether to allow UTF-8 from within the UI). So an out of the box Qubes install would still have the nice security properties, however if users choose to accept the risk, they can use UTF-8, accepting the slight risk.

[DemiMarie]

But they will be unescaped in the GUI.

Auto-decoding base64 in any trusted environment risks breaking the nice property of "The ultimate goal for qvm-backup-restore should be that, even if the backup was made on a compromised Qubes system, than the new system" #899 (comment) . Perhaps by default only using ascii, but add an addition to enable UFT-8 (behind the scenes that would use base64 and validate the UTF-8), similar to allow_utf8_titles #899 (comment) . Additionally adding a setting in qubes-manager to change whether to allow UTF-8 from within the UI). So an out of the box Qubes install would still have the nice security properties, however if users choose to accept the risk, they can use UTF-8, accepting the slight risk.

That is a good idea. base64 is sufficiently simple that I am not too worried about decoder exploits, but UTF-8 rendering exploits are a legitimate concern. We might be able to use a renderer written in Rust to avoid at least some of the risk.

[marmarek]

Rendering UTF-8 is not the only "scary" thing. Some toolkits (including both GTK and Qt) support (a subset of) markups like HTML or similar. So, allowing ascii only may still carry significant attack surface if not done carefully.

[ghost]

Correct me if I'm wrong, but can't Qubes also set their own features? Like when QWT sets gui here? If they can, then a Qubes-aware attack from an infected domU could inject a feature starting with human. and attempt to compromise the relatively complex dom0 parser (If it properly handles HTML, UTF-8, base64, ect). Doing a check for human. wouldn't be ideal as future development that allows for modification of features would need to be aware implement that check.

@ninavizz in the responses in the appmenu survey #6560 (comment) did people want one UTF-8 compatible notes field, or multiple? Did they want to sort/filter on that? Or just have a separate dialog for seeing and editing the notes? Personally I'm fine with just ascii (aka valid input to qvm-features/qvm-tags).

What would the downsides of:

• Adding one qvm-prefs called "description" that is by default treated as an ASCII string, but if the user accepts the risk of UTF-8, it would be a base64-encoded UTF-8 string instead.
• Using qvm-features human.* and qvm-tags (after sanitizing) as searchable/filterable in qubes-manager?

That would still allow a compromised domU to attempt to exploit the sanitizer, but it would be only be ASCII. However it would prevent a rouge domU from touching the UTF-8 parser (as that data is stored base64-encoded in qvm-prefs). It would also not allow non-english speaking users to search/filter (as qvm-features and qvm-tags are limited to ASCII) in qubes-manager.

[DemiMarie]

Rendering UTF-8 is not the only "scary" thing. Some toolkits (including both GTK and Qt) support (a subset of) markups like HTML or similar. So, allowing ascii only may still carry significant attack surface if not done carefully.

Agreed, but that can be fairly easily tested for. Also, at least with GTK, my understanding is that only a subset of APIs interpret markup. Rendering UTF-8 has far more corner cases to check for.

[DemiMarie]

That said, I ultimately believe we must figure out a way to render untrusted text safely, regardless of source language. As I am sure @ninavizz will confirm, proper internationalization support is absolutely essential. The first idea that comes to my mind is to require all characters in a field to be in the same script, which is in turn selected by the user (and thus trusted). That prevents homograph and mixed-direction attacks; the rest can (hopefully) be mitigated by using a renderer written in a memory-safe language.

[marmarek]

Correct me if I'm wrong, but can't Qubes also set their own features? Like when QWT sets gui here?

Not directly. It can request features to be set, and then the request is validated (basically a list of allowed features + value of "1" or ""). For reference:

• https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-features.html#qvm-features-request-qubes-postinstall-service
• https://dev.qubes-os.org/projects/core-admin/en/latest/_modules/qubes/ext/core_features.html#CoreFeatures

[andrewdavidwong]

Duplicate of #899

[andrewdavidwong]

This appears to be a duplicate of an existing issue. If so, please comment on the appropriate existing issue instead. If anyone believes this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.