dispvm browser retains information

[Jon deps]

Hello, in Thunderbird when I do open-in-vm and check firefox it has
retained bookmarks from a previous session,

I believe this is Not how DVMs are supposed to work ?


If so how would I troubleshoot and/or remove old DVM data sesssions
please

[Mike Keehan]

Is the qvm-prefs property "template_for_dispvms" True for your
dvm template?

Mike.

[unman]

You're right. It isn't how disposableVMs are supposed to work.

The obvious question is, what did you select when you "did" open-in-vm?
If you selected an appVM, have you made sure that you have made that
appVM in to a template for disposableVMs?
(qvm-prefs <qube> template_for_dispvms True)

Also check to see what you have set in
/etc/qubes-rpc/policy/qubes.OpeninVM and
/etc/qubes-rpc/policy/qubes.OpenURL

unman

[Jon deps]

What I did/have done is for secure printing(per Qubes docs advice) ,
cloned fedora-29 -> fedora-29printtemplate, then I use the clone as the
template for an AppVM (named fedoraprintqube).

when I do :
$qvm-prefs fedoraprintqube

template - fedora-29printtemplate
template_for_dispvms - True

$qubes-prefs

default_dispvm - fedoraprintqube


re: "what did I choose" there is only 1 choice in Thunderbird
Open-in-dispvm

right click and choose and it open the atttachment in a dispvm


re: rpc policy everything is as default setup


further the AppVM in which Thunderbird is running has it's default
DispVM set to: fedoraprintqube



is there some directory I should clear where dispVM information
would be stored to perhaps reset the system ?


or any further ideas welcome regards

[unman]

There was an issue before where disposableVMs were leaking information
but that was under 3 where the structure was somewhat different.
There may be 2 cases:
1. a disposableVM is created and you are seeing information from the
underlying fedoraprintqube - normal, and to be expected;
2. a disposableVM is created and you are seeing information from a previous
disposableVM session. Bug.
Are you able to rule out (1) and confirm that it is (2)? When a qube is
created, it is definitely named dispXX?

[Jon deps]

ah ok , so it's #1 , so what is disposed of in this configuration by
using the DVM based on a AppVM instead of a TemplateVM ?

or is there any benefit for the disposable-ness ? perhaps I should be
using a Template for true disposable data ?

[unman]

The benefit of disposableness is, well, that data will be disposed of.

Why might you want to do this using an appVM?
Lets say you have a template which provides firefox, and you configure a
couple of qubes using that template - one has ad-block, and other
security oriented plug-ins, and a selection of your favourite bookmarks;
the other has no plugins, but a few bookmarks.
So the obvious advantage of basing disposableVMS on the qubes is that you
have firefox configured just the way you like and access to relevant
bookmarks, but you have the relative security of knowing that pretty
much anything hostile will disappear when you close the browser, and the
disposableVM is cleared.
You could do this in the template but it would be somewhat
more difficult (and risky) since you would have to give the template
network access to install plugins. Of course, you'd also need two
templates to provide the different needs of the qubes.

Naturally, all disposableVMs based on a qube will carry the same
fingerprint as the qube, so you cant use them to provide a measure
of separation between identities. (The same goes, to some extent, to
qubes sharing a template.)

In your case, there may not be any advantage in using a a qube as
opposed to a template. I don't know what you are trying to achieve in
using Qubes.
You need to look at the capabilities and decide what will best suit your
needs.

unman