VM description

[marmarek]

Reported by Oleg Artemiev grey olli on 12 Sep 2014 08:14 UTC
It could be usefull to have a text description for a VM in its
properties to document changes/difference.
https://groups.google.com/d/topic/qubes-users/uYCcOqIeF5k/discussion

Migrated-From: https://wiki.qubes-os.org/ticket/899

[marmarek]

Modified by marmarek on 12 Sep 2014 08:14 UTC

[marmarek]

Modified by marmarek on 12 Sep 2014 08:14 UTC

[marmarek]

Comment by joanna on 12 Sep 2014 09:25 UTC
Would be more logical to do that in R3, as part of our qubes.xml revamping.

[marmarek]

Comment by joanna on 12 Sep 2014 09:25 UTC
Would be more logical to do that in R3, as part of our qubes.xml revamping.

[Jeeppler]

I would like to work on this issue (see https://groups.google.com/forum/#!topic/qubes-devel/t32l-0BjlLs).

[Jeeppler]

I would like to work on this issue (see https://groups.google.com/forum/#!topic/qubes-devel/t32l-0BjlLs).

[marmarek]

@bnvk is working on new Qubes Manager, please coordinate.

[marmarek]

@bnvk is working on new Qubes Manager, please coordinate.

[Jeeppler]

Is this still relevant, after decomposing the Qubes Manager? How would it look like? Would it be something like a qvm-description tool? I would love to have a VM description.

[Jeeppler]

Is this still relevant, after decomposing the Qubes Manager? How would it look like? Would it be something like a qvm-description tool? I would love to have a VM description.

[marmarek]

On Tue, Jul 26, 2016 at 02:10:35PM -0700, Jeppler wrote:

Is this still relevant, after decomposing the Qubes Manager? How would it look like? Would it be something like a qvm-description tool? I would love to have a VM description.

I think this may be simply a VM property, accessible using qvm-prefs.
How to present it in GUI is unrelated to this ticket.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Tue, Jul 26, 2016 at 02:10:35PM -0700, Jeppler wrote:

Is this still relevant, after decomposing the Qubes Manager? How would it look like? Would it be something like a qvm-description tool? I would love to have a VM description.

I think this may be simply a VM property, accessible using qvm-prefs.
How to present it in GUI is unrelated to this ticket.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Jeeppler]

Perfect. @marmarek are you considering to implement it as qvm-prefs property in Q R4?

[Jeeppler]

Perfect. @marmarek are you considering to implement it as qvm-prefs property in Q R4?

[andrewdavidwong]

It's worth thinking about how this is related to #865, i.e., defining and disambigutating these possible properties of VMs:

• Description
• Tag
• Attribute

[andrewdavidwong]

It's worth thinking about how this is related to #865, i.e., defining and disambigutating these possible properties of VMs:

• Description
• Tag
• Attribute

[Jeeppler]

I would like to see "Tags" the plural form to do something like: -dev -> tags: work, project

It would be nice to have a "last started" property. This would be helpful to see if the machines are used regularly or have been used a long time ago.

[Jeeppler]

I would like to see "Tags" the plural form to do something like: -dev -> tags: work, project

It would be nice to have a "last started" property. This would be helpful to see if the machines are used regularly or have been used a long time ago.

[Jeeppler]

What would be the "Attribute" property? It seems a little bit generic.

[Jeeppler]

What would be the "Attribute" property? It seems a little bit generic.

[andrewdavidwong]

Yes, "last started" would be useful, especially when trying to decide whether a VM needs to be included in a backup. (If the "last started" date is the same or earlier than the "last backup" date, then it probably doesn't need to be backed up again.)

But this is different from a "VM description," so here's a new issue for it: #2230

[andrewdavidwong]

Yes, "last started" would be useful, especially when trying to decide whether a VM needs to be included in a backup. (If the "last started" date is the same or earlier than the "last backup" date, then it probably doesn't need to be backed up again.)

But this is different from a "VM description," so here's a new issue for it: #2230

[marmarek]

I would like to see "Tags" the plural form to do something like: -dev -> tags: work, project

Yes, that's how it is in Qubes 4.0.

What would be the "Attribute" property? It seems a little bit generic.

That's generic name for tag with some value (so, not only "present"/"absent") ;)

[marmarek]

I would like to see "Tags" the plural form to do something like: -dev -> tags: work, project

Yes, that's how it is in Qubes 4.0.

What would be the "Attribute" property? It seems a little bit generic.

That's generic name for tag with some value (so, not only "present"/"absent") ;)

[marmarek]

Some thoughts about "VM description" feature - it would be useful to allow free-form text, possibly with some non-ASCII characters, multiple lines, etc. So I take back the idea of putting it in qvm-prefs (and consequently in qubes.xml), as it may lead to some troubles (qvm-prefs don't support multi-line values for example). IMO much better store it as a simple description.txt file in VM directory (/var/lib/qubes/appvms/name-of-vm/description.txt). And in preparation for GUI domain - have some qrexec services to access it (qubes.DescriptionGet, qubes.DescriptionSet). For now, those services would be called from dom0 (this is where qubes-manager is running) to dom0.

[marmarek]

Some thoughts about "VM description" feature - it would be useful to allow free-form text, possibly with some non-ASCII characters, multiple lines, etc. So I take back the idea of putting it in qvm-prefs (and consequently in qubes.xml), as it may lead to some troubles (qvm-prefs don't support multi-line values for example). IMO much better store it as a simple description.txt file in VM directory (/var/lib/qubes/appvms/name-of-vm/description.txt). And in preparation for GUI domain - have some qrexec services to access it (qubes.DescriptionGet, qubes.DescriptionSet). For now, those services would be called from dom0 (this is where qubes-manager is running) to dom0.

[andrewdavidwong]

Would that be a potential attack vector in conjunction with qvm-export? (If descrption.txt isn't somehow sanitized.)

[andrewdavidwong]

Would that be a potential attack vector in conjunction with qvm-export? (If descrption.txt isn't somehow sanitized.)

[marmarek]

What do you have in mind? Trying to exploit archive format from inside of included file? That archive tool should be resistant against such attacks because it needs to include also private.img, which is fully controlled by the VM.

[marmarek]

What do you have in mind? Trying to exploit archive format from inside of included file? That archive tool should be resistant against such attacks because it needs to include also private.img, which is fully controlled by the VM.

[andrewdavidwong]

Well, we disallow rendering non-ASCII text in dom0 window titles by default, since window title content is potentially adversary-controlled and therefore presents a potential attack vector against dom0. IIUC, qvm-export is meant to allow importing potentially untrusted VMs. But if we allow non-ASCII characters in description.txt, which also gets imported and rendered in dom0, then we've reintroduced adversary-controlled non-ASCII text rendered in dom0. Is that a problem?

[andrewdavidwong]

Well, we disallow rendering non-ASCII text in dom0 window titles by default, since window title content is potentially adversary-controlled and therefore presents a potential attack vector against dom0. IIUC, qvm-export is meant to allow importing potentially untrusted VMs. But if we allow non-ASCII characters in description.txt, which also gets imported and rendered in dom0, then we've reintroduced adversary-controlled non-ASCII text rendered in dom0. Is that a problem?

[Jeeppler]

@marmarek it would be useful to allow free-form text, possibly with some non-ASCII characters, multiple lines, etc. yes, I absolutely agree with you.

@andrewdavidwong I assume the reason for only allowing rendering a specific subset of ASCII characters has to do with technical limitations of the window manager.

I would like to have Unicode (UTF-8) support. Unicode (UTF-8) allows to write text and words in almost all languages and is not limited to English.

[Jeeppler]

@marmarek it would be useful to allow free-form text, possibly with some non-ASCII characters, multiple lines, etc. yes, I absolutely agree with you.

@andrewdavidwong I assume the reason for only allowing rendering a specific subset of ASCII characters has to do with technical limitations of the window manager.

I would like to have Unicode (UTF-8) support. Unicode (UTF-8) allows to write text and words in almost all languages and is not limited to English.

[andrewdavidwong]

@andrewdavidwong I assume the reason for only allowing rendering a specific subset of ASCII characters has to do with technical limitations of the window manager.

I would like to have Unicode (UTF-8) support. Unicode (UTF-8) allows to write text and words in almost all languages and is not limited to English.

No, it's not a technical limitation. Rather, UTF-8 in window titles is disabled by default as a security measure for the reasons I mentioned above. If you like, you can enable UTF-8 in window titles by setting allow_utf8_titles = true, either globally or on a per-VM basis, in /etc/qubes/guid.conf in dom0.

[andrewdavidwong]

@andrewdavidwong I assume the reason for only allowing rendering a specific subset of ASCII characters has to do with technical limitations of the window manager.

I would like to have Unicode (UTF-8) support. Unicode (UTF-8) allows to write text and words in almost all languages and is not limited to English.

No, it's not a technical limitation. Rather, UTF-8 in window titles is disabled by default as a security measure for the reasons I mentioned above. If you like, you can enable UTF-8 in window titles by setting allow_utf8_titles = true, either globally or on a per-VM basis, in /etc/qubes/guid.conf in dom0.

[marmarek]

But if we allow non-ASCII characters in description.txt, which also gets imported and rendered in dom0, then we've reintroduced adversary-controlled non-ASCII text rendered in dom0. Is that a problem?

Ah, indeed this may be a problem. I see a few options:

• don't import description.txt as part of the VM importing
• strip it of dangerous characters (which also will include <, & etc, to avoid triggering some HTML or other parsers)

[marmarek]

But if we allow non-ASCII characters in description.txt, which also gets imported and rendered in dom0, then we've reintroduced adversary-controlled non-ASCII text rendered in dom0. Is that a problem?

Ah, indeed this may be a problem. I see a few options:

• don't import description.txt as part of the VM importing
• strip it of dangerous characters (which also will include <, & etc, to avoid triggering some HTML or other parsers)

[rootkovska]

1. I like keeping description as a separate file, not to pollute the XML file.

2. I think coming up with a general method to sanitize description would be tricky. We don't know what widget/application will finally want to display it. This is potentially much harder to reasonable sanitation of titlebars.

3. So, instead, I would go for ignoring it while... well that's the challenge: we can't just say: ignore it only for imported VMs (restoring VMs previously qvm-exported by someone else), while retain for those imported from a backup, easily. Can we?

4. We should aim at treating any qvm-backup-restore operation as potentially untrusted. 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 (where we restoring to) should not get compromised -- i.e. neither Dom0, nor the hypervisor, and firmware, etc, should not be affected (this of course assumes the user opting out from restoring the Dom0 home dir, which often can be used with minimal PITA).

BTW just to double check, @andrewdavidwong: the scenario you really mean is qvm-backup-restore importing a previously qvm-exported (by someone else) VM, correct?

[rootkovska]

1. I like keeping description as a separate file, not to pollute the XML file.

2. I think coming up with a general method to sanitize description would be tricky. We don't know what widget/application will finally want to display it. This is potentially much harder to reasonable sanitation of titlebars.

3. So, instead, I would go for ignoring it while... well that's the challenge: we can't just say: ignore it only for imported VMs (restoring VMs previously qvm-exported by someone else), while retain for those imported from a backup, easily. Can we?

4. We should aim at treating any qvm-backup-restore operation as potentially untrusted. 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 (where we restoring to) should not get compromised -- i.e. neither Dom0, nor the hypervisor, and firmware, etc, should not be affected (this of course assumes the user opting out from restoring the Dom0 home dir, which often can be used with minimal PITA).

BTW just to double check, @andrewdavidwong: the scenario you really mean is qvm-backup-restore importing a previously qvm-exported (by someone else) VM, correct?

[marmarek]

On Sat, Apr 01, 2017 at 04:32:15AM -0700, Joanna Rutkowska wrote: 3. So, instead, I would go for ignoring it while... well that's the challenge: we can't just say: ignore it _only_ for imported VMs (restoring VMs previously qvm-exported by someone else), while retain for those imported from a backup, easily. Can we?

Yes, we can simply ignore this file during VM import - this will be a separate tool, so it can have separate logic for handling this.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

On Sat, Apr 01, 2017 at 04:32:15AM -0700, Joanna Rutkowska wrote: 3. So, instead, I would go for ignoring it while... well that's the challenge: we can't just say: ignore it _only_ for imported VMs (restoring VMs previously qvm-exported by someone else), while retain for those imported from a backup, easily. Can we?

Yes, we can simply ignore this file during VM import - this will be a separate tool, so it can have separate logic for handling this.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[andrewdavidwong]

BTW just to double check, @andrewdavidwong: the scenario you really mean is qvm-backup-restore importing a previously qvm-exported (by someone else) VM, correct?

If qvm-backup-restore is the tool used to import VMs that have been created (and potentially shared) with the qvm-export-vm tool (#1747), then yes. However, #1747 doesn't specify whether it would be qvm-backup-restore or a new tool, e.g., qvm-import-vm.

Yes, we can simply ignore this file during VM import - this will be a
separate tool, so it can have separate logic for handling this.

Ok, sounds like it would indeed be a new tool (e.g., qvm-import-vm).

[andrewdavidwong]

BTW just to double check, @andrewdavidwong: the scenario you really mean is qvm-backup-restore importing a previously qvm-exported (by someone else) VM, correct?

If qvm-backup-restore is the tool used to import VMs that have been created (and potentially shared) with the qvm-export-vm tool (#1747), then yes. However, #1747 doesn't specify whether it would be qvm-backup-restore or a new tool, e.g., qvm-import-vm.

Yes, we can simply ignore this file during VM import - this will be a
separate tool, so it can have separate logic for handling this.

Ok, sounds like it would indeed be a new tool (e.g., qvm-import-vm).

[rootkovska]

Yes, we can simply ignore this file during VM import - this will be a
separate tool, so it can have separate logic for handling this.

But the doesn't solve the problem that we still want to have qvm-backup-restore to be resistant to a compromise if the previous system (on which qvm-bakup/qvm-export were run) was compromised.

Perhaps a solution to this would be to add a switch to qvm-backup-restore: e.g. `--distrust-backup", which would imply: 1) don't restore Dom0 homedir, 2) ignore VM description files, 3) perhaps some other things, TBD in another ticket.

And, yes, having a separate qvm-import tool, which always ignores description.txt files.

[rootkovska]

Yes, we can simply ignore this file during VM import - this will be a
separate tool, so it can have separate logic for handling this.

But the doesn't solve the problem that we still want to have qvm-backup-restore to be resistant to a compromise if the previous system (on which qvm-bakup/qvm-export were run) was compromised.

Perhaps a solution to this would be to add a switch to qvm-backup-restore: e.g. `--distrust-backup", which would imply: 1) don't restore Dom0 homedir, 2) ignore VM description files, 3) perhaps some other things, TBD in another ticket.

And, yes, having a separate qvm-import tool, which always ignores description.txt files.