Summary of the security discussions around Wayland and privileged clients

[Bill Spitzak]

This makes it impossible for a privileged client to distribute it's 
privledges to more than one subprocess, or to both itself and a subprocess.

That is why I would prefer an "id" approach, which I still think would 
be a good way for parent processes to send objects to children, even if 
it is not used for privileges. If a process has an object it can ask the 
server for an "id". It can then use IPC (including environment variables 
or argv) and pass the id to any other process. That process can open the 
same server, send the id, and get the same object. The id is a random 
number generated by the server and it keeps a map of id->object (and 
probably throws them away after first use or a timeout).

The already-opened fd is still useful and the top-level privledged 
clients would still use this exactly as proposed. If a client tries to 
create a screenshooter object and it is not on the privledged socket 
then it fails. However any client if it can send the right id can get a 
second connection to the screen shooter object. But the only way to get 
that id is for a client that has the screen shooter object to ask for it.

The already-opened fd is also useful so all clients don't have to 
reproduce whatever rules there are for locating the server. A parent 
process using this can be pretty certain that it's child will use the 
correct wayland server.

Jason Ekstrand wrote:
> On Thu, Feb 20, 2014 at 2:41 PM, Thiago Macieira <thiago at kde.org 
> <mailto: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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel