"Open in DisposableVM": Popup to enable insecure settings, like networking

[RefinedSoftwareLLC]

Was Duplicate of #1118 (sorry), renamed.

An alternative implementation (which may be more secure):

• Select "Open in DisposableVM"
• Dom0 opens a popup asking if you want to enable insecure settings:

[Dom0] Open in DisposableVM

<filename>
[ ] Enable editing file on qube: <vm-name> (If unchecked, do not send back changes to original file & cloned file needs Read-only attribute set before opening in DispVM)
[ ] Enable networking (So malware can't phone home by default)
[Cancel] (encase malware triggered the open).

Original implementation for this issue:

Qubes OS version:

R4.0

Affected component(s):

File Manager's right click menu option to "Open in DisposableVM".

---

Steps to reproduce the behavior:

Create a file in <vmname>.
Use File Manager's right click menu option "Open in DisposableVM".
In DispVM, change file and save changes.
Reopen the file in <vmname>, and see if the changes were saved.

Expected behavior:

If a file has malware, I do not want it to be able to change itself, like how some delete/corrupt their own file contents, store telemetry, or store stolen authentications. It is more secure to have the file be read-only when edits are not needed.

The File Manager's right click menu should have these two options:

1. "Open & Edit in DisposableVM" or just "Edit in DisposableVM"
2. "Read-only in DisposableVM" or just "View in DisposableVM"

• This never brings any changes back to the original VM.
• The copy of the file in the DisposableVM has its access reduced to read-only before it is opened.
• Note: You can't just get the "Copy To Other AppVM" to work easily on a DispVM to view a file.

Actual behavior:

File Manager's right click menu option to "Open in DisposableVM" allows editing the file.

[RefinedSoftwareLLC]

An alternative implementation (which may be more secure):

• Select "Open in DisposableVM"
• Dom0 opens a popup asking if you want to enable insecure settings:

[Dom0] Open in DisposableVM

<filename>
[ ] Enable editing file on qube: <vm-name> (If unchecked, do not send back changes to original file & cloned file needs Read-only attribute set before opening in DispVM)
[ ] Enable networking (So malware can't phone home by default)
[Cancel] (encase malware triggered the open).

[RefinedSoftwareLLC]

An alternative implementation (which may be more secure):

• Select "Open in DisposableVM"
• Dom0 opens a popup asking if you want to enable insecure settings:

[Dom0] Open in DisposableVM

<filename>
[ ] Enable editing file on qube: <vm-name> (If unchecked, do not send back changes to original file & cloned file needs Read-only attribute set before opening in DispVM)
[ ] Enable networking (So malware can't phone home by default)
[Cancel] (encase malware triggered the open).

[airelemental]

Duplicate of #1118 ?

Right now in current-testing, you can do this:
$ qvm-open-in-vm --viewonly
or right-click
Edit in DispVM
View in DispVM

[airelemental]

Duplicate of #1118 ?

Right now in current-testing, you can do this:
$ qvm-open-in-vm --viewonly
or right-click
Edit in DispVM
View in DispVM

[RefinedSoftwareLLC]

Okay I am going to change the title, to incorporate the second idea. Sorry for duplicate of #1118 .

[RefinedSoftwareLLC]

Okay I am going to change the title, to incorporate the second idea. Sorry for duplicate of #1118 .

[RefinedSoftwareLLC]

The popup idea, would be future compatible. For "Opening in a DispVM", the right click menu wouldn't need every possible combination of security. Instead new security features could be added to the popup, defaulted to the secure option as an unchecked checkbox.

The popup could have a dropdown of DispVMs, like the "[Dom0] Operation execution", but with the system defaults "Default DispVM" already selected.

[RefinedSoftwareLLC]

The popup idea, would be future compatible. For "Opening in a DispVM", the right click menu wouldn't need every possible combination of security. Instead new security features could be added to the popup, defaulted to the secure option as an unchecked checkbox.

The popup could have a dropdown of DispVMs, like the "[Dom0] Operation execution", but with the system defaults "Default DispVM" already selected.

[airelemental]

You can bring up the settings GUI of an already-running dispvm, e.g.
$ qubes-vm-settings disp1831
from there you can edit the NetVM to be clearnet or whonix or whatever.

With some scripting you can bind a keyboard shortcut that instantly opens the settings GUI for the foremost VM,

[airelemental]

You can bring up the settings GUI of an already-running dispvm, e.g.
$ qubes-vm-settings disp1831
from there you can edit the NetVM to be clearnet or whonix or whatever.

With some scripting you can bind a keyboard shortcut that instantly opens the settings GUI for the foremost VM,

[marmarek]

Lets not introduce additional popup, making the system more usable is about reducing them, not multiplying. But if you want, it is already possible to assign different DispVMs for different actions, or even - as you propose - choose them each time (which IMO is a bad idea). If you consider a case where some VM (normally network disconnected?) could use "Open in DisposableVM" action to phone home, better set network-disconnected DispVM there (without any prompts), instead of relying on the user to carefully choose the right thing each time. Remember, if you consider such a case, you should not trust that the file sent to view/edit is the one you've really wanted.
You can do this by setting "default_dispvm" property for such VM (for example have fedora-28-dvm-offline for that purpose). Or even per-action, using qrexec policy, like this:

$ cat /etc/qubes-rpc/policy/qubes.OpenInVM
# source          target                         action
some-offline-vm   $dispvm                        allow,target=$dispvm:fedora-28-dvm-offline
another-vm        $dispvm                        allow,target=$dispvm:fedora-28-dvm

# or have 'ask', with a list of available options defined by other 'ask' actions:
some-vm           $dispvm                        ask,default_target=$dispvm:fedora-28-dvm-offline
some-vm           $dispvm:fedora-28-dvm-offline  ask
some-vm           $dispvm:fedora-28-dvm          ask

[marmarek]

Lets not introduce additional popup, making the system more usable is about reducing them, not multiplying. But if you want, it is already possible to assign different DispVMs for different actions, or even - as you propose - choose them each time (which IMO is a bad idea). If you consider a case where some VM (normally network disconnected?) could use "Open in DisposableVM" action to phone home, better set network-disconnected DispVM there (without any prompts), instead of relying on the user to carefully choose the right thing each time. Remember, if you consider such a case, you should not trust that the file sent to view/edit is the one you've really wanted.
You can do this by setting "default_dispvm" property for such VM (for example have fedora-28-dvm-offline for that purpose). Or even per-action, using qrexec policy, like this:

$ cat /etc/qubes-rpc/policy/qubes.OpenInVM
# source          target                         action
some-offline-vm   $dispvm                        allow,target=$dispvm:fedora-28-dvm-offline
another-vm        $dispvm                        allow,target=$dispvm:fedora-28-dvm

# or have 'ask', with a list of available options defined by other 'ask' actions:
some-vm           $dispvm                        ask,default_target=$dispvm:fedora-28-dvm-offline
some-vm           $dispvm:fedora-28-dvm-offline  ask
some-vm           $dispvm:fedora-28-dvm          ask

[RefinedSoftwareLLC]

I agree that there are trade offs with using the popup, even though it has its advantages (less right click clutter, networking disabled by default, able to choose dvm-template).
The bare minimum is having the "View in DispVM" feature which I am told is implemented in current-testing. @andrewdavidwong feel free to close this, if this change is currently undesirable. It can always be reopened if it becomes needed in the future (if right click clutter gets out of hand or needed to add future security feature).

[RefinedSoftwareLLC]

I agree that there are trade offs with using the popup, even though it has its advantages (less right click clutter, networking disabled by default, able to choose dvm-template).
The bare minimum is having the "View in DispVM" feature which I am told is implemented in current-testing. @andrewdavidwong feel free to close this, if this change is currently undesirable. It can always be reopened if it becomes needed in the future (if right click clutter gets out of hand or needed to add future security feature).

[andrewdavidwong]

Closing as "won't do." If anyone has a new argument for why this should be done, please leave a comment, and we'll be happy to take another look. Thank you.

[andrewdavidwong]

Closing as "won't do." If anyone has a new argument for why this should be done, please leave a comment, and we'll be happy to take another look. Thank you.