cross-client surface references

[Jonas Ådahl]

On Thu, Jul 09, 2015 at 10:00:56AM +0100, Daniel Stone wrote:
> Hi Alex,
> 
> On 9 July 2015 at 09:44, Alexander Larsson <alexl at redhat.com> wrote:
> > On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
> >> This thread has sadly degenerated into: 'what if Wayland's object
> >> model was totally different? what if some of its explicit core design
> >> principles were thrown out the window?'. Realistically, that is not
> >> something that will happen in the Wayland 1.x timeframe, if ever.
> >> Where this thread started was, 'what's a good sandboxing model for
> >> clients which must be explicitly separated for security reasons?',
> >> and
> >> the answer to that is the same answer to the same issue within WebKit
> >> 2 (UI process distrusts render processes), which is that your more
> >> trusted client itself becomes a Wayland compositor. Which is exactly
> >> what Jasper did with Wakefield, almost exactly for this usecase, a
> >> few
> >> months ago. If there are issues with that design, then great, let's
> >> chase that up.
> >>
> > I'm not at all interested in the change that bill is talking about, and
> > I think it is unfortunate that it takes this thread off-topic, but this
> > is a mischaracterization of the problem.
> >
> > Yes, using a subcompositor is a good idea for the case where a more
> > privileged process needs to contain some subclient. In fact, I took
> > Jaspers wakefield work and extended it for use in the case of e.g.
> > embedding a file previewer out of process.
> >
> > However, the problem I have now is different, in that it involves an
> > existing, less privileged client initiating a higher privileged
> > operation (in a controlled fashion) and the higher privileged client
> > needing to refer to the lower privileged one. In particular, I need the
> > compositor to get toplevel parenting right (higher priv dialog has a
> > parent that is a lower priv toplevel).
> >
> > This case can not really be solved using subcompositors.
> 
> Fair enough; that does help.
> 
> Is that the absolute limit of what you require: that the higher-priv
> dialog must be a child of the lower-priv window, and that's it?
> Without an interface that was very strictly limited to that exact
> usecase, I can see no end of issues for manipulation.
> 
> Even with that, I'm struggling to think of how to do it in a truly
> secure fashion. My base idea would be for the lower-priv client to
> create an fd referring to its xdg_surface, which when passed to the
> higher-priv client (having its own separately-initiated connection to
> the compositor), allowed it to use a special interface to create a
> modal dialog as a child of that surface, and nothing else. But the
> wider we drag the surface area, the more difficult it gets to design
> out really unpleasant races.

That is more or less what was the idea before the thread derailed.

Something like:

low-priv-client:

xdg_surf = xdg_shell.get_xdg_surface
fd = export(xdg_surf)
* pass fd to high-priv-client via dbus *

high-priv-client:

* receive fd from low-priv-client via dbus *
xdg_foreign = import(fd)
xdg_surf = xdg_shell.get_xdg_surface
xdg_surf.set_parent(xdg_foreign)

I think that if we clarify what happens if the exported surfaces
disappears (which is the race you are referring to I suppose), as well
as provide events for that on xdg_foreign so the high-priv-client can
clean up etc, I don't see anything obvious that will go wrong. Also if
we force the set_parent(foreign) to always stack above the foreign tree
(similar to how subsurfaces stacking works), what would the security
implications be?

We can't put too many rescriptions on the xdg_surf of the
high-priv-client, since it needs to be able to map its own child
surfaces (popup menus and subsurfaces at least).


Jonas