[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-13 20:13:47
Message-ID: 5736357B.7010804 () openmailbox ! org
[Download RAW message or body]



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.

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

I recall the distinction from a past discussion, and my own thinking is 
(like #1) to keep the functionality effective but simple... WWAD (What 
Would Apple Do)? Since you are already adding a complex feature, the 
added implementation details should be very simple at first. 
Distinguishing between a file and a link (isolated vs networked) is as 
far as I would go for now.

Printing is an interesting case, but the paper-bound office is still on 
the decline. You can try to address it with the dispvm concept and still 
not be able to provide actual connection to printing services (which 
will become glaringly obvious as soon as you try to implement any 
automation for printing).

I'm beginning to think the best practice here is to encourage people to 
create LAN vms (i.e. LAN-home, LAN-work, etc) since printers, routers, 
and scanners (maybe even lightbulbs, thermostats and security cameras) 
have a similar insecurity profile. A 'QubesOutgoing' folder can even be 
utilized so that users can print-to-PDF into it, and if that appvm is 
set to have permission then automatically shuffle it to the LAN vm for 
printing.

Those are my thoughts.

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


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