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

List:       qubes-devel
Subject:    [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 10:13:57
Message-ID: 20160512101357.GL1171 () mail-itl
[Download RAW message or body]

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

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


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