[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:       "Manuel Amador (Rudd-O)" <rudd-o () rudd-o ! com>
Date:       2016-05-16 17:39:14
Message-ID: e4f786c0-9383-bb10-655d-20e91c0f8440 () rudd-o ! com
[Download RAW message or body]

On 05/16/2016 10:30 AM, Joanna Rutkowska wrote:
> On Thu, May 12, 2016 at 12:13:57PM +0200, Marek Marczykowski wrote:
> > 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:

Careful, you may end up reimplementing a crappy version of capabilities.

I'm not just joking here.  Half of it is a joke.  The other half is
serious.  Fundamentally, the problem to solve is as follows:

* User wants to perform an activity on a certain object or using certain
services
* User is controlling the source of that activity (a browser displaying
an untrusted link, or a file manager showing the icon of an untrusted file)
* User wants do use the source of that activity to initiate the
performance of that activity

This reeks from a mile away as something that could be well-served by
capabilities -- the user expresses to the source system "I want to
perform this activity X with object Y on a different domain Z which has
access to resources W, V, and U, and no more than that", and the source
system is in charge of making that request to its parent domain, which
is the actual original source of the capabilities -- the only thing that
can actually give permission to execute the activity X in the context
provided by the intersection of Y Z V W U.  Of course, at this point,
the parent domain prompts the user for confirmation, and if the user
confirms (or policy deems it so), then BAM, the activity begins.

The complexity of the interaction, of course, can vary from anything
like "Right click on a file, select convert PDF to trusted PDF", to
"Right click on a file, select Print, display dialog selecting domain
that will do the printing, start domain with its own network settings"
to "Right click on a link, select Open in untrusted browser, display
dialog allowing the user to select a domain and its networking
properties, then start domain with the provided network settings".

But, of course, this quickly runs into the problem of the fact that the
source domain does not necessarily, or should not necessarily, know
certain properties necessary to display such a decision dialog box. 
What business does my banking VM have, learning of network adapters /
NetVMs that exist in my system?  None.  But, for some reason, it also
seems "wrong" to put those policy UX elements in Dom0, and it also
requires a bit of a reinvention of the policy service to support such an
use case where in some cases it makes sense to ask the use to make a
policy decision, while in others it's brain dead obvious that asking the
user only causes a security problem (e.g. why does the user benefit from
selecting a NetVM when starting a PDF in an untrusted domain?).

We need to think about the use cases carefully before committing to the
code.  It's easy to say, "this or that is just a fringe use", but more
often than not, that is something people tell themselves to avoid
considering how a robust implementation of said "fringe use" would work,
or what scary doors that implementation opens.

My two cents.

-- 
    Rudd-O
    http://rudd-o.com/

-- 
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/e4f786c0-9383-bb10-655d-20e91c0f8440%40rudd-o.com.
 For more options, visit https://groups.google.com/d/optout.


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