DispVM design decisions for Qubes 4.0

[Marek Marczykowski-Górecki]

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

Hi all,

In Qubes 4.0 we're going to (finally!) implement support for multiple
DispVM templates: https://github.com/QubesOS/qubes-issues/issues/866

In principle it will be possible to start an AppVM in "disposable" mode
- - which means changes to its private image (in addition to root image as
in normal AppVM) will be discarded after VM shutdown. Technically any
AppVM can be used for that, but practically it makes sense to have
dedicated "DispVM template" AppVMs (as currently fedora-xx-dvm).

Since DispVM support will be basically rewritten from scratch, we may
change some things if there is need for it. Below is some non-exhaustive
list of things for consideration:

### 1. How to choose which DispVM should be used?

For DispVM started directly from dom0 it should be easy - we may simply
have some command line option for that (like: qvm-run --dispvm fedora-23-dvm).
But how about DispVM started from another VM (opening some document,
link etc)?
I think the most straightforward solution would be to have another VM
property: which DispVM should be used for calls from this VM (simply
called "dispVM"). But maybe there are other ideas? For example does it
make sense (and when?) to use different DispVM depending on what
file/action is opened? Should it be controlled by calling VM? If so,
should a VM be able to launch any DispVM, or only selected one (based on
some setting and/or qrexec policy)?

### 2. What should be properties of created DispVM?

Currently new DispVM inherit some properties from calling VM. Those
properties are:
- label
- netvm (based on dispvm_netvm property from calling VM)
- firewall rules

Does it make sense to extend/shrink this set?

The main idea behind inheriting network related properties is to prevent
leaks from infected documents when opened in DispVM. This is especially
important when using VMs behind Tor - you don't want to give clearnet
access to (potentially compromised) PDF viewer, when opening some
document downloaded anonymously over Tor, because that would leak your
real IP address.

While having multiple DispVM templates will make it possible to highly
customized them (for example have one for each network connection), but
I think in practice it doesn't scale well.


### 3. Do we need multiple ways to start DispVM?

(somehow connected to previous questions)
This has been raised in the past that it would be useful to be able to
start networked DispVM or non-networked DispVM. For example open
documents (run pdf converter etc) in non-networked DispVMs, but open
links in networked DispVMs.
Do we need anything else? Or maybe such cases can be solved by using
different DispVM templates?



In all the above cases, please provide concrete use cases and keep the
discussion on topic. While technically many options are possible, we
want to have the design as simple as possible. To easily (and properly)
implement it. But also to be easy to comprehend by the users (and future
developers). So anything that requires complex flow chart to follow is
no-go.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXNFdmAAoJENuP0xzK19csBwkH/2sA/LSU4VpRxUkfaordgSBR
gVcrHXJuCEpZlbVWTukm728Hn1BnmcosRBKrnxFp9e2QBiaSO0O6eNYTg9bgtOaX
TCR++yI1hUxstYl3K2ufuXH76IdEU36Gxke36ScUHqIrR2mBl8H7UUozOrsAkUrS
vfApKHK8r+VOVvN0UlAABj2zH1oskXBH+IeQHgl0EOEoRtrtEiAAA42WgtPLD97F
BJ0ZqqT8s1uswKSCqjROqRsypFlmbIrYFsbqq5rKy6K67h/MV5NEeNubBzXbym87
L4YLlPFOTHbWgaGB+NkdyNQiZxj3zr2c5OsnE7tJ+Vycc8MVktlyA2garYa7yTI=
=iZBA
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-05-12 03:13, Marek Marczykowski-Górecki wrote:
> Hi all,
>
> In Qubes 4.0 we're going to (finally!) implement support for
> multiple DispVM templates:
> https://github.com/QubesOS/qubes-issues/issues/866
>

Woohoo!

> In principle it will be possible to start an AppVM in "disposable"

> mode - which means changes to its private image (in addition to

> root image as in normal AppVM) will be discarded after VM shutdown.
> Technically any AppVM can be used for that, but practically it
> makes sense to have dedicated "DispVM template" AppVMs (as
> currently fedora-xx-dvm).
>

How will the risk of data loss/leaks be handled? RPC policy rules?

For example, I probably never want it to be possible for my
mission-critical-data-vm to be launched as a DispVM, because if I
forget to export a file before closing the DispVM (or accidentally
close the original DispVM window), I'm toast.

Likewise, I probably never want it to be possible for my
super-secret-data-vm to be started as a DispVM with a NetVM other than
"none."

> Since DispVM support will be basically rewritten from scratch, we
> may change some things if there is need for it. Below is some
> non-exhaustive list of things for consideration:
>
> ### 1. How to choose which DispVM should be used?
>
> For DispVM started directly from dom0 it should be easy - we may
> simply have some command line option for that (like: qvm-run
> --dispvm fedora-23-dvm). But how about DispVM started from another
> VM (opening some document, link etc)? I think the most
> straightforward solution would be to have another VM property:
> which DispVM should be used for calls from this VM (simply called
> "dispVM").

Perhaps we should try to avoid replicating the situation in which
"NetVM" takes on three different meanings. :)

> But maybe there are other ideas? For example does it make sense
> (and when?) to use different DispVM depending on what file/action
> is opened? Should it be controlled by calling VM? If so, should a
> VM be able to launch any DispVM, or only selected one (based on
> some setting and/or qrexec policy)?
>
> ### 2. What should be properties of created DispVM?
>
> Currently new DispVM inherit some properties from calling VM.
> Those properties are: - label - netvm (based on dispvm_netvm
> property from calling VM) - firewall rules
>
> Does it make sense to extend/shrink this set?
>

Personally, I'm a fan of having no NetVM as the default, mainly for
the reasons indicated here:

https://github.com/QubesOS/qubes-issues/issues/1988

I'm also a fan of allowing for not inheriting firewall rules, for the
use case described here:

https://groups.google.com/d/topic/qubes-users/ZsHL3ASYUHU/discussion

> [...]

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXNGYwAAoJENtN07w5UDAwJ8QP/ijilH3pxNuO+3Wb4l+i4bFG
/Mrj4ozeW5nngx+Jak0ltuBKBlBNW9AeM0+og1h9cUcsU4ePHN+S+ckLRs/BUJwp
qLoH+aBVJlm1k687vvrNviF6WTgCfjYWkiq+UwQiNUPQFd6eTp0V9yzSIJzv/jdM
HGCBlbZMlfGdj6W2ZqiNT+lRv7CsYnau+0WRSnReD6To69qGz/jlYaNiPhj2lk6s
yqNSv5Jxqb+4FMfAgOqe9sMP6uONqm5/2JHSto2Bc8PU/OLl8OpHaNsj0g95haKC
GpMuhZcyUG0RaHAqKi3853bbW16L69mnsKiIPHsE3wHXaEuQiA25lYViXDRdVHTR
vbOEcRxBobmynuC50aYchV1lWniWOCuwyU9RGkTHlsWLmFa8Nmt8uo2APpSx/2Fw
TX7K9tgLOdoDWi07ioBBBvlcTGePf+pGaG1BNpYz5TrLeepsWfwPgRjiC5HUozXx
LjGpRQC9FU000Spz0SfFhV+G8Emh2NaRmEE5yvjkFU7hdc254lrhRqr7Mamc01Kp
iNm3Q23VzASosZOESYUT92DT0jxDIZx9iTWGfRTTIx2TqC4C+wVw6TPSf9kLqiby
QBUFic0x/nEGXtcOqNWUrHb/grdHYjul3C7LIzoJlQeBR77UybyRUvKfafeC9ZPG
ea0ixnyeThke5zMem+Mu
=TrLI
-----END PGP SIGNATURE-----

[Chris Laprise]

1. Probably the most manageable way is to have a boolean property for
templatevms like 'Use local dispvm based on this template'. Then there
is potentially just one dispvm per template. The default template would
have this property always set, and other templates could be either 'on'
or 'off'.

Other templates would have the property default to 'off', which means
that derivative vms are using the 'global' dispvm derived from the
default template until a user or admin changes this property in a given
template.

For example, if I have template vms A, B and C with A the system
default, then by default all vms will use a default dispvm generated
from template A. Assuming I have appvms Aardvark, Bonobo and Cat
(derived from templates A, B and C respectively) and turn on the 'Use
local dispvm' property for template B, then the Bonobo appvm (and any
other appvms dependent on B) will begin using a dispvm derived from B
instead of A.

This arrangement has several advantages over a free-form assignment of
dispvms to appvms:

A. It keeps the amount of time waiting for dispvms to regenerate
down to the same level we currently see, unless someone takes steps
to change the settings.

B. It also helps reduce confusion, because there are two very simple
possibilities for a dispvm spawned by an appvm: One from the default
template, or one from the appvm's own template.

C. Dependency resolution while maintaining vms or restoring from
backup is straightforward, requiring no additional user input.

Overall, I think this strikes a good balance between flexibility and
complexity.

2. Just a bit more flexibility is called-for with networking... Allow
the user to choose 'no networking' for dispvms, or make this the default
_for_appvm_launched_dispvms_ and let users enable networking if they wish.

