[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-13 14:18:11
Message-ID: 20160513141811.GT25975 () mail-itl
[Download RAW message or body]

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

On Thu, May 12, 2016 at 07:44:27PM -0700, Andrew David Wong wrote:
> 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?

Yes.

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

Maybe... or dispvm_base?

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

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

-- 
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/20160513141811.GT25975%40mail-itl. For \
more options, visit https://groups.google.com/d/optout.


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