help with creating a dispVM with a non-random name

[Ivan Mitev]

Hi,

I'm trying to implement "semi-persistent" dispVMs (in 4.0) that could be
used for more than one time, until the service call ends (eg. the
browser is closed by the user). The idea is to save resources/time and
allow several consecutive links to be opened in the *same* dispVM until
the user decides to scrap the VM by closing its browser.
It's of course less secure than using a dispVM for a single usage, but
it's much better than always using the same browser in an AppVM like I
do because a/ I usually don't have enough RAM to have several dispVMs
opened, b/ I'm usually in a hurry and don't want to wait for a dispVM to
pop up, c/ dispVMs don't have bookmark management.

But for that to work I need to set the dispVM's name (eg.
'dispBrowsing') rather than the randomly generated "disp[0-9]+" string.

`qvm-run` doesn't provide that functionality but it seems achievable
with qubes's python API. I had a look at some tests in
python/site-packages/qubes/... where dispVM names were hardcoded (eg.
'disp42' or 'disp123') but before spending too much time trying to
understand those, I thought I'd ask here (+, the question seemed to be
too in-depth for the qubes-users ML)

It's important to retain the "shutdown/destroy when service call ends"
functionality; a comment in vm/__init__.py (line 342) says "when running
in dom0, one need to manually kill the dispVM after service call ends"
(line 342). Does that mean that AppVMs have to initiate the creation of
a dispVM with `qvm-open-in-dvm`, or is it possible to create such
dispVMs in dom0 ?

Another solution would be use create/destroy standard AppVMs but have a
dispVM behavior - ie. shutdowning when the service call ends. Is that
possible ? I looked at RPC actions but didn't find anything relevant.

Thanks in advance !

Ivan

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, May 02, 2018 at 05:22:55PM +0300, Ivan Mitev wrote:
> Hi,
>
> I'm trying to implement "semi-persistent" dispVMs (in 4.0) that could be
> used for more than one time, until the service call ends (eg. the
> browser is closed by the user). The idea is to save resources/time and
> allow several consecutive links to be opened in the *same* dispVM until
> the user decides to scrap the VM by closing its browser.
> It's of course less secure than using a dispVM for a single usage, but
> it's much better than always using the same browser in an AppVM like I
> do because a/ I usually don't have enough RAM to have several dispVMs
> opened, b/ I'm usually in a hurry and don't want to wait for a dispVM to
> pop up, c/ dispVMs don't have bookmark management.
>
> But for that to work I need to set the dispVM's name (eg.
> 'dispBrowsing') rather than the randomly generated "disp[0-9]+" string.

You can start a normal DispVM and copy&paste links there. This is what I
do - a habit from times where no other option was available.

> `qvm-run` doesn't provide that functionality but it seems achievable
> with qubes's python API. I had a look at some tests in
> python/site-packages/qubes/... where dispVM names were hardcoded (eg.
> 'disp42' or 'disp123') but before spending too much time trying to
> understand those, I thought I'd ask here (+, the question seemed to be
> too in-depth for the qubes-users ML)
>
> It's important to retain the "shutdown/destroy when service call ends"
> functionality;

This seems contradicting what you want to achieve. If the VM should be
destroyed after the call ends, it wont be there after opening one link.
I think you've meant "shutdown/destroy when _all_ service calls ends",
but there are a lot of corner cases in such feature.

> a comment in vm/__init__.py (line 342) says "when running
> in dom0, one need to manually kill the dispVM after service call ends"
> (line 342). Does that mean that AppVMs have to initiate the creation of
> a dispVM with `qvm-open-in-dvm`, or is it possible to create such
> dispVMs in dom0 ?
>
> Another solution would be use create/destroy standard AppVMs but have a
> dispVM behavior - ie. shutdowning when the service call ends. Is that
> possible ? I looked at RPC actions but didn't find anything relevant.

You can create a DispVM with a static name. Such VM will not have
persistent storage (so, all the browser history, cache etc will be gone
after you shutdown the VM), but you can launch multiple rpc calls,
without spawning new instance for each. When you decide to close it, you
can simply choose "shutdown" action in qubes widget, instead of closing
just the browser. Or combine it with automatic shutdown of inactive VMs:
https://github.com/QubesOS/qubes-issues/issues/832
(there are at least two scripts for this linked there)

To create a DispVM with a static name, use:

qvm-create -C DispVM -t fedora-26-dvm -l red my-static-dispvm

- --
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?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlrp2V0ACgkQ24/THMrX
1yyGpAf9Gbl8EcYjYv93m1fZTDj89w8Sh31nfxDlMPR3FKFp10HAkrUXJTF6IEn+
Zo+k5mCmwD26CH46JmPMNehEj0gAvs6eKUYNYoIsAs+ujQsHe8AQseZiROJc/FyP
qP6/uEFg+suWCIW87jY5t4RvA8BJRUMugEcRprk0cglI5NQWOctNmo1B+x6dZX6z
K0Mqad2RUKOKI4tf3Ff83NuOzg+SVmY59v64tzznCoJAw0X3gL0W++sPYfWcUqNj
MJKZCgXHBagLmY0jGhtOO2TowGDrPZBb1qOH3FdTgX69dY/cnFISuh1H9+b1WYpy
M1GYtwlIPJAxHFzRfgUeIqpmiommyg==
=3wsg
-----END PGP SIGNATURE-----