3. This is partly answered by my response in #2. I would prefer having
dispvms launched from dom0 launcher to have networking, and dispvms
spawned from appvms to not have it by default. There should also be a
dom0 CLI utility to launch dispvms with a switch to disable networking.

Chris

[Marek Marczykowski-Górecki]

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

On Thu, May 12, 2016 at 04:17:06AM -0700, Andrew David Wong wrote:
> On 2016-05-12 03:13, Marek Marczykowski-Górecki wrote:
> > In principle it will be possible to start an AppVM in "disposable"
> > mode - which means changes to its private image (in addition to
> > root image as in normal AppVM) will be discarded after VM shutdown.
> > Technically any AppVM can be used for that, but practically it
> > makes sense to have dedicated "DispVM template" AppVMs (as
> > currently fedora-xx-dvm).
> >
>
> How will the risk of data loss/leaks be handled? RPC policy rules?
>
> For example, I probably never want it to be possible for my
> mission-critical-data-vm to be launched as a DispVM, because if I
> forget to export a file before closing the DispVM (or accidentally
> close the original DispVM window), I'm toast.
>
> Likewise, I probably never want it to be possible for my
> super-secret-data-vm to be started as a DispVM with a NetVM other than
> "none."

Yes, that should be done by either RPC policy rules, or having a
property like "allow this VM to be started as DispVM".

> > Since DispVM support will be basically rewritten from scratch, we
> > may change some things if there is need for it. Below is some
> > non-exhaustive list of things for consideration:
> >
> > ### 1. How to choose which DispVM should be used?
> >
> > For DispVM started directly from dom0 it should be easy - we may
> > simply have some command line option for that (like: qvm-run
> > --dispvm fedora-23-dvm). But how about DispVM started from another
> > VM (opening some document, link etc)? I think the most
> > straightforward solution would be to have another VM property:
> > which DispVM should be used for calls from this VM (simply called
> > "dispVM").
>
> Perhaps we should try to avoid replicating the situation in which
> "NetVM" takes on three different meanings. :)

Yeah, any better idea for such property name?

> > But maybe there are other ideas? For example does it make sense
> > (and when?) to use different DispVM depending on what file/action
> > is opened? Should it be controlled by calling VM? If so, should a
> > VM be able to launch any DispVM, or only selected one (based on
> > some setting and/or qrexec policy)?
> >
> > ### 2. What should be properties of created DispVM?
> >
> > Currently new DispVM inherit some properties from calling VM.
> > Those properties are: - label - netvm (based on dispvm_netvm
> > property from calling VM) - firewall rules
> >
> > Does it make sense to extend/shrink this set?
> >
>
> Personally, I'm a fan of having no NetVM as the default, mainly for
> the reasons indicated here:
>
> https://github.com/QubesOS/qubes-issues/issues/1988
>
> I'm also a fan of allowing for not inheriting firewall rules, for the
> use case described here:
>
> https://groups.google.com/d/topic/qubes-users/ZsHL3ASYUHU/discussion

I think we should differentiate two use cases here:
- open a file
- open a link

Which is somehow along the lines of this:
https://github.com/QubesOS/qubes-issues/issues/1487

Then opening a file should be in non-networked DispVM by default, but
opening a link in networked one (with the current rules for network
connection?). Not sure about firewall rules, but if opening a file would
be in network-isolated DispVM by default, it shouldn't matter anymore.

There are some use cases when you want to open a file in networked
DispVM, for example:
- a document which will indeed need to communicate with some network
service (like downloading images, or interactive PDF form with
built-in "send" functionality)
- printing a file

How to handle those? One more qrexec service (and context menu item)?
That would make even more complex UI...

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXNQ6aAAoJENuP0xzK19csFIEH/3XPLmQrmjgVIsq2jTAMLqC5
QZrkLeCD7Aiel47rNPcW573aKW7cmE55Pns1JFLwk/KJhpQHPNpimDp8NBuUf4+C
9qFAk7hWGKZQ96KeRDOyKMi0u4sYpOkDdMiVXmNKfMsPUX6VwX26FkxumakRYt8q
uqRmmP0XBCQJVLepFwBzW5NwRKnA6n2dj/as2X++/2vcd85PYU6jwUCu+zS7I5qn
ZArvZd0GccuMxofQsGXcx5I13gvmP8Dvj6DIXeh+LCVXHUOFXo0cFAp2BMEsTDUo
83ZYO7WljXg9QxwVLv9l8SqVTBPjSCDuFYymo7bNEW4+qorFeR+abVVegz7pIhw=
=jYdE
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

This is nice idea, but not sure if not too strict. This excludes ability
to create different DispVMs based on the same template. But maybe indeed
it is such advanced, niche functionality that don't worth having easily
accessible option.

On the other hand, there is quite valid use case for using Whonix-based
DispVMs even when opening files/links from non-Whonix based VMs. How to
handle this? Have Whonix-based DispVM set as global default?

> 2. Just a bit more flexibility is called-for with networking... Allow the
> user to choose 'no networking' for dispvms, or make this the default
> _for_appvm_launched_dispvms_ and let users enable networking if they wish.
>
> 3. This is partly answered by my response in #2. I would prefer having
> dispvms launched from dom0 launcher to have networking, and dispvms spawned
> from appvms to not have it by default. There should also be a dom0 CLI
> utility to launch dispvms with a switch to disable networking.

Take a look at my other response about file/link distinction.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXNRC3AAoJENuP0xzK19cs8owIAID+PUoHvWqlyPz/fn2w65or
oKNZFAxcgLBIWLP4hiDAWw3qNusr22YmDLoBe2zAeVXJ3cRFtSWF5gdlAPLYyhpO
jSGXS8WV/+yt5+kiSTH0Z6L5vn0F3z9+jc7EJ4OWRGBGtZFJN2cMp1KghiyICi8R
Le85ODiVgdgQYiHq9AT+VvUEZFTa+M07OmkJW/hq19pomtoA8y19FoNHginAzIa4
w3/5mLHUwP11/Zl2mm9JQn0KgRAJZvg2bxbLQBqVV0gku/Pp9atfBkIT/W5qGIla
r/3bApF15ZxPKeMRrVjU6CUeOVtKqJWUI3EJPC5VUqw72F+faj4rar/GWGEvprg=
=ev38
-----END PGP SIGNATURE-----

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-05-12 16:15, Marek Marczykowski-Górecki wrote:
> On Thu, May 12, 2016 at 04:17:06AM -0700, Andrew David Wong wrote:
>> On 2016-05-12 03:13, Marek Marczykowski-Górecki wrote:
>>> In principle it will be possible to start an AppVM in
>>> "disposable" mode - which means changes to its private image
>>> (in addition to root image as in normal AppVM) will be
>>> discarded after VM shutdown. Technically any AppVM can be used
>>> for that, but practically it makes sense to have dedicated
>>> "DispVM template" AppVMs (as currently fedora-xx-dvm).
>>>
>
>> How will the risk of data loss/leaks be handled? RPC policy
>> rules?
>
>> For example, I probably never want it to be possible for my
>> mission-critical-data-vm to be launched as a DispVM, because if I
>> forget to export a file before closing the DispVM (or
>> accidentally close the original DispVM window), I'm toast.
>
>> Likewise, I probably never want it to be possible for my
>> super-secret-data-vm to be started as a DispVM with a NetVM
>> other than "none."
>
> Yes, that should be done by either RPC policy rules, or having a
> property like "allow this VM to be started as DispVM".
>

Ok, sounds good.

>>> Since DispVM support will be basically rewritten from scratch,
>>> we may change some things if there is need for it. Below is
>>> some non-exhaustive list of things for consideration:
>>>
>>> ### 1. How to choose which DispVM should be used?
>>>
>>> For DispVM started directly from dom0 it should be easy - we
>>> may simply have some command line option for that (like:
>>> qvm-run --dispvm fedora-23-dvm). But how about DispVM started
>>> from another VM (opening some document, link etc)? I think the
>>> most straightforward solution would be to have another VM
>>> property: which DispVM should be used for calls from this VM
>>> (simply called "dispVM").
>
>> Perhaps we should try to avoid replicating the situation in which
>> "NetVM" takes on three different meanings. :)
>
> Yeah, any better idea for such property name?
>

This would be one of the properties set/listed by qvm-prefs, right?

I see that we already have "dispvm_netvm", so how about something like
"dispvm_target"?

Right. 99% of the time, if I (intentionally) click on a link in an
email, I want it to be opened in an untrusted networked (Disp)VM with
firewall rules that allow me to load the website.

(Someone might ask: "What about trusted links?" Sure, your bank sends
you emails with links in them, but we shouldn't encourage or train
users to rely on those links as a way to get to their actual bank's
website. Qubes has better solutions for that, like having a dedicated
banking VM where you have your bank's website bookmarked in that VM's
browser.)

