'Re: [qubes-devel] DispVM design decisions for Qubes 4.0'

[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-17 11:57:47
Message-ID: 20160517115747.GI25975 () mail-itl
[Download RAW message or body]

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

On Tue, May 17, 2016 at 01:47:22PM +0200, Joanna Rutkowska wrote:
> On Tue, May 17, 2016 at 01:07:58PM +0200, Marek Marczykowski wrote:
> > On Tue, May 17, 2016 at 10:08:37AM +0200, Joanna Rutkowska wrote:
> > > On Mon, May 16, 2016 at 01:57:51PM +0200, Marek Marczykowski wrote:
> > > > But in case of not specified target domain, if the policy is
> > > > unambiguous, that could be used directly. If not - ask for target VM in
> > > > dom0. Probably using policy as a hint - for example:
> > > > 
> > > > cat qubes.FileCopy
> > > > work work-email ask
> > > > work work-web ask
> > > > work work-vault ask
> > > > 
> > > > Then the target VM prompt should list just those three VMs, with
> > > > 'work-email' being the first one (default).
> > > > 
> > > 
> > > If anything should be used as a hint, it's the dstvm specified by the srcvm. \
> > > The policy should always have a priority over that.
> > 
> > Ok. Lets suppose you've got request with empty target VM name ("lets dom0
> > decide") and policy like the above. Or even like this:
> > 
> > cat qubes.FileCopy
> > work work-email allow
> > work work-web allow
> > work work-vault allow
> > 
> > What should qrexec-policy tool do?
> > 
> 
> Prompt the user 

Yes.

> (and optionally, some UI might also present the three VM names
> as list of hints in a drop-down list).

And here I think the UI should be as simple as possible. Having first of
those VMs already selected (there is already "allow", right?) IMHO would
be a good idea.

> So, what you want to do is basically introduce a dictionary for each VM
> addressable by the service_id, whose value would be the default target VM for
> the given service, right? E.g.:
> 
> work['qubes.OpenURL']=work-web

Yes.

> I think that's fine, provided this would still need to comply with the policy, of
> course. I.e. in case the policy defined in /etc/qubes-rpc/policy/qubes.OpenURL
> had a rule preventing 'work' from requesting the service from 'work-web', such a
> request would be blocked.

Yes, of course.

> > > > > Such central configuration of all the VM interactions from within the Qubes
> > > > > policy, combined with our management framework, should make it much easier \
> > > > > to offer default preconfigured configurations, hopefully making it harder \
> > > > > for users to shoot themselves into their foot.
> > > > > 
> > > > > BTW, I think it might be useful to also provide some kind of a policy \
> > > > > evaluation tool, or some kind of a "simulator", to let the admins test the \
> > > > > policies. One example of a policy evaluation tool might be a graphing tool \
> > > > > (based on dot) for drawing all the allowed RPC invocations between VMs. Am \
> > > > > I not mistaken that it should work in O(M*N^2) time, where M is the number \
> > > > >                 of files in
> > > > > /etc/qubes-rpc/policy, and N is the no of VMs in the system?
> > > > > 
> > > > > The remaining questions are how to determine the DispVM's 1) label and 2) \
> > > > > netvm? I don't have a strong opinion here, although I'm leaning towards \
> > > > > having the DispVM inherit the two from its template.
> > > > > 
> > > > > joanna.
> > > > > 
> > > > > [1] https://groups.google.com/forum/#!topic/qubes-devel/uQJL7I70GQs
> > > > > [2] https://www.qubes-os.org/doc/qrexec3/
> > > > 
> > > 
> > > Given that we won't probably move networking to qrexec service anytime soon, I
> > > think we should just assume the networking policy should be
> > > DispVM-template-specific (and not inherited from the VM requesting DispVM \
> > > start) and just remember that the DispVM-template would not need to be the real
> > > template VM. And as for the need to maintain multiple DispVM-template (i.e. \
> > > keep the updates), that could be solved by our magic mgmt stack now.
> > 
> > Not inherited at all, or not inherited by default and have some setting
> > to change that? I'm asking because we have currently "dispvm_netvm"
> > property, which set "NetVM used by DispVMs started from this VM" (can anyone
> > follow this sentence?). Default is "the same as netvm property" (which
> > means to inherit the netvm connection).
> > 
> > What about label? There was some discussion about that:
> > https://github.com/QubesOS/qubes-issues/issues/1788
> > 
> > Since having multiple kind of DispVMs will be possible, maybe also let
> > it be DispVM-template-specific? Then if you want have DispVMs opened
> > from your work VM to be green, simply create "dispvm-work" with green
> > label. And have default DispVM red label.
> > 
> 
> In the interest of clarity I'd say that DispVMs should _not_ inherit anything
> from the srcvm (i.e. the VM which makes the service request), and instead only
> inherit from its template. We should be able to achieve the current semantics of
> "inherit everything from the srcvm" by... selecting the srcvm as the DispVM
> template.

Selecting srcvm as the DispVM template will have undesired effect: that
DispVM will have (read-only) access to srcvm private image. Not
something we want...

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

iQEcBAEBCAAGBQJXOwc8AAoJENuP0xzK19csq0wH/3v8IZt7luezLa4yi2FBmXIP
J+QNg+u5sAlvM3qdJM0FrTehZO8jq8PJn5k/rG+J5NMcY9vXUSQ3n2mLd/qAE4xA
f59kKbl8fAavav+/NtFnrqsA0aKCoWVkChrpGMD34ZtcW/9cCetpw09DixQz97Od
/id5pL3VpjgH8s/Y9BF1+efbfa/kGLEOuMpz1oT5otutb1Nqq/9uQS9CmnbZrpbq
4LAqZa8LSx7EEIOwV9npXfN9yhAjT3CvfgRdlyM9qJ/Tbbff0WvEYl3hPaxBGOX7
NIueaZoRtZYmt2/ddyZHfolv4DEiZhKB7LLEjRKKc+SENoTNSBWa5Qdwit2myHw=
=JBHV
-----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/20160517115747.GI25975%40mail-itl. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic