edits in DispVM are saved, counter to user expectations

[mfc]

Qubes 3.0RC2

1. create text file
2. open text file in DispVM
3. edit and save text file
4. close text file

expected behavior: edited text will not be added to original text files in non-DispVM
actual behavior: edited text is added to original text file in non-DispVM

This runs counter to user expectations give that these are called Disposable VMs.

Reported at CCCamp!

[unman]

Interesting - the actual behaviour is exactly what I expected it to be when I first used a dispVM.
Clearly "user expectations" differ.

A DispVM allows you to work with files that may be malicious without compromising your sensitive VMs.
I wonder what you thought stage 3 - edit and save would do?
It's the VM that is disposable not the work done in it.

The documentation isn't clear on this, so I'm adding a note to make it so

[unman]

Interesting - the actual behaviour is exactly what I expected it to be when I first used a dispVM.
Clearly "user expectations" differ.

A DispVM allows you to work with files that may be malicious without compromising your sensitive VMs.
I wonder what you thought stage 3 - edit and save would do?
It's the VM that is disposable not the work done in it.

The documentation isn't clear on this, so I'm adding a note to make it so

[andrewdavidwong]

Three points:

1. The behavior @mfc describes was originally described as the intentional behavior regarding changes made to files opened in DispVMs. Unfortunately, I can't find the reference now. (I remember reading this a long time ago, probably in one of Joanna's blog posts.)
2. I've tried unsuccessfully to reproduce this behavior in the past, and I still can't reproduce it now. (Perhaps it depends on RPC settings?)
3. Personally, it doesn't bother me that I can't seem to reproduce this behavior, since I actually prefer that changes I make to files opened in DispVMs don't get saved back in the original files. Many times, the reason I open a file in a DispVM is precisely so that I can manipulate a disposable version of that file.

[andrewdavidwong]

Three points:

1. The behavior @mfc describes was originally described as the intentional behavior regarding changes made to files opened in DispVMs. Unfortunately, I can't find the reference now. (I remember reading this a long time ago, probably in one of Joanna's blog posts.)
2. I've tried unsuccessfully to reproduce this behavior in the past, and I still can't reproduce it now. (Perhaps it depends on RPC settings?)
3. Personally, it doesn't bother me that I can't seem to reproduce this behavior, since I actually prefer that changes I make to files opened in DispVMs don't get saved back in the original files. Many times, the reason I open a file in a DispVM is precisely so that I can manipulate a disposable version of that file.

[mfc]

Thanks for the sharing your perspectives @unman and @aXon. We were unable to find any documentation or blogposts that discussed this aspect of Disposable VMs.

There were five developers/hackers in this discussion, and for every one of them they expected from the language ("Open in Disposable VM") that the file would not be able to modify itself based actions performed in the DispVM. It made them slightly uncomfortable given that if the file is malicious, it should not be able to modify/interact with the non-DispVM.

Also, if there is interaction between the DispVM and the non-DispVM, where is the unspoofable dom0 message of file transfer/editing? And because there is no dom0 notification, does that mean the DispVM has some privileged understanding of the non-DispVM file structure and privileged ability to modify? It's a very different VM interaction than what Qubes users have otherwise.

From a language point of view, maybe the solution is to have a "View in Disposable VM" where no changes can be saved, and then "Edit in Disposable VM" which would make it more clear that the file can be modified back into the non-DispVM.

From my perspective, I would want Disposable VMs to be by default non-networked, unable to edit other VMs, so that if the file opened was malicious it could not exfiltrate any data (whether through the network or by changing metadata etc on the non-DispVM) and it would be deleted upon closing the DispVM window. I just created a new ticket #1121 to discuss the non-networked default aspect.

[mfc]

Thanks for the sharing your perspectives @unman and @aXon. We were unable to find any documentation or blogposts that discussed this aspect of Disposable VMs.

There were five developers/hackers in this discussion, and for every one of them they expected from the language ("Open in Disposable VM") that the file would not be able to modify itself based actions performed in the DispVM. It made them slightly uncomfortable given that if the file is malicious, it should not be able to modify/interact with the non-DispVM.

Also, if there is interaction between the DispVM and the non-DispVM, where is the unspoofable dom0 message of file transfer/editing? And because there is no dom0 notification, does that mean the DispVM has some privileged understanding of the non-DispVM file structure and privileged ability to modify? It's a very different VM interaction than what Qubes users have otherwise.