> There are some use cases when you want to open a file in networked
> DispVM, for example: - a document which will indeed need to
> communicate with some network service (like downloading images, or
> interactive PDF form with built-in "send" functionality) -
> printing a file
>
> How to handle those? One more qrexec service (and context menu
> item)? That would make even more complex UI...
>

We already have a drop-down menu, a button, and a right-click context
menu for attachments in Thunderbird (with the Qubes Attachments
extension). We could add menu options for opening attachments in
different DispVMs with commonly-used presets and user-definable
entries. For example:

Open in DispVM
=>Open in online DispVM
=>Open in offline DispVM
=>Open in printer DispVM
=>Open in PDF DispVM

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXNT+OAAoJENtN07w5UDAwLfgP/005dXctZtD75yZ+UA+BuEvh
COX/jk/FaIuaAEbhXn4YrshLjMfGsLwkVk39FjkAG4UQsALQxmmMV7xRMCuCmM1h
oXeh81BG/XQ+PSQSver3QvQj/OcJcbrOc9vU8z6XuvwSl6pwNeJ7uFO+RGFl9SAu
oHyJTW3kHThyhiyp+Glc/vDIy5ZNyVY1Z+SyBUychWs1VP6PSFE1bgwKYMK4UP0c
gId98UpAwjbXG9yEr+Eu6T98suscS2kqzLn6MGFxK4yGHNU7chfyE38b/IbJrl6t
01ZCuMfTTr5BwncvdGwXiiEC1TVCT47RPKprwPYdJMT3E9fkUNGsJkmx1Pzcvyhc
qxNu7Oonlj0XxFXSmbAph1eMxGZhQRebc4M+TYHskav3olKCJcHbrkjL9ru53iby
HRwjU3Z0b7YQwJVBzRmxg9pSAwZVe6wHGTWfrN/aRxb222+K0VQjNf68H6tGqkIi
9P7lTVMxBwdLnZKmByRgbMomitNKF5QLL6vJXfRfhFUkus6pHplbvZJo0Yb6Rlf1
Czj/mfRqXC7AtGl0QK0WUPO1h+b/lKx0JZnUiDmH6k0Rw6yb7Y0vE2IiysA+aaE0
Tfd9sYFXW+BH227i/eDZu4ZbLGtJspRU4YShqrlbWlEbTQpdXbZeklqhk1ChEKYx
9aahPzngkWd+Qh9LG77S
=okC7
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

Yes.

> I see that we already have "dispvm_netvm", so how about something like
> "dispvm_target"?

Maybe... or dispvm_base?

Exactly.

> > There are some use cases when you want to open a file in networked
> > DispVM, for example: - a document which will indeed need to
> > communicate with some network service (like downloading images, or
> > interactive PDF form with built-in "send" functionality) -
> > printing a file
> >
> > How to handle those? One more qrexec service (and context menu
> > item)? That would make even more complex UI...
> >
>
> We already have a drop-down menu, a button, and a right-click context
> menu for attachments in Thunderbird (with the Qubes Attachments
> extension). We could add menu options for opening attachments in
> different DispVMs with commonly-used presets and user-definable
> entries. For example:
>
> Open in DispVM
> =>Open in online DispVM
> =>Open in offline DispVM
> =>Open in printer DispVM
> =>Open in PDF DispVM

One more click... And I guess it may be too much for average user - not
only to choose which files open in DispVM instead of in that VM
directly, but now to choose which DispVM flavor. Every time.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXNeIiAAoJENuP0xzK19csyvgH/0w6T9TYGhIykTvW07Acy77q
5qFAHPrpDnToGgkA9JzaQ/bYXAXBQfZ3tLnK+A7IHZ9tmBR2KBd5oiU8OBExxjJy
rpfLLfcRbHZOORHH3GbtO9ebdCt/Lm1G5iEIRXCDCm01XZYFrzi+REMZRV2NzmzO
6P+QwhQFvax0c/kdhF/1qXVmnxNgVE1RjLSRA6xLr8mj9xN/+dG3gto8BWkpUw1j
kTh9/KPBZkr6e0+mo4/DqA1SPmbyl4J+3L1kwpHv59A3eSd//MnCzegIX1q7xWzd
NZQJKGJU2pN42Uf4HLgOMFttjqXjg3UHXoR5aTzP3aMBxxlPV8fWI6lMbJjYIGc=
=fVNq
-----END PGP SIGNATURE-----

[Andrew Clausen]

Hi Marek et al,

On 13 May 2016 at 15:18, Marek Marczykowski-Górecki

<marm...@invisiblethingslab.com> wrote:
>> > How to handle those? One more qrexec service (and context menu
>> > item)? That would make even more complex UI...
>> >
>>
>> We already have a drop-down menu, a button, and a right-click context
>> menu for attachments in Thunderbird (with the Qubes Attachments
>> extension). We could add menu options for opening attachments in
>> different DispVMs with commonly-used presets and user-definable
>> entries. For example:
>>
>> Open in DispVM
>> =>Open in online DispVM
>> =>Open in offline DispVM
>> =>Open in printer DispVM
>> =>Open in PDF DispVM
>
> One more click... And I guess it may be too much for average user - not
> only to choose which files open in DispVM instead of in that VM
> directly, but now to choose which DispVM flavor. Every time.

I expect a simple UI can make this quite easy:

(1) It doesn't make sense to open links in offline VMs, or PDFs in
online VMs. Can't some simple rules cut down the number of choices?

(2) If there are only one or two relevant choices (e.g. printer vs
offline VM for a PDF), then you wouldn't need a nested menu, you could
just include two items:

Open in offline DispVM
Open in printer DispVM

(3) Another possibility is to have a default VM for each use case
(e.g. offline VM for a PDF), and allow the user to either go with the
default or choose manually:

Open in offline DispVM
Open in another VM...

Kind regards,
Andrew

[Chris Laprise]

I doubt that Tor really matters for documents. Q: Interactive documents?
A: Unsupported fringe case. They can be manually accommodated with some
file copying.

As for the possibility of doing it the complex way, this has the
potential to make parts of the Qubes UI really confusing. At the very
least the options would need to be tucked away under an Advanced button
or everything dispvm-related moved to its own settings tab. Then there
is added complexity for Launcher, etc.

>> 2. Just a bit more flexibility is called-for with networking... Allow the
>> user to choose 'no networking' for dispvms, or make this the default
>> _for_appvm_launched_dispvms_ and let users enable networking if they wish.
>>
>> 3. This is partly answered by my response in #2. I would prefer having
>> dispvms launched from dom0 launcher to have networking, and dispvms spawned
>> from appvms to not have it by default. There should also be a dom0 CLI
>> utility to launch dispvms with a switch to disable networking.
> Take a look at my other response about file/link distinction.

I recall the distinction from a past discussion, and my own thinking is
(like #1) to keep the functionality effective but simple... WWAD (What
Would Apple Do)? Since you are already adding a complex feature, the
added implementation details should be very simple at first.
Distinguishing between a file and a link (isolated vs networked) is as
far as I would go for now.

Printing is an interesting case, but the paper-bound office is still on
the decline. You can try to address it with the dispvm concept and still
not be able to provide actual connection to printing services (which
will become glaringly obvious as soon as you try to implement any
automation for printing).

I'm beginning to think the best practice here is to encourage people to
create LAN vms (i.e. LAN-home, LAN-work, etc) since printers, routers,
and scanners (maybe even lightbulbs, thermostats and security cameras)
have a similar insecurity profile. A 'QubesOutgoing' folder can even be
utilized so that users can print-to-PDF into it, and if that appvm is
set to have permission then automatically shuffle it to the LAN vm for
printing.

Those are my thoughts.

Chris

[Patrick Schleizer]

Andrew David Wong:

>> Open in DispVM
>> > =>Open in online DispVM
>> > =>Open in offline DispVM
>> > =>Open in printer DispVM
>> > =>Open in PDF DispVM

I like that idea a bit. What about 'edit file' vs 'open file'?

Related ticket:
'edits in DispVM are saved, counter to user expectations'
https://github.com/QubesOS/qubes-issues/issues/1118

Marek Marczykowski-Górecki:

> One more click... And I guess it may be too much for average user - not
> only to choose which files open in DispVM instead of in that VM
> directly, but now to choose which DispVM flavor. Every time.

I also agree.

Cheers,
Patrick

[Chris Laprise]

Besides the obvious worries of letting a domU internally select other
vms and vm features, I find this loading-up of menus and very specific
vms to be rather baroque.

As I mentioned below, a LAN services vm - playing a similar role to
sys-usb - could handle printing, scanning, NAS, etc. Once that is
established, treat it like the microphone.... Right-click on your appvm
and select an option to allow forwarding print jobs to the LAN vm. Even
general network access for the dispvm could be handled this way.

Chris

[Joanna Rutkowska]

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

I can see it useful for the DispVM template to be dependent on the (srcvm,
qrexec_service) tuple. E.g. I might want to open most files in a Linux-based
(Disp)VM, but for MS Office files I might want to have a special service
(qubes.OpenMsOffileFile) that would open it in a Windows-based one.

