[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] DispVM design decisions for Qubes 4.0
From:       Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek () invisiblethingslab ! com>
Date:       2016-05-12 23:15:38
Message-ID: 20160512231538.GK25975 () mail-itl
[Download RAW message or body]

-----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-----

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20160512231538.GK25975%40mail-itl. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]