[Ivan Mitev]

On 05/02/2018 06:29 PM, Marek Marczykowski-Górecki wrote:
> On Wed, May 02, 2018 at 05:22:55PM +0300, Ivan Mitev wrote:
>> Hi,
>
>> I'm trying to implement "semi-persistent" dispVMs (in 4.0) that could be
>> used for more than one time, until the service call ends (eg. the
>> browser is closed by the user). The idea is to save resources/time and
>> allow several consecutive links to be opened in the *same* dispVM until
>> the user decides to scrap the VM by closing its browser.
>> It's of course less secure than using a dispVM for a single usage, but
>> it's much better than always using the same browser in an AppVM like I
>> do because a/ I usually don't have enough RAM to have several dispVMs
>> opened, b/ I'm usually in a hurry and don't want to wait for a dispVM to
>> pop up, c/ dispVMs don't have bookmark management.
>
>> But for that to work I need to set the dispVM's name (eg.
>> 'dispBrowsing') rather than the randomly generated "disp[0-9]+" string.
>
> You can start a normal DispVM and copy&paste links there. This is what I
> do - a habit from times where no other option was available.

Yes I know, but I don't find it very convenient. The idea here would be
to have a non-networked AppVM with a bookmark manager (and maybe
password manager too) and use it to open links in a given dispVM; this
can be streamlined almost transparently without needing any copy/paste
between VMs by (re)configuring the mimetype scheme handler ([1] [2]).

>> `qvm-run` doesn't provide that functionality but it seems achievable
>> with qubes's python API. I had a look at some tests in
>> python/site-packages/qubes/... where dispVM names were hardcoded (eg.
>> 'disp42' or 'disp123') but before spending too much time trying to
>> understand those, I thought I'd ask here (+, the question seemed to be
>> too in-depth for the qubes-users ML)
>
>> It's important to retain the "shutdown/destroy when service call ends"
>> functionality;
>
> This seems contradicting what you want to achieve. If the VM should be
> destroyed after the call ends, it wont be there after opening one link.
> I think you've meant "shutdown/destroy when _all_ service calls ends",
> but there are a lot of corner cases in such feature.

Not sure what you mean - the idea was the following: an AppVM opens a
link with `qvm-open-in-dvm` dispName url:

1/ if dispName doesn't exist, it is created and a browser (eg. firefox)
pops up with the url.

2/ if dispName exists, a new tab is opened in the existing browser (it
is expected that a browser would be running otherwise the dispVM would
be killed because the service call in 1/ would have ended)

I'd have expected that when the browser is closed by the user the dispVM
would be killed - even if many tabs are open - because the initial
service call in 1/ is "qubes.StartApp+firefox" (or something like that)
and that process/service ended.
Do you mean that in case 2/ service calls "pile up" and that even if the
first service call in 1/ ends the dispVM won't be killed because
subsequent calls are still running ?

>> a comment in vm/__init__.py (line 342) says "when running
>> in dom0, one need to manually kill the dispVM after service call ends"
>> (line 342). Does that mean that AppVMs have to initiate the creation of
>> a dispVM with `qvm-open-in-dvm`, or is it possible to create such
>> dispVMs in dom0 ?
>
>> Another solution would be use create/destroy standard AppVMs but have a
>> dispVM behavior - ie. shutdowning when the service call ends. Is that
>> possible ? I looked at RPC actions but didn't find anything relevant.
>
> You can create a DispVM with a static name. Such VM will not have
> persistent storage (so, all the browser history, cache etc will be gone
> after you shutdown the VM), but you can launch multiple rpc calls,
> without spawning new instance for each. When you decide to close it, you
> can simply choose "shutdown" action in qubes widget, instead of closing
> just the browser. Or combine it with automatic shutdown of inactive VMs:
> https://github.com/QubesOS/qubes-issues/issues/832
> (there are at least two scripts for this linked there)
>
> To create a DispVM with a static name, use:
>
> qvm-create -C DispVM -t fedora-26-dvm -l red my-static-dispvm

Thanks for that - I had forgotten that 'DispVM' was a valid class. That
could be a workaround if regular dispVMs can't be used.


[1]
https://micahflee.com/2016/06/qubes-tip-opening-links-in-your-preferred-appvm/

[2] https://github.com/Qubes-Community/Contents/issues/24

[Ivan Mitev]

I did 2 tests:

1. using "regular" DispVMs

- from the Qubes menu, open firefox in a DispVM; 'disp5195' is started.
- in my untrusted AppVM, `qvm-open-in-vm disp5195 "http://somesite.com";
a new tab is created in disp5195's firefox.
- in my work AppVM, `qvm-open-in-vm disp5195 "http://someothersite.com";
another tab is created in disp5195's firefox.
- close firefox