It's important that the type of the VM was enforced by the global policy, not by
the srcvm. E.g. I might _not_ want my anonymous VM to be able to start my
Windows-based (Disp)VM and learn the product key. E.g.:

cat qubes.OpenFile
anon @dispwin7 deny
$anyvm $dispvm allow

cat qubes.openMsOfficeFile
work-email @dispwin7 allow

The '@dispvm' represents a disposable VM created from the 'dispvm' template (see
[1]). For compatibility reasons we might alias $dispvm -> @(default_dist_vm).

So, I'm leaning towards changing the syntax for qrexec-client-vm (the tool we
invoke in the srcvm) to the following:

qrexec-client-vm RPC_ACTION_NAME[+ARGUMENT]

For services where the RPC precisely defines the destvm, this would be handled
according to the policy, e.g:

cat qubes.Gpg
work-email keys-itl-email allow

And for those services where the policy doesn't specify the target VM explicitly
(i.e. the 2nd argument is $anyvm, or more broadly speaking cannot be evaluated
into the specific VM in the system, which might be the case when we introduce
tags in Qubes 4), such as e.g.:

cat qubes.FileCopy
$anyvm $anyvm allow

...we would have the Dom0's qubes-rpc-multiplexer to popup a window asking
the user to provide the target VM manually (something the user is required to do
anyway for such services, only that presently the VM-side script is asking for
the target VM). For compatibilily we can allow the qrexec-client-vm to take the
targetvm argument and just ignore it (or provide as a "hint" to the Dom0-asking
program maybe?)

Generally, as discussed many times already, we should work towards having all
the inter-VM, as well as the VM-world interactions, including the networking
policy (firewall), all to be controllable by the global (qrexec) policy. These
should not be hard-coded into the qrexec mechanism.

The recent introduction of "the policy argument" [2] should make this now
possible. E.g. the networking - at some point can be replaced with
qubes.{Ip,Tcp,Udp} services. Although, I think, especially in case of
networking, we should also add a way to enforce the argument by the policy for
service requests which otherwise don't specify arguments, e.g I would like to be
able to state:

cat qubes.Tcp
work-email $netvm allow smtp.itl.com:25,imap.itl.com:993
anon whonix-gw allow # Don't allow networking through other netvms
whonix-gw $netvm allow *:https # Mostly to catch incidental bugs
@dispvm $netvm deny # 'dispvm'-based DispVMs cannot do TCP by default
$anyvm $netvm allow

cat qubes.Udp
vpn-gw $netvm allow gate.itl.com:1194 # Mostly to catch config errors
@dispvm $netvm deny # 'dispvm'-based DispVMs cannot do UDB by default
$anyvm $netvm allow

Where the '$netvm' represents the actual netvm to which the srcvm is connected
to (i.e the netvm should remain a property of the srcvm).

The above examples also suggest that DispVMs should not be implicitly inheriting
any policies from the srcvm, like it is currently the case with firewall
configuration. I think this is a cleaner approach. Although there is some
potential problem -- e.g. I might want most of the DispVMs to be offline, except
the one for opening URLs from my email domain. So I would like to say something
like:

cat qubes.Tcp
$dispvm deny
$dispvm.srcvm=work-email allow *:https # Admittedly syntax a bit clumsy...

Such central configuration of all the VM interactions from within the Qubes
policy, combined with our management framework, should make it much easier to
offer default preconfigured configurations, hopefully making it harder for
users to shoot themselves into their foot.

BTW, I think it might be useful to also provide some kind of a policy evaluation
tool, or some kind of a "simulator", to let the admins test the policies. One
example of a policy evaluation tool might be a graphing tool (based on dot) for
drawing all the allowed RPC invocations between VMs. Am I not mistaken that it
should work in O(M*N^2) time, where M is the number of files in
/etc/qubes-rpc/policy, and N is the no of VMs in the system?

The remaining questions are how to determine the DispVM's 1) label and 2) netvm?
I don't have a strong opinion here, although I'm leaning towards having the
DispVM inherit the two from its template.

joanna.

[1] https://groups.google.com/forum/#!topic/qubes-devel/uQJL7I70GQs
[2] https://www.qubes-os.org/doc/qrexec3/
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXOaE9AAoJEDOT2L8N3GcY5KAQALWTuMwAaBN7ZJaMwDvm9Cm4
6WgM6r7ghEOOw4nV1ufm/cbiqK/PFEoaYs1k0SxIDoGU5mXjAdUulcFAkNlQDr50
aq7hAko2mVWHjiSW8ohmuFQN0b/uI9eVzgMaMF8CBQmX17AbGg1oKFNykKihv/1W
hI1aBEVKHBlOpaA2E9rCOfC7EXwTA9UVEXU9KbCbkKiD+GYcg7gStZ0WSj3KQnJB
433z4jR3lt14eM+qBZLsF0NcMez0fvKBApD1zFECy/nt850EkxIBhGCcG8BrPLmm
gzsoIEqNZIqQO+fkR5pur/o8IVHWj3BMJOPABHnKgBlL3MkcJzrrgaEbjnswmO3G
hBoPbGPFeQCJaQTVl+VPh50p/iVU/wPEVZrd85bR65OzMQt3wZuNVgPNCfKTf0+S
XaTclFMg48Tf0UXezmcumhenYUDgP8ZtGucrdEPN0Hrdz7/Tg6cM8gXWBEJ6SD/x
SoqVlF96bUBxwQT6VQ5qAn99X4c+IO63Iwu0bJSTQfa67bUNOVx2Ir/N6HBoo/6W
d89h/7pMRk22WA37HgnYr6zs04lEXknISOB7heGFaWeAzyW+zWKTiF4xo77BF64a
uqYpT4o/qBFI5ZX8SKJ6479HweXktwc0MMBRJzYPm9EndJ9tvQU1P3ZYsDrg3eZC
2F7FLzkPoRlX//lPKPMy
=fwjC
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

I'd rather avoid another magic character here and use something more
descriptive. Like "$dispvm:dispvm" (for example: "$dispvm:fedora-23-dvm").
Then "$dispvm" would mean "default DispVM", not "any DispVM".

But, how would you decide what service should be called? I.e. when to
use qubes.openMsOfficeFile instead of qubes.OpenFile? Using some mime
handlers in the calling VM?

> So, I'm leaning towards changing the syntax for qrexec-client-vm (the tool we
> invoke in the srcvm) to the following:
>
> qrexec-client-vm RPC_ACTION_NAME[+ARGUMENT]

This is very similar to what is discussed here:
https://github.com/QubesOS/qubes-issues/issues/910

But I wouldn't remove target VM name from here. Simply pass empty string
('') as "lets dom0 decide". See below.

> For services where the RPC precisely defines the destvm, this would be handled
> according to the policy, e.g:
>
> cat qubes.Gpg
> work-email keys-itl-email allow
>
> And for those services where the policy doesn't specify the target VM explicitly
> (i.e. the 2nd argument is $anyvm, or more broadly speaking cannot be evaluated
> into the specific VM in the system, which might be the case when we introduce
> tags in Qubes 4), such as e.g.:
>
> cat qubes.FileCopy
> $anyvm $anyvm allow
>
> ...we would have the Dom0's qubes-rpc-multiplexer to popup a window asking

s/qubes-rpc-multiplexer/qrexec-policy/

> the user to provide the target VM manually (something the user is required to do
> anyway for such services, only that presently the VM-side script is asking for
> the target VM). For compatibilily we can allow the qrexec-client-vm to take the
> targetvm argument and just ignore it (or provide as a "hint" to the Dom0-asking
> program maybe?)

I'd not remove an option to specify target VM name by calling party.
There are multiple cases when it makes sense. For example you can have
policy like this:

cat qubes.Gpg
devel keys-devel allow
release keys-devel allow
release keys-release allow

In other words: allow devel VM to access devel keys, but release VM to
allow both devel and release keys. Then have different target domain set
in different places (here: keys-devel for git and keys-release for rpm).
Asking for target VM in such a case (even with properly set default)
will be a huge UX regression...

But in case of not specified target domain, if the policy is
unambiguous, that could be used directly. If not - ask for target VM in
dom0. Probably using policy as a hint - for example:

cat qubes.FileCopy
work work-email ask
work work-web ask
work work-vault ask

Then the target VM prompt should list just those three VMs, with
'work-email' being the first one (default).

> Generally, as discussed many times already, we should work towards having all
> the inter-VM, as well as the VM-world interactions, including the networking
> policy (firewall), all to be controllable by the global (qrexec) policy. These
> should not be hard-coded into the qrexec mechanism.
>
> The recent introduction of "the policy argument" [2] should make this now
> possible. E.g. the networking - at some point can be replaced with
> qubes.{Ip,Tcp,Udp} services. Although, I think, especially in case of
> networking, we should also add a way to enforce the argument by the policy for
> service requests which otherwise don't specify arguments, e.g I would like to be
> able to state:
>
> cat qubes.Tcp
> work-email $netvm allow smtp.itl.com:25,imap.itl.com:993
> anon whonix-gw allow # Don't allow networking through other netvms
> whonix-gw $netvm allow *:https # Mostly to catch incidental bugs
> @dispvm $netvm deny # 'dispvm'-based DispVMs cannot do TCP by default
> $anyvm $netvm allow