From a language point of view, maybe the solution is to have a "View in Disposable VM" where no changes can be saved, and then "Edit in Disposable VM" which would make it more clear that the file can be modified back into the non-DispVM.

From my perspective, I would want Disposable VMs to be by default non-networked, unable to edit other VMs, so that if the file opened was malicious it could not exfiltrate any data (whether through the network or by changing metadata etc on the non-DispVM) and it would be deleted upon closing the DispVM window. I just created a new ticket #1121 to discuss the non-networked default aspect.

[adrelanos]

I also expected the DispVM to not share anything back with the original VM.

So we have 4 use cases here.

• "View in Disposable VM with disabled networking"
• "View in Disposable VM with enabled networking"
• "Edit in Disposable VM with disabled networking"
• "Edit in Disposable VM with enabled networking"

Is there any sane way to support all that UI wise?

Perhaps there could be two entries in the context menu.

• View in Disposable VM
• Edit in Disposable VM

Upon activating that context by the mouse cursor, it could show another layer:

• with networking disabled
• with networking enabled

---

EDIT: One might also want to distinguish clearnet vs torified networking.

[adrelanos]

I also expected the DispVM to not share anything back with the original VM.

So we have 4 use cases here.

• "View in Disposable VM with disabled networking"
• "View in Disposable VM with enabled networking"
• "Edit in Disposable VM with disabled networking"
• "Edit in Disposable VM with enabled networking"

Is there any sane way to support all that UI wise?

Perhaps there could be two entries in the context menu.

• View in Disposable VM
• Edit in Disposable VM

Upon activating that context by the mouse cursor, it could show another layer:

• with networking disabled
• with networking enabled

---

EDIT: One might also want to distinguish clearnet vs torified networking.

[unman]

The behaviour exactly matches that of qvm-open-in-vm, in that a file changed and saved in the other VM is copied back to the originator. The difference is, of course, that it's edited in a disposable VM rather than one of your appVMs. As I said, it's the VM that is disposable, not the work you do in it.
Using this mechanism allows you to safely use potentially malicious files in one of your secure VMs. (This was the original intention as described by Joanna in her blog post. ) There is no need to feel uncomfortable about this: the file is already in your secureVM - you open and edit it in a disposable VM so even if it is malicious, the attack is limited to the disposable VM which will be nuked at the end of your editing, and it ends up back in your secureVM. The threat level is unchanged.
Agreed, there isn't any message about the file transfer: in the normal case, this provides a check against transferring a file to a VM with a different security context to the originator; in the dispVM case, the security context is (by default) the same. If you want to see a message change the policy in qubes.OpenInVm.

Note that this issue arises because of step 3 - edit and save the file. If you don't want the changes to be reflected in the originator don't save them.
Actually, because a dispVM can be used like any other VM there's no reason why you shouldn't save your changes under a new file name, open a term or gui file manager in the dispVM, and copy the new file back to the originator. That way you have the original and your new edited version. (Both, of course, should be considered potentially malicious.)

On the networking question, this was a change in behaviour introduced quite recently(#862). I don't like it, but its easy to set the default netVM for DispVM to none, so it isn't an issue.

[unman]

The behaviour exactly matches that of qvm-open-in-vm, in that a file changed and saved in the other VM is copied back to the originator. The difference is, of course, that it's edited in a disposable VM rather than one of your appVMs. As I said, it's the VM that is disposable, not the work you do in it.
Using this mechanism allows you to safely use potentially malicious files in one of your secure VMs. (This was the original intention as described by Joanna in her blog post. ) There is no need to feel uncomfortable about this: the file is already in your secureVM - you open and edit it in a disposable VM so even if it is malicious, the attack is limited to the disposable VM which will be nuked at the end of your editing, and it ends up back in your secureVM. The threat level is unchanged.
Agreed, there isn't any message about the file transfer: in the normal case, this provides a check against transferring a file to a VM with a different security context to the originator; in the dispVM case, the security context is (by default) the same. If you want to see a message change the policy in qubes.OpenInVm.

Note that this issue arises because of step 3 - edit and save the file. If you don't want the changes to be reflected in the originator don't save them.
Actually, because a dispVM can be used like any other VM there's no reason why you shouldn't save your changes under a new file name, open a term or gui file manager in the dispVM, and copy the new file back to the originator. That way you have the original and your new edited version. (Both, of course, should be considered potentially malicious.)

On the networking question, this was a change in behaviour introduced quite recently(#862). I don't like it, but its easy to set the default netVM for DispVM to none, so it isn't an issue.

[marmarek]

Exactly, this is intended behaviour. If you want to not override
original file, simply don't save the changes, or operate on a copy.
If you think it is still better to have an option to only "view" the
file, not "edit" (in terms of saving changes), as a separate option,
feel free to provide a patch :) But please, not multi-level menu or
other things decreasing usability...

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]

