[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:       Andrew David Wong <adw () qubes-os ! org>
Date:       2016-05-13 2:44:27
Message-ID: d9701fb8-fd59-64d2-0ebb-87eff43354e3 () qubes-os ! org
[Download RAW message or body]

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

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

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

-- 
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/d9701fb8-fd59-64d2-0ebb-87eff43354e3%40qubes-os.org.
 For more options, visit https://groups.google.com/d/optout.


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