-> disp5195 is killed.

That's exactly what I need; is that the expected behavior, or am I just
being lucky without the "corner cases" you mentioned ?

If that's the expected behavior, is there a way to start the dispVM name
(eg. dispBrowser) from dom0 instead of getting a random disp[0-9]+ name ?


2. using the way other way you suggested:

- create a VM with class DispVM
- start it from dom0 with `qvm-run --service dispBrowser
qubes.StartApp+firefox` (similar to the .desktop commands of dispVMs in
the qubes menu).
- open http links from AppVMs as above
- close firefox

-> dispBrowser isn't killed/shutdown


So I get half the behavior I need with each of those tests but I don't
manage to combine both - define a DispVM name *and* have the VM killed
when the initial service call ends.

I just realize that a workaround for case 2/ could be to define a new
application shortcut (or systemd unit) that would run firefox and then
poweroff when it exits. Or instead of poweroff, ask dom0 to kill it.

[Sven Semmler]

On 05/02/2018 09:22 AM, Ivan Mitev wrote:
> I'm trying to implement "semi-persistent" dispVMs (in 4.0) that could
> be used for more than one time, until the service call ends (eg. the
> browser is closed by the user).

I understand what you are looking for and would like something like that
too. Unfortunately I lack the knowledge/skill to contribute this myself
but let me at least share the idea:

You know the dialog that pops up in Qubes 4 now when one calls qvm-copy
or qvm-move to select the target VM?

It would be great if qvm-open-in-vm would show a simliar dialog if no
target VM was specified. In that dialog one could choose an app VM, an
existing DispVM instance or create a new DispVM.

I copy and paste plenty of URLs everyday. My default DispVM connects to
TOR ... but there are other URLs in my email that link either to a
specific Jira issues (open in dev VM) or a link that identifies me in
some way (makes no sense to open that over a TOR connection - is
actually harmful). Still most links I want to open in the DispVM with
TOR (Whonix) as they are just links to articles, presentations and
nothing in the URL identifies me.

/Sven

[Ivan Mitev]

On 05/22/2018 08:02 AM, Sven Semmler wrote:
> On 05/02/2018 09:22 AM, Ivan Mitev wrote:
>> I'm trying to implement "semi-persistent" dispVMs (in 4.0) that could
>> be used for more than one time, until the service call ends (eg. the
>> browser is closed by the user).
>
> I understand what you are looking for and would like something like that
> too. Unfortunately I lack the knowledge/skill to contribute this myself
> but let me at least share the idea:
>
> You know the dialog that pops up in Qubes 4 now when one calls qvm-copy
> or qvm-move to select the target VM?

yes - you get that dialog when the qubes policy [1] for a given rpc
service is set to ask.

> It would be great if qvm-open-in-vm would show a simliar dialog if no
> target VM was specified. In that dialog one could choose an app VM, an
> existing DispVM instance or create a new DispVM.

change the following policies in dom0:

/etc/qubes-rpc/policy/qubes.OpenInVM
/etc/qubes-rpc/policy/qubes.OpenURL

for instance

'$anyvm $dispvm allow' -> '$anyvm $dispvm ask'

(or 'work $dispvm ask' if you want to have the popup dialog displayed
only for the 'work' VM).

if you use tor you may want to change the whonix* stuff - I'm not
familiar with how those VMs interact with each other.

> I copy and paste plenty of URLs everyday. My default DispVM connects to
> TOR ... but there are other URLs in my email that link either to a
> specific Jira issues (open in dev VM) or a link that identifies me in
> some way (makes no sense to open that over a TOR connection - is
> actually harmful). Still most links I want to open in the DispVM with
> TOR (Whonix) as they are just links to articles, presentations and
> nothing in the URL identifies me.

I see. FYI there's a xdg mime tweak [2] that you can use to reconfigure
how you open URLs *globally* in a VM. That means that clicks, auto-open
stuff, ..., can automatically get redirected to 'qvm-open-in-vm' ; The
problem is that apps could leak info without having you notice (actually
you'll see the url open in the dest VM but even if you stop it early you
may have leaked info through the url). But combined with the policy
tweaks above and you get a pretty powerful user controlled setup without
habing to copy/paste between VMs.

hope this helps !


[1] https://www.qubes-os.org/doc/rpc-policy/
[2]
https://micahflee.com/2016/06/qubes-tip-opening-links-in-your-preferred-appvm/

PS: off-topic for qubes-devel: there's an effort to write some doc on
that topic at https://github.com/Qubes-Community/Contents/issues/24
Feel free to drop a comment (or contribute) there...

>
> /Sven
>
>

[Sven Semmler]

On 05/23/2018 01:18 AM, Ivan Mitev wrote:
> hope this helps !

A lot! Sorry that it took me so long to see your answer. Thank you!

/Sven