So here, the argument means "all the firewall rules, to be evaluated by
the service", not "connection target". So in this case (part of) actual
policy would be enforced by the service itself, not dom0 policy
mechanism. This is something different than policy argument was designed
for.
Also it isn't exactly what you wanted: you've written "for service
requests which otherwise don't specify arguments", but in fact you
wanted to "override regardless of argument specified by the caller".
Otherwise the called may specify its own policy, like "*:*"...

There is a also another problem with such approach - having complex argument
(like full network policy) in a single string may be hard to manage and
very error-prone. Also, currently we filter argument from almost any
non-alphanumeric characters, to ease secure service implementation (not
to worry about shell special chars, path traversal etc). If we want to
put full firewall into service argument, that would be tricky (for
example '/' and '*' are not allowed, so 1.2.3.0/24:* would not be
possible).

Maybe better, for readability, would be to use argument as target
host:port? But then it would be even harder to specify policy like
"allow *:https", because in current approach we can either allow or deny
_specific_ argument, not some group of them based on some expression...

> cat qubes.Udp
> vpn-gw $netvm allow gate.itl.com:1194 # Mostly to catch config errors
> @dispvm $netvm deny # 'dispvm'-based DispVMs cannot do UDB by default
> $anyvm $netvm allow
>
> Where the '$netvm' represents the actual netvm to which the srcvm is connected
> to (i.e the netvm should remain a property of the srcvm).

Having '$netvm' which means different things depending on calling VM
may be misleading. I'd rather understand it as "system default NetVM".
Maybe "$srcvm:netvm"? Later we may introduce another options like this,
for example "$srcvm:gpgvm".

> The above examples also suggest that DispVMs should not be implicitly inheriting
> any policies from the srcvm, like it is currently the case with firewall
> configuration. I think this is a cleaner approach. Although there is some
> potential problem -- e.g. I might want most of the DispVMs to be offline, except
> the one for opening URLs from my email domain. So I would like to say something
> like:
>
> cat qubes.Tcp
> $dispvm deny
> $dispvm.srcvm=work-email allow *:https # Admittedly syntax a bit clumsy...

Maybe have a separate DispVM for that? Then the syntax would be clearer:

cat qubes.Tcp
$dispvm deny
$dispvm:my_web_dispvm allow *:https

cat qubes.OpenURL
work-email $dispvm:my_web_dispvm allow

Admittedly at the cost of having additional DispVM base VM to manage.

> Such central configuration of all the VM interactions from within the Qubes
> policy, combined with our management framework, should make it much easier to
> offer default preconfigured configurations, hopefully making it harder for
> users to shoot themselves into their foot.
>
> BTW, I think it might be useful to also provide some kind of a policy evaluation
> tool, or some kind of a "simulator", to let the admins test the policies. One
> example of a policy evaluation tool might be a graphing tool (based on dot) for
> drawing all the allowed RPC invocations between VMs. Am I not mistaken that it
> should work in O(M*N^2) time, where M is the number of files in
> /etc/qubes-rpc/policy, and N is the no of VMs in the system?
>
> The remaining questions are how to determine the DispVM's 1) label and 2) netvm?
> I don't have a strong opinion here, although I'm leaning towards having the
> DispVM inherit the two from its template.
>
> joanna.
>
> [1] https://groups.google.com/forum/#!topic/qubes-devel/uQJL7I70GQs
> [2] https://www.qubes-os.org/doc/qrexec3/

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXObW+AAoJENuP0xzK19cs6FUH/2TrB5fyCHOklGeLeghFhyTf
x1cr9ZJxDBb3uXfKEQ1+phB1RuABR02mPQOCVtqw0kD0XUV97MUUUhedPllymAqD
ItLu1nWcY1Z84Y1GJHYV604ImcEViM4SAiYFSGoo6yTfTIva/zbxPvflT52ohffT
xnugBkTvGWOPj+SXznPpLpliElryjMZ4O4Ad4ui1vsjClfQ0QwjTGGgmSwVzA2UF
R2ZsMcLNYEMaAHgv34PM9BBD7zIQDG5MsZnVq0UZJ8DD7aE0Iy8X1+o52ttuZAZ/
q2ZptBKVYKz1ks5n3qerbgdrTYXop7y76Dshj4Ir9ZIQWgS4HOMFgIs4zxe2qtY=
=8Qrd
-----END PGP SIGNATURE-----

[Manuel Amador (Rudd-O)]

On 05/16/2016 10:30 AM, Joanna Rutkowska wrote:
> On Thu, May 12, 2016 at 12:13:57PM +0200, Marek Marczykowski wrote:
> > Hi all,
>
> > In Qubes 4.0 we're going to (finally!) implement support for multiple
> > DispVM templates: https://github.com/QubesOS/qubes-issues/issues/866
>
> > In principle it will be possible to start an AppVM in "disposable" mode
> > - which means changes to its private image (in addition to root image as
> > in normal AppVM) will be discarded after VM shutdown. Technically any
> > AppVM can be used for that, but practically it makes sense to have
> > dedicated "DispVM template" AppVMs (as currently fedora-xx-dvm).
>
> > Since DispVM support will be basically rewritten from scratch, we may
> > change some things if there is need for it. Below is some non-exhaustive
> > list of things for consideration:

Careful, you may end up reimplementing a crappy version of capabilities.

I'm not just joking here. Half of it is a joke. The other half is
serious. Fundamentally, the problem to solve is as follows:

* User wants to perform an activity on a certain object or using certain
services
* User is controlling the source of that activity (a browser displaying
an untrusted link, or a file manager showing the icon of an untrusted file)
* User wants do use the source of that activity to initiate the
performance of that activity

This reeks from a mile away as something that could be well-served by
capabilities -- the user expresses to the source system "I want to
perform this activity X with object Y on a different domain Z which has
access to resources W, V, and U, and no more than that", and the source
system is in charge of making that request to its parent domain, which
is the actual original source of the capabilities -- the only thing that
can actually give permission to execute the activity X in the context
provided by the intersection of Y Z V W U. Of course, at this point,
the parent domain prompts the user for confirmation, and if the user
confirms (or policy deems it so), then BAM, the activity begins.

The complexity of the interaction, of course, can vary from anything
like "Right click on a file, select convert PDF to trusted PDF", to
"Right click on a file, select Print, display dialog selecting domain
that will do the printing, start domain with its own network settings"
to "Right click on a link, select Open in untrusted browser, display
dialog allowing the user to select a domain and its networking
properties, then start domain with the provided network settings".

But, of course, this quickly runs into the problem of the fact that the
source domain does not necessarily, or should not necessarily, know
certain properties necessary to display such a decision dialog box.
What business does my banking VM have, learning of network adapters /
NetVMs that exist in my system? None. But, for some reason, it also
seems "wrong" to put those policy UX elements in Dom0, and it also
requires a bit of a reinvention of the policy service to support such an
use case where in some cases it makes sense to ask the use to make a
policy decision, while in others it's brain dead obvious that asking the
user only causes a security problem (e.g. why does the user benefit from
selecting a NetVM when starting a PDF in an untrusted domain?).

We need to think about the use cases carefully before committing to the
code. It's easy to say, "this or that is just a fringe use", but more
often than not, that is something people tell themselves to avoid
considering how a robust implementation of said "fringe use" would work,
or what scary doors that implementation opens.

My two cents.

--
Rudd-O
http://rudd-o.com/

[Chris Laprise]

In addition to what I said about having a boolean choice between 'local'
and global dispvms, there could also be a global setting for the default
dispvm template (as separate from the default template setting). This
adds a lot of flexibility in a very simple way.

Furthermore, the question of anon functions can be addressed nicely if
we make dom0 aware of whether whonix/anon service is available in the
system. Then its a matter of adding just one more menu entry in the
applicable context menus. That means only TWO menu items (open in
dispvm, open in anon dispvm) if we assume the following:

1. The dom0 part of the framework understands whether the supplied
object is a link or a file.
2. Dom0 prompts the user to grant network access /if/ the object is a
link /and/ if its a normal dispvm (asking in the case of anon is pointless).
3. We allow the calling vm to request a non-networked dispvm in advance,
so as to avoid the possibility of unneeded prompts. This facilitates
file-oriented functions such as 'convert to trusted pdf'.

Chris

[Joanna Rutkowska]

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

Yes.

If anything should be used as a hint, it's the dstvm specified by the srcvm. The
policy should always have a priority over that.

