[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:       Chris Laprise <tasket () openmailbox ! org>
Date:       2016-05-16 21:03:25
Message-ID: 573A359D.8030402 () openmailbox ! org
[Download RAW message or body]



On 05/13/2016 04:13 PM, Chris Laprise wrote:
> 
> 
> On 05/12/2016 07:24 PM, Marek Marczykowski-Górecki wrote:
> > -----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?
> 
> I doubt that Tor really matters for documents. Q: Interactive 
> documents? A: Unsupported fringe case. They can be manually 
> accommodated with some file copying.
> 
> As for the possibility of doing it the complex way, this has the 
> potential to make parts of the Qubes UI really confusing. At the very 
> least the options would need to be tucked away under an Advanced 
> button or everything dispvm-related moved to its own settings tab. 
> Then there is added complexity for Launcher, etc.
> 


In addition to what I said about having a boolean choice between 'local' 
and global dispvms, there could also be a global setting for the default 
dispvm template (as separate from the default template setting). This 
adds a lot of flexibility in a very simple way.

Furthermore, the question of anon functions can be addressed nicely if 
we make dom0 aware of whether whonix/anon service is available in the 
system. Then its a matter of adding just one more menu entry in the 
applicable context menus. That means only TWO menu items (open in 
dispvm, open in anon dispvm) if we assume the following:

1. The dom0 part of the framework understands whether the supplied 
object is a link or a file.
2. Dom0 prompts the user to grant network access /if/ the object is a 
link /and/ if its a normal dispvm (asking in the case of anon is pointless).
3. We allow the calling vm to request a non-networked dispvm in advance, 
so as to avoid the possibility of unneeded prompts. This facilitates 
file-oriented functions such as 'convert to trusted pdf'.

Chris

-- 
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/573A359D.8030402%40openmailbox.org. For \
more options, visit https://groups.google.com/d/optout.


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