Qubes Domains: "Open File Manager" button similar to "Run Terminal"

[andrewdavidwong]

The problem you're addressing (if any)

It could be easier to open the file manager in a qube.

Describe the solution you'd like

In the Qubes Domains widget, we have a "Run Terminal" button for each running qube. I suggest also having an "Open File Manager" button.

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

This would make it easier to open the file manager in a qube, especially in a DisposableVM that doesn't have an Applications menu entry.

Describe alternatives you've considered

I usually just do qvm-run in a dom0 terminal.

Additional context

(None)

Relevant documentation you've consulted

N/A

Related, non-duplicate issues

#2132, #4398

[marmarek]

Especially if it opened the default file manager for that qube and not a specific one

Yes, that's definitely a good idea. Does anyone know if there is something like "default file manager" in Linux, or we need to invent it? xdg-settings knows only default web browser...
Maybe the handler for inode/directory mime type? This is what xdg-open $HOME would do.

[iprid23]

Agreed it's a nice idea.
Also how about having the Change keyboard layout there too?
It's really annoying to change your keyboard layout in a DispVM right now.

[andrewdavidwong]

Also how about having the Change keyboard layout there too?

Not sure if that use case is common enough to merit adding another button to the list.

[unman]

Maybe the handler for inode/directory mime type? This is what xdg-open $HOME would do.

I think this is right, although not infallible.
What about minimal or custom templates where there is no file manager? The button would fail silently, I think.

[marmarek]

Technically adding running DisposableVMs to the menu is not a problem. But doing so will easily lead to another usability issue: DisposableVM by design is destroyed as soon as the application running there is closed. If you start another application there and then close the initial one, DisposableVM will be destroyed, potentially destroying the data you had open in another application. Changing DisposableVM mechanism to destroy it only when last application there is closed also isn't such a good idea, because it could lead to the opposite problem: closing an application and expecting the VM to be destroyed, but in fact it will stay there, because some other application (on another desktop? minimized?) is still running.

As for the proposed menu layout, it looks nice on paper, but multi level menus are hard to navigate. Anyway I like the idea of putting "New" word somewhere in the menu entry for creating new DisposableVM. So, instead of "Disposable: whonix-ws-15-dvm" it could be "New Disposable: whonix-ws-15-dvm". It would be also logical to keep that DisposableVM Template (whonix-ws-15-dvm) somewhere visible, next to dispXXXX names. But that's getting offtopic now.

[airelemental]

2. The DisposableVM that is started manually in the application menu. I do not think most users expect this to shutdown automatically on them. I know I did not and when it did it was really unpleasant. After all, every other VM started via the app menu does not shutdown automatically, so why would the DispVMs? That is my experience as a user.

This style of DisposableVM are already implemented (persist until shutdown, automatic app menu entry) but must be created using CLI (no GUI): https://groups.google.com/d/msg/qubes-users/LB9f9OSWCzM/Grsk5VDjCQAJ

IMHO they are really the natural VM type for VMs as sys-net, sys-usb, untrusted, email VMs, viewing-only VMs, etc... that are untrusted and whose state is mostly static (except for careful changes applied to the DVM template), so that any unauthorized state change disappears next restart.

[brendanhoar]

ON TOPIC:
I think there's a thread here that is important in that there's a need by Qubes users to handle untrusted content which is different than their need to handle very sensitive data, data that should not persist in the Qubes live environment and that it should not be recoverable even by the system owner after VM shutdown.

DisposableVMs were primarily designed for the former (e.g. open in disposable VM...) and the transient nature of the VMs came out of that use case, primarily for resource recovery (RAM, CPU). They are only somewhat useful for the latter user case, in that there is no guarantee that the sensitive data does not stick around as plaintext within the context of the live environment after the disposable VMs shut down or even after Qubes is rebooted and running again (see TAILS-related discourse below).

I think it may be worth separating out the two use cases into two different feature sets and engineering a different solution for the latter use case. DisposableVMs and AmnesiacVMs (or whatever the names should really be, I've been using Ephemeral, but that's probably not right either).

Tangentially related, but probably off-topic of the original ask:

Considering I manually started the VM the same way as every other VM in the system which I control the shutdown it makes sense that those VMs would be controlled by me too. I look at those VMs as more like Tails. When a user wants to do a set related tasks in a non-persistant manner, then they use such a VM.

"more like Tails" can be misleading and I believe quite a few Qubes users assume that DisposableVMs provide more assurances than they actually do. DisposableVMs write to disk and, at least currently. When they are removed, the data they wrote to disk is persisted, at least for a while, in the available space in the LVM thin pool. This due to the "zero-on-allocate" model of thin-pool space allocation. Granted, if you are running LUKS, the plaintext of what was in the DisposableVM is only available once you unlock and boot your Qubes system but that's still not "gone forever".

If auto-shutdown is a non-negotiable feature of the DispsoableVM, then I think it might be useful to have a simple NonPersitantVM that is like a normal VM in every way except nothing is persisted to disk.

The approach I am taking is to:
a) utilize disposableVMs
b) launch a terminal to start the VM
c) launch a second terminal from the first terminal.
d) Minimize the first terminal to make it less likely I might close it by mistake.
e) utilize the second terminal for running all applications, spawn additional terminals from it, etc.
f) when finished close everything but the second terminal, validate that there is nothing on the filesystem I need to preserve (e.g. scripts I created to process data, etc. which I would qvm-move to the appropriate storage if not sensitive or, alternately, save into an encrypted volume I mount/dismount)
g) when satisfied, I un-minimize the originally launched terminal and close/exit it.

Yes, not very user friendly.

In addition, due to the issue of data remaining in the unallocated space on exit, I have two other mitigations (one hardware specific, one not):

1. Utilize @tasket's modification of the lvm.py to enforce blkdiscard (aka trim) of the DisposableVM's LVs before removal. I have previously enabled trim all the way down the software stack to the SSD, which is a SED that supports TRIM and DZAT. This gives a higher confidence in the data being unrecoverable from a live system.
2. Scripted a rather convoluted storage layout to create an ephemeral encrypted thin pool within the existing thin pool (pool00 aka qubes_dom0) for the disposableVMs to run in, so that even though the private and volatile volume data is persisted to disk, the encryption key for the data is only ever in RAM and is destroyed during the teardown portion of the script. This gives highest confidence in the data being unrecoverable from a live system.

And yet, even this isn't to the standard of Tails...but it's more comfortably close. E.g. is it possible for storage layer data from a VM that writes to a separately encrypted layer in dom0 to leak plaintext elsehwere in dom0 (swap, temporary files, logs)? I think @marmarek has expressed a preference for storage encryption running within the VM, which might mitigate this, but then exposes control of what is written plaintext in dom0 to an in-VM attacker. Maybe ephemeral encryption is needed on both the dom0 and VM side? It's turtles all the way down... :)

Brendan

[andrewdavidwong]

Please try to keep your comments on-topic. We already have a lot of other issues that deal with forensics-related topics: #4972, #4488, #4408, #3504, #1293, #904.

The scope of this issue is clearly much narrower.