> > Generally, as discussed many times already, we should work towards having all
> > the inter-VM, as well as the VM-world interactions, including the networking
> > policy (firewall), all to be controllable by the global (qrexec) policy. These
> > should not be hard-coded into the qrexec mechanism.
> >
> > The recent introduction of "the policy argument" [2] should make this now
> > possible. E.g. the networking - at some point can be replaced with
> > qubes.{Ip,Tcp,Udp} services. Although, I think, especially in case of
> > networking, we should also add a way to enforce the argument by the policy for
> > service requests which otherwise don't specify arguments, e.g I would like to be
> > able to state:
> >
> > cat qubes.Tcp
> > work-email $netvm allow smtp.itl.com:25,imap.itl.com:993
> > anon whonix-gw allow # Don't allow networking through other netvms
> > whonix-gw $netvm allow *:https # Mostly to catch incidental bugs
> > @dispvm $netvm deny # 'dispvm'-based DispVMs cannot do TCP by default
> > $anyvm $netvm allow
>
> So here, the argument means "all the firewall rules, to be evaluated by
> the service", not "connection target". So in this case (part of) actual
> policy would be enforced by the service itself, not dom0 policy
> mechanism. This is something different than policy argument was designed
> for.

Yes, all correct.

> Also it isn't exactly what you wanted: you've written "for service
> requests which otherwise don't specify arguments", but in fact you
> wanted to "override regardless of argument specified by the caller".
> Otherwise the called may specify its own policy, like "*:*"...

That's an irrelevant technicality, because we want the policy to always override
whatever specified the srcvm in case of any conflict.

>
> There is a also another problem with such approach - having complex argument
> (like full network policy) in a single string may be hard to manage and
> very error-prone. Also, currently we filter argument from almost any
> non-alphanumeric characters, to ease secure service implementation (not
> to worry about shell special chars, path traversal etc). If we want to
> put full firewall into service argument, that would be tricky (for
> example '/' and '*' are not allowed, so 1.2.3.0/24:* would not be
> possible).
>

Right, and we have been having this discussion for at least a year now :)

