[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:24:40
Message-ID: 20160512232440.GL25975 () mail-itl
[Download RAW message or body]

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

On Thu, May 12, 2016 at 11:24:42AM -0400, Chris Laprise wrote:
> 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.

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

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


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