Exactly, this is intended behaviour. If you want to not override
original file, simply don't save the changes, or operate on a copy.
If you think it is still better to have an option to only "view" the
file, not "edit" (in terms of saving changes), as a separate option,
feel free to provide a patch :) But please, not multi-level menu or
other things decreasing usability...

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?

[mfc]

thanks @unman for clarifying this behavior in the documentation with QubesOS/qubes-doc#29.

Expected behavior should equal intended behavior, if users constantly need to refer to documentation to understand things then that's bad, because most times users will not realize they are misunderstanding the behavior, and will do unsafe things based on that misunderstanding.

From the language we choose and the context we implement it in they should have clear ideas about functionality. Having a "View in DisposableVM" and "Edit in DisposableVM" would help clarify the functionality of both for the user so that they don't need to refer to the documentation.

I don't think we don't need the additional networking options Patrick suggested since the networking options already exist in the Qubes VM manager advanced tab. I am a big fan of making that functionality more transparent to the user, since I was not aware of it in the Advanced tab. Maybe having an option in the Global Settings for a global default networking choice on DispVMs -- [1] inherit from parent AppVM or [2] non-networked? And then folks can change on an per-AppVM basis as desired.

---

One tangential question, with "Edit in DisposableVM" if the DispVM can successfully pass back an edited file to the original AppVM, does that mean the DispVM has an understanding of the AppVM name and file structure of the original AppVM?

[mfc]

thanks @unman for clarifying this behavior in the documentation with QubesOS/qubes-doc#29.

Expected behavior should equal intended behavior, if users constantly need to refer to documentation to understand things then that's bad, because most times users will not realize they are misunderstanding the behavior, and will do unsafe things based on that misunderstanding.

From the language we choose and the context we implement it in they should have clear ideas about functionality. Having a "View in DisposableVM" and "Edit in DisposableVM" would help clarify the functionality of both for the user so that they don't need to refer to the documentation.

I don't think we don't need the additional networking options Patrick suggested since the networking options already exist in the Qubes VM manager advanced tab. I am a big fan of making that functionality more transparent to the user, since I was not aware of it in the Advanced tab. Maybe having an option in the Global Settings for a global default networking choice on DispVMs -- [1] inherit from parent AppVM or [2] non-networked? And then folks can change on an per-AppVM basis as desired.

---

One tangential question, with "Edit in DisposableVM" if the DispVM can successfully pass back an edited file to the original AppVM, does that mean the DispVM has an understanding of the AppVM name and file structure of the original AppVM?

[marmarek]

On Wed, Aug 26, 2015 at 05:24:33AM -0700, Michael Carbone wrote:

From the language we choose and the context we implement it in they should have clear ideas about functionality. Having a "View in DisposableVM" and "Edit in DisposableVM" would help clarify the functionality of both for the user so that they don't need to refer to the documentation.

Agree.

I don't think we don't need the additional networking options Patrick
suggested since the networking options already exist in the Qubes VM
manager advanced tab.

I think we should keep the UI as simple as possible. Having 2-level, 4+
options for just opening a file in DispVM (plus additional options for
copying/moving the file) doesn't look like a simple solution.

I am a big fan of making that functionality more
transparent to the user, since I was not aware of it in the Advanced
tab. Maybe having an option in the Global Settings for a global
default networking choice on DispVMs -- [1] inherit from parent AppVM
or [2] non-networked? And then folks can change on an per-AppVM basis
as desired.

This would be non trivial in current code base (i.e. before core3,
planned for Qubes 4.0). Generally in the current code global
settings/defaults are rather hacky...

So I guess the way to go is simply change default to have non-networked
DispVMs by default. But I'd ask on ML first.

One tangential question, with "Edit in DisposableVM" if the DispVM can successfully pass back an edited file to the original AppVM, does that mean the DispVM has an understanding of the AppVM name and file structure of the original AppVM?

No, DispVM just send a modified blob and source VM put it in place of
original file. DispVM know the base name and extension of the file,
though (to have it displayed in title bar for example).

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 Wed, Aug 26, 2015 at 05:24:33AM -0700, Michael Carbone wrote:

From the language we choose and the context we implement it in they should have clear ideas about functionality. Having a "View in DisposableVM" and "Edit in DisposableVM" would help clarify the functionality of both for the user so that they don't need to refer to the documentation.

Agree.

I don't think we don't need the additional networking options Patrick
suggested since the networking options already exist in the Qubes VM
manager advanced tab.

I think we should keep the UI as simple as possible. Having 2-level, 4+
options for just opening a file in DispVM (plus additional options for
copying/moving the file) doesn't look like a simple solution.

I am a big fan of making that functionality more
transparent to the user, since I was not aware of it in the Advanced
tab. Maybe having an option in the Global Settings for a global
default networking choice on DispVMs -- [1] inherit from parent AppVM
or [2] non-networked? And then folks can change on an per-AppVM basis
as desired.

This would be non trivial in current code base (i.e. before core3,
planned for Qubes 4.0). Generally in the current code global
settings/defaults are rather hacky...

So I guess the way to go is simply change default to have non-networked
DispVMs by default. But I'd ask on ML first.

One tangential question, with "Edit in DisposableVM" if the DispVM can successfully pass back an edited file to the original AppVM, does that mean the DispVM has an understanding of the AppVM name and file structure of the original AppVM?

No, DispVM just send a modified blob and source VM put it in place of
original file. DispVM know the base name and extension of the file,
though (to have it displayed in title bar for example).

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]

So, does this depend on RPC settings? If so, perhaps we should document that somewhere. As I said above, I cannot reproduce this behavior (i.e., I cannot edit a plain text file in a DispVM and have the changes saved back in the original file), and I'm thinking maybe that's because I've modified my RPC settings.

Also, which file types are (supposed to be) implicated here? Just plain text files?

[andrewdavidwong]

So, does this depend on RPC settings? If so, perhaps we should document that somewhere. As I said above, I cannot reproduce this behavior (i.e., I cannot edit a plain text file in a DispVM and have the changes saved back in the original file), and I'm thinking maybe that's because I've modified my RPC settings.

Also, which file types are (supposed to be) implicated here? Just plain text files?

[unman]

@axon-qubes
In my experience this works with all file types. I have seen occasional corruption in docx files edited in libreoffice in a dispVM, but otherwise it works across the board.
I cant see that policy settings would make a difference , but I could be wrong. Which settings have you changed?

[unman]

@axon-qubes
In my experience this works with all file types. I have seen occasional corruption in docx files edited in libreoffice in a dispVM, but otherwise it works across the board.
I cant see that policy settings would make a difference , but I could be wrong. Which settings have you changed?

[marmarek]

@axon-qubes RPC settings shouldn't have anything to do here - either the file is opened in the DispVM (and then changes should be saved back to the source VM), or DispVM wouldn't be started at all. So most likely some bug...

[marmarek]

@axon-qubes RPC settings shouldn't have anything to do here - either the file is opened in the DispVM (and then changes should be saved back to the source VM), or DispVM wouldn't be started at all. So most likely some bug...

[cfcs]

If at some point this moves forward, it might be nice to have it in the VM title (like [disp1:read-only] and [disp1:edit-original]or whatever)

[cfcs]

If at some point this moves forward, it might be nice to have it in the VM title (like [disp1:read-only] and [disp1:edit-original]or whatever)

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.29-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.29-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.29-1.fc26) has been pushed to the r4.0 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.29-1.fc26) has been pushed to the r4.0 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.30-1.fc26) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.30-1.fc26) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.30-1+deb9u1 has been pushed to the r4.0 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.30-1+deb9u1 has been pushed to the r4.0 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 stable repository for the Fedora centos7 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 stable repository for the Fedora centos7 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_3.2.32-1+deb9u1 has been pushed to the r3.2 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_3.2.32-1+deb9u1 has been pushed to the r3.2 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-3.2.32-1.fc26) has been pushed to the r3.2 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.2-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-3.2.32-1.fc26) has been pushed to the r3.2 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.2-current-testing

Changes included in this update