I think the dom0 should _not_ do any parsing of the argument, just treat it as
an opaque string and pass to the target vm's service. It might do some
sanitization, that's ok. If '*' and '/' (understendably) should be sanitized out
(b/c of the other way to specify the argument, i.e. in the policy file after the
'+ sign), then we should pick some others.

> Maybe better, for readability, would be to use argument as target
> host:port? But then it would be even harder to specify policy like
> "allow *:https", because in current approach we can either allow or deny
> _specific_ argument, not some group of them based on some expression...
>

See above.

> > cat qubes.Udp
> > vpn-gw $netvm allow gate.itl.com:1194 # Mostly to catch config errors
> > @dispvm $netvm deny # 'dispvm'-based DispVMs cannot do UDB by default
> > $anyvm $netvm allow
> >
> > Where the '$netvm' represents the actual netvm to which the srcvm is connected
> > to (i.e the netvm should remain a property of the srcvm).
>
> Having '$netvm' which means different things depending on calling VM
> may be misleading. I'd rather understand it as "system default NetVM".
> Maybe "$srcvm:netvm"? Later we may introduce another options like this,
> for example "$srcvm:gpgvm".
>

I'm not terribly against that syntax, just would like to note the fundamental
difference between the netvm and what you described as gpgvm -- the former is a
property of the VM, while the latter is just (one of the possible) dest VMs for
some qrexec service request. Although... if we moved to qrexec-based networking,
as I described above -- which I doubt we would do anytime soon, because of the
fundamental disagreement about the argument parsing and work needed to implement
it -- then suddenly this distinction disappears. In that case, however, the
generic terms such as "netvm" also looses its meaning, and instead we might want
to state something like: "the VM which is the target of qubes.Xyz service
request from VM abc".

> > The above examples also suggest that DispVMs should not be implicitly inheriting
> > any policies from the srcvm, like it is currently the case with firewall
> > configuration. I think this is a cleaner approach. Although there is some
> > potential problem -- e.g. I might want most of the DispVMs to be offline, except
> > the one for opening URLs from my email domain. So I would like to say something
> > like:
> >
> > cat qubes.Tcp
> > $dispvm deny
> > $dispvm.srcvm=work-email allow *:https # Admittedly syntax a bit clumsy...
>
> Maybe have a separate DispVM for that? Then the syntax would be clearer:
>
> cat qubes.Tcp
> $dispvm deny
> $dispvm:my_web_dispvm allow *:https
>
> cat qubes.OpenURL
> work-email $dispvm:my_web_dispvm allow
>
> Admittedly at the cost of having additional DispVM base VM to manage.
>

Right. I was trying to avoid the cost of having multiple templates for DispVMs.
However, I just realized the templates for these new DispVMs in Qubes 4 would
not need to be the actual Template VMs (as is: taking multiple GBs on the disk),
but could be just ordinary AppVMs (i.e.: taking just a few hundred of MBs on the
disk). So, I think this might be the best compromise, which would allow us to
keep the policy expression much simpler.

> > Such central configuration of all the VM interactions from within the Qubes
> > policy, combined with our management framework, should make it much easier to
> > offer default preconfigured configurations, hopefully making it harder for
> > users to shoot themselves into their foot.
> >
> > BTW, I think it might be useful to also provide some kind of a policy evaluation
> > tool, or some kind of a "simulator", to let the admins test the policies. One
> > example of a policy evaluation tool might be a graphing tool (based on dot) for
> > drawing all the allowed RPC invocations between VMs. Am I not mistaken that it
> > should work in O(M*N^2) time, where M is the number of files in
> > /etc/qubes-rpc/policy, and N is the no of VMs in the system?
> >
> > The remaining questions are how to determine the DispVM's 1) label and 2) netvm?
> > I don't have a strong opinion here, although I'm leaning towards having the
> > DispVM inherit the two from its template.
> >
> > joanna.
> >
> > [1] https://groups.google.com/forum/#!topic/qubes-devel/uQJL7I70GQs
> > [2] https://www.qubes-os.org/doc/qrexec3/
>

Given that we won't probably move networking to qrexec service anytime soon, I
think we should just assume the networking policy should be
DispVM-template-specific (and not inherited from the VM requesting DispVM start)
and just remember that the DispVM-template would not need to be the real
template VM. And as for the need to maintain multiple DispVM-template (i.e. keep
the updates), that could be solved by our magic mgmt stack now.

joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXOtGFAAoJEDOT2L8N3GcYtPkQANBJEean9N61vCFrDZtJuqEG
sHEunr54zofqb9LoYBIP1CNznBQakzCFiWkgIEsM7BF8emEcNdsfaxK0d9NitCzW
LsrzrHCvQFHe2H8BeZD4ya1pKfjvNcoW30Q3EfVYHW8rYgfnMZ6asmEtb26ROT3r
wu8gyYh7z/3taNhJffcgA60/KYYrunfd8WIYyEkcTzmPbs3fcy9wuYRF58eC0Gv0
G/TNeU/PYPt+5XsGsGCNyyMwWBCANkd9EDNmN6TC9jPWYB34NvF89a0XOJkliK09
KyrTK1I/mctToDa7NBzSAVE/gRXN6hYRh6uAJaKMON0F4gwuMeDI/4zYUCMcl4+c
7FDe8UfhDYKVkZeBPWOePjxvmhoawFXq+VI6IlHgN9TE6nWC7nCF+b+C6ieSVaBP
Zi3MIdLjhfDExc5sLxHLgalKwl2oT099a0evMILatuTo4eePjVa7ZwD6HHkB5BVG
SYcKEaS+3oHKMeAZQOvW4o8I6ZdBjBe6y3SrcKnjhkK9lYoEyvLS+jDX7A7eS6p8
mnCegjr5+iZY2gVq5/vsw+XAnTg3m49hpY4jz7kz8WAYp0EmLg2mXgRQplDECFHS
6l00GSi3H5MWVJrDvpUssuDyjad79YuUzOs8v7C6gxpWqCRwjRhiOKgJWU00TKca
UoNA8EHMRfa4YtsWMdt3
=3SxY
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

Ok. Lets suppose you've got request with empty target VM name ("lets dom0
decide") and policy like the above. Or even like this:

cat qubes.FileCopy
work work-email allow
work work-web allow
work work-vault allow

What should qrexec-policy tool do?

> > Also it isn't exactly what you wanted: you've written "for service
> > requests which otherwise don't specify arguments", but in fact you
> > wanted to "override regardless of argument specified by the caller".
> > Otherwise the called may specify its own policy, like "*:*"...
>
> That's an irrelevant technicality, because we want the policy to always override
> whatever specified the srcvm in case of any conflict.

Yes, I understand what you wanted to achieve: override the argument. But
this isn't what you've written, just that. I fully agree with such
approach (ability to override the argument by the policy).

> > There is a also another problem with such approach - having complex argument
> > (like full network policy) in a single string may be hard to manage and
> > very error-prone. Also, currently we filter argument from almost any
> > non-alphanumeric characters, to ease secure service implementation (not
> > to worry about shell special chars, path traversal etc). If we want to
> > put full firewall into service argument, that would be tricky (for
> > example '/' and '*' are not allowed, so 1.2.3.0/24:* would not be
> > possible).
> >
>
> Right, and we have been having this discussion for at least a year now :)
>
> I think the dom0 should _not_ do any parsing of the argument, just treat it as
> an opaque string and pass to the target vm's service. It might do some
> sanitization, that's ok. If '*' and '/' (understendably) should be sanitized out
> (b/c of the other way to specify the argument, i.e. in the policy file after the
> '+ sign), then we should pick some others.

I think firewall is too complex to be handled by very simple policy,
without complicating the policy. IMHO better leave it separate (either
in firewall.xml or elsewhere, with similar GUI as currently) and provide
some way to for "netvm" to retrieve it (qubes.GetFirewallRules
service?).

> > > Where the '$netvm' represents the actual netvm to which the srcvm is connected
> > > to (i.e the netvm should remain a property of the srcvm).
> >
> > Having '$netvm' which means different things depending on calling VM
> > may be misleading. I'd rather understand it as "system default NetVM".
> > Maybe "$srcvm:netvm"? Later we may introduce another options like this,
> > for example "$srcvm:gpgvm".
> >
>
> I'm not terribly against that syntax, just would like to note the fundamental
> difference between the netvm and what you described as gpgvm -- the former is a
> property of the VM, while the latter is just (one of the possible) dest VMs for
> some qrexec service request. Although... if we moved to qrexec-based networking,
> as I described above -- which I doubt we would do anytime soon, because of the
> fundamental disagreement about the argument parsing and work needed to implement
> it -- then suddenly this distinction disappears. In that case, however, the
> generic terms such as "netvm" also looses its meaning, and instead we might want
> to state something like: "the VM which is the target of qubes.Xyz service
> request from VM abc".

Exactly. And at least for some services it would be convenient to set
default target VM (per source-VM). Even when policy allow some other
options too.

Hmm, actually something very similar is already possible, we do have
"target=" option in the policy to override target VM. So it may look
like this:

cat qubes.OpenURL
work work-web allow
work $anyvm allow,target=$dispvm

This means VM 'work' will be able to open links in 'work-web' VM, but if
not specified (or specified anything else), it will open links in new
DispVM.

But still, I think it would be useful to have such per-service default
target VM as a VM property - it will be more convenient and safer for
the user (harder to introduce undesired change in the policy).

> > > Such central configuration of all the VM interactions from within the Qubes
> > > policy, combined with our management framework, should make it much easier to
> > > offer default preconfigured configurations, hopefully making it harder for
> > > users to shoot themselves into their foot.
> > >
> > > BTW, I think it might be useful to also provide some kind of a policy evaluation
> > > tool, or some kind of a "simulator", to let the admins test the policies. One
> > > example of a policy evaluation tool might be a graphing tool (based on dot) for
> > > drawing all the allowed RPC invocations between VMs. Am I not mistaken that it
> > > should work in O(M*N^2) time, where M is the number of files in
> > > /etc/qubes-rpc/policy, and N is the no of VMs in the system?
> > >
> > > The remaining questions are how to determine the DispVM's 1) label and 2) netvm?
> > > I don't have a strong opinion here, although I'm leaning towards having the
> > > DispVM inherit the two from its template.
> > >
> > > joanna.
> > >
> > > [1] https://groups.google.com/forum/#!topic/qubes-devel/uQJL7I70GQs
> > > [2] https://www.qubes-os.org/doc/qrexec3/
> >
>
> Given that we won't probably move networking to qrexec service anytime soon, I
> think we should just assume the networking policy should be
> DispVM-template-specific (and not inherited from the VM requesting DispVM start)
> and just remember that the DispVM-template would not need to be the real
> template VM. And as for the need to maintain multiple DispVM-template (i.e. keep
> the updates), that could be solved by our magic mgmt stack now.

Not inherited at all, or not inherited by default and have some setting
to change that? I'm asking because we have currently "dispvm_netvm"
property, which set "NetVM used by DispVMs started from this VM" (can anyone
follow this sentence?). Default is "the same as netvm property" (which
means to inherit the netvm connection).

What about label? There was some discussion about that:
https://github.com/QubesOS/qubes-issues/issues/1788

Since having multiple kind of DispVMs will be possible, maybe also let
it be DispVM-template-specific? Then if you want have DispVMs opened
from your work VM to be green, simply create "dispvm-work" with green
label. And have default DispVM red label.

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXOvuPAAoJENuP0xzK19csnZYIAIljXe15Or5cckSeVG0306Wc
HRxuI6TUIAQQsf77omNKY/bf/1Rj6Qw+8MG8gYD4zoe/1fmKWepEFeCPDKHnah/x
9VI3Ywpj2391WxDgPrBR6MkUUhwbVUEet9hYMHenN200BUMF/IfbxADfaFvb9zDR
jlWCHNQxLEiY12dyN2/wjjSt+xnmcixv+GPGTNtSTwSs0kGd1HHxk33hJ0nIMFnl
+rTq92PKJj29jg9CeW25yF/ckMxGNZ4acYj9oKpdYk98nyqUXHWuCrwutKQonuUJ
hfXYnrH5SN1reZ7GbwDqt2ouStKZg6pH1K3nayCaoC2fqiq94ZzZNXWGmuTrXK0=
=wUgC
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

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

Prompt the user (and optionally, some UI might also present the three VM names
as list of hints in a drop-down list).

Let's leave the firewall discussion for another threat :)

So, what you want to do is basically introduce a dictionary for each VM
addressable by the service_id, whose value would be the default target VM for
the given service, right? E.g.:

work['qubes.OpenURL']=work-web

I think that's fine, provided this would still need to comply with the policy, of
course. I.e. in case the policy defined in /etc/qubes-rpc/policy/qubes.OpenURL
had a rule preventing 'work' from requesting the service from 'work-web', such a
request would be blocked.

In the interest of clarity I'd say that DispVMs should _not_ inherit anything
from the srcvm (i.e. the VM which makes the service request), and instead only
inherit from its template. We should be able to achieve the current semantics of
"inherit everything from the srcvm" by... selecting the srcvm as the DispVM
template.

joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXOwTKAAoJEDOT2L8N3GcYNGQP/11SyeIYoPEOijbFd8sPOqCn
5xKPc9X/s+8diMr4hMlfC3+gCJlRVsM7ZV7ITZyrTuWIbHxD/HuqUQ8Dqh/Khj6o
4aq3/IpCcCJse3fmYnihPe3xpG4v17qRzNHuxiLX1bPBSDq+MuLBEjQu/I8HfWMJ
1tYOyw7Aqrg12rzzCWYUS4XpDH/OYZ7eZ9hV2f8XORfa+I2aG6xRhqkxRgaYrTpJ
a5ijh4lEPYUyvyyt9V2XRd5zvFI9wtuxL/BCxsnKEGQsxfpKbyz0PraIr7R+z+Td
itCHwynauxUoVR95uguVzf6GG9hEi9wJkZk/KdczvLrqau4oaTIo/ZN9P59TeBJx
v2CtFO6Gcc6XXLuyNrNh229LQ+Dqj36hFTY+smCvSsiRdgh9ukXJq0FOYrQ4Bx5A
Q8oU+ah60Bxm0phni4r/jeX64+I8Pqrc3LED0bF+QQkxa5n66lKd7N+jz9mP75pu
5vAisNfJuTiizKJ5qe92DxKXBjKGzg+HpJf8zi3r6/KhFKP0RE72Maf1ycBwg8SC
9WRrwGcMEDE7dIiGcvrDd3G6QsslIGvUm9qD25Av7HYuN44j1wcqngIeh7vKkXc+
iT55H4K+NinNXX3pI1ao6fv/fbr04Uns03c0OjeqPWPqJIDk/w/fgNcJ+8PaHJ4Q
36bTSX2Lot3uh+Uwp2g8
=x1SJ
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Tue, May 17, 2016 at 01:47:22PM +0200, Joanna Rutkowska wrote:
> On Tue, May 17, 2016 at 01:07:58PM +0200, Marek Marczykowski wrote:
> > On Tue, May 17, 2016 at 10:08:37AM +0200, Joanna Rutkowska wrote:
> > > On Mon, May 16, 2016 at 01:57:51PM +0200, Marek Marczykowski wrote:
> > > > But in case of not specified target domain, if the policy is
> > > > unambiguous, that could be used directly. If not - ask for target VM in
> > > > dom0. Probably using policy as a hint - for example:
> > > >
> > > > cat qubes.FileCopy
> > > > work work-email ask
> > > > work work-web ask
> > > > work work-vault ask
> > > >
> > > > Then the target VM prompt should list just those three VMs, with
> > > > 'work-email' being the first one (default).
> > > >
> > >
> > > If anything should be used as a hint, it's the dstvm specified by the srcvm. The
> > > policy should always have a priority over that.
> >
> > Ok. Lets suppose you've got request with empty target VM name ("lets dom0
> > decide") and policy like the above. Or even like this:
> >
> > cat qubes.FileCopy
> > work work-email allow
> > work work-web allow
> > work work-vault allow
> >
> > What should qrexec-policy tool do?
> >
>
> Prompt the user

Yes.

> (and optionally, some UI might also present the three VM names
> as list of hints in a drop-down list).

And here I think the UI should be as simple as possible. Having first of
those VMs already selected (there is already "allow", right?) IMHO would
be a good idea.

> So, what you want to do is basically introduce a dictionary for each VM
> addressable by the service_id, whose value would be the default target VM for
> the given service, right? E.g.:
>
> work['qubes.OpenURL']=work-web

Yes.

> I think that's fine, provided this would still need to comply with the policy, of
> course. I.e. in case the policy defined in /etc/qubes-rpc/policy/qubes.OpenURL
> had a rule preventing 'work' from requesting the service from 'work-web', such a
> request would be blocked.

Yes, of course.

Selecting srcvm as the DispVM template will have undesired effect: that
DispVM will have (read-only) access to srcvm private image. Not
something we want...

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXOwc8AAoJENuP0xzK19csq0wH/3v8IZt7luezLa4yi2FBmXIP
J+QNg+u5sAlvM3qdJM0FrTehZO8jq8PJn5k/rG+J5NMcY9vXUSQ3n2mLd/qAE4xA
f59kKbl8fAavav+/NtFnrqsA0aKCoWVkChrpGMD34ZtcW/9cCetpw09DixQz97Od
/id5pL3VpjgH8s/Y9BF1+efbfa/kGLEOuMpz1oT5otutb1Nqq/9uQS9CmnbZrpbq
4LAqZa8LSx7EEIOwV9npXfN9yhAjT3CvfgRdlyM9qJ/Tbbff0WvEYl3hPaxBGOX7
NIueaZoRtZYmt2/ddyZHfolv4DEiZhKB7LLEjRKKc+SENoTNSBWa5Qdwit2myHw=
=JBHV
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

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

Right, good point. Anyway, I still think we should go for the "inherit only from
the DispVM template" option.

joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXOwx3AAoJEDOT2L8N3GcYGsMP/iqc2DOa+kbJxdCCvlhFqK0/
Vb7I07pUQj5zmCxVGF2deXrN6lF3uPnklPND97cH5exS0Jez6tl9U2605AhmGgZh
e66M1yia1owrqCcsnegDJ3RFWiHBbRLMucowBZqxpf8WtAKJ8C+GUAPRxv12KYxv
oOCiOXAbVxPARLMsvmsE2yD0HkzNpIDQdqg7ecDbahGptVM6C69W4YdwyBMb/yf7
De8Nns+HgzVrar+/WPtfJ/yfDHOJmlRebEfodqUXFK3dX55MqocRDmKap9p65q+p
h+gwDCJ4Ry8uFMwLGH6NjYRNTOiLbISxlY9fZXzhXjmfNpnQg14o3L8BfK/Hwpwz
4bUkBe5Vw2fH62kOCpfRYIe2j69Oe4FJEizbuteZZVXHmbAgNWWj3hkEPJ2jYhEs
sxSV+YYmOvMezlCXoOzjevsZQNAVxnnMKM8aSF/1XZ6DNza4nSsHn9vbz9F6k2Mo
T/UuHGl/hsPGglvGk8/zpvFCnA3S/Bc3r8BukIPLS+AIkuowqK6TEfTcM/hC2yaw
FzbAt4QIh44mdlnqxkiJ5Nv8Yjb/v904GjI20EbeIvs8tVyuus2mQu9/1je/7RRX
7jRbGeCb26kJVr8jHRU2hv5GLGFyBSiCbafU5Sks4mONvcpgtn5GlD/egz0KQqM1
sek6Nt9M0a9ye+yZppl8
=rzf6
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

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

On Tue, May 17, 2016 at 02:20:07PM +0200, Joanna Rutkowska wrote:
> On Tue, May 17, 2016 at 01:57:47PM +0200, Marek Marczykowski wrote:
> > Selecting srcvm as the DispVM template will have undesired effect: that
> > DispVM will have (read-only) access to srcvm private image. Not
> > something we want...
> >
>
> Right, good point. Anyway, I still think we should go for the "inherit only from
> the DispVM template" option.

Ok.

So, I think this will be enough for new DispVM implementation. To
summarize:

1. Modify qrexec policy to allow express "DispVM based on X", not only
"DispVM" by adding "$dispvm:vmname" option. Have "$dispvm" mean "default

DispVM", not "any DispVM".

2. Move target VM choice from calling VM to dom0, based on qrexec policy
and user choice (https://github.com/QubesOS/qubes-issues/issues/910)

2a. (optional for 4.0?) Add ability to specify default target VM for
given service and source VM.

3. Inherit all the VM settings from DispVM base VM, instead of calling
VM (including label and netvm)

Related:

4. Implement qubes.OpenURL service
(https://github.com/QubesOS/qubes-issues/issues/1487)

- --
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-----
Version: GnuPG v2

iQEcBAEBCAAGBQJXOxFvAAoJENuP0xzK19cswGQH/2X3b8/oo6sRW1iZDRXNq6uf
beHhMe9NsxLMMPaFQyKzHpjYZIg+2Cx3rsZ/wf/RjA58APQETDaux/eEvCMhqPic
EobbU8e7dfnm5gNYc0H52DFXJf2kQaM99LSjIbX99fsivtrjkj1Q0Wgrkiq1Mwth
q/jdBflQ9GI6IkmMj0joL6SeEi47lB5hG3BKgtn2nyRv/fHmgNSBr18lU6hjd7j9
1bvxOn3zuzyPDn0ZqqAF3Ktkv7NwE5+MdEHY6os9Bykeet49QwHYeecS+WZ26GzY
G1cWmrUSVmz8zssdzRRsfR5gDeXrTgBsrwVj462cyYnjxoHETcuSkkT2FJQ+ubU=
=gdup
-----END PGP SIGNATURE-----

[Joanna Rutkowska]

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

On Tue, May 17, 2016 at 02:41:18PM +0200, Marek Marczykowski wrote:
> On Tue, May 17, 2016 at 02:20:07PM +0200, Joanna Rutkowska wrote:
> > On Tue, May 17, 2016 at 01:57:47PM +0200, Marek Marczykowski wrote:
> > > Selecting srcvm as the DispVM template will have undesired effect: that
> > > DispVM will have (read-only) access to srcvm private image. Not
> > > something we want...
> > >
> >
> > Right, good point. Anyway, I still think we should go for the "inherit only from
> > the DispVM template" option.
>
> Ok.
>
> So, I think this will be enough for new DispVM implementation. To
> summarize:
>
> 1. Modify qrexec policy to allow express "DispVM based on X", not only
> "DispVM" by adding "$dispvm:vmname" option. Have "$dispvm" mean "default
> DispVM", not "any DispVM".
>
> 2. Move target VM choice from calling VM to dom0, based on qrexec policy
> and user choice (https://github.com/QubesOS/qubes-issues/issues/910)
>
> 2a. (optional for 4.0?) Add ability to specify default target VM for
> given service and source VM.
>
> 3. Inherit all the VM settings from DispVM base VM, instead of calling
> VM (including label and netvm)
>
> Related:
>
> 4. Implement qubes.OpenURL service
> (https://github.com/QubesOS/qubes-issues/issues/1487)
>

Sounds about right. Also adding Wojtek.

joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXPErlAAoJEDOT2L8N3GcYAZcP/2GjBb22rVv09B0rqobO71gf
bC9FoTaqvOKfD6McvQwmA1a/ojlMgM9XkU4AT2Pe2Z1jrxUjJtd6NJeDf3cZDNXD
5eW/rjQtAqvRP/urQUmFRhK7sU/LAhBh3d+xki1I8zfAfTFDX4gnSpRK5ZgyMuSN
S9XXmPgmFakqkpXvUjUYPvEq47Z7mEnvhS0NZkZ/ItgzG7wnPLgER7I5iPUeLnM6
kn4sFXy4HbCTWedsDNeBgJ2s5lk0gE+6sANnLaXSRLog7QhtngwWtb5KNvHDMAJW
3/g4cPjqVjJDh5gaT2BjzJgDB+dAagczbgyYGI4gNXbQ3M7M3spgiqZTbtWPOkMd
4Bcy6M40wp9ktzoy8KXWXiifNlplk5sbng8fGuwQw9S8P8u59oL/tWL/uN70xptc
T/x85an4kzy08rsMQkenIeiD7yfBnT/H0XQZ2aARPlIVm+tik8hk6yMpBFQkCf2y
3/jL1CJL2hBnp4fnutTT5DiHwEtODdPMp3nwer4U/I4ohxWq2Zgj3F8jbxCrgBgs
l7CtqAhe1dktGAfK5kbjHHDMEETAie/tB0a/MbJLJ1UtA1PzoclUEF4p8lUkTlDW
fXqhXsGXEx+eJsZ0zbhaUQicALwFXzbFF2ZQPUCVBplyYr3d0hKqasI7JoB1OUL5
Ic01SRvyCuMKhg7ADoAm
=LC6A
-----END PGP SIGNATURE-----