Summary of the security discussions around Wayland and privileged clients

[Jason Ekstrand]

On Thu, Feb 20, 2014 at 2:41 PM, Thiago Macieira <thiago at kde.org> wrote:

> Em qui 20 fev 2014, às 21:31:59, Martin Peres escreveu:
> > > Now, the privileged process wants to launch a sub-process. How will the
> > > sub- process connect to the compositor? Remember: WAYLAND_SOCKET
> contains
> > > a file descriptor number that isn't available to the child process.
> >
> > Ah, I see. You are suggesting un-setting WAYLAND_SOCKET and using
> fcntl() to
> > set the socket's fd to CLOEXEC?
>
> Setting the socket to O_CLOEXEC is mandatory after you start using it. Two
> processes cannot write to the same streaming socket file descriptor at the
> same
> time. You might be able to do this with a datagram socket, but that's not
> the
> case here.
>
> > It is true that multiple process could end up with the same connection
> and
> > I didn't think about that. The problem is the same if an application
> > connects
> > to the compositor by itself and then forks. Not sure how the compositor
> > could detect that :s
>
> It can't. It will get very confused because two applications with
> independent
> states will start stepping on each other's toes. The best outcome of this
> would be if the compositor detected a problem early on and cut the
> connection
> to both.
>
> The way I see it, wl_display_connect() must unset the WAYLAND_SOCKET
> environment variable after getting the file descriptor number and it must
> set
> O_CLOEXEC. The socket is not available to child processes.
>

It already does both of these:
http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n763


>
> But then the question returns: how do child processes connect to the
> compositor, if the environment variable was cleared? How do they find the
> compositor?
>
> Solutions:
>
> 1) the compositor MUST have a well-known socket name
>   => not an option, since we want to have multiple concurrent compositors
>
> 2) wl_display_connect() doesn't clear the environment, but resets it to the
> actual socket name. It needs to get the socket name from somewhere.
>   => problem: if it's getting the name from the compositor, this may take a
>   few roundtrips and the process may have decided to start the child
> process
>
> 3) use a different environment variable. One variable contains the
> traditional
> socket path and the other contains the file descriptor. The latter
> overrides
> the former.
>

This is what we are doing right now.  The WAYLAND_DISPLAY environment
variable contains the name of a socket that can be found in
XDG_RUNTIME_DIR.  The WAYLAND_SOCKET environment variable (if it exists)
contains a file descriptor that a single client can use to connect to the
compositor.  Inside wl_display_connect, we clear WAYLAND_SOCKET but not
WAYLAND_DISPLAY.  If both are present, the client connects directly and is
then free to spawn other clients which will connect via WAYLAND_DISPLAY.
However, those other clients will not have the same priviledged status
because they didn't use the direct connection.  This is the way Weston's
desktop-shell panel spawns things right now.


> 4) store both settings in WAYLAND_SOCKET. D-Bus does that:
> DBUS_SESSION_BUS_ADDRESS can contain multiple addresses, to be attempted in
> order.
>

That's an interesting idea.  Not sure what benefit it would have for
Wayland right now though.

Hope that helps,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140220/7b71eacf/attachment.html>