Summary of the security discussions around Wayland and privileged clients

[Pekka Paalanen]

On Wed, 19 Feb 2014 17:11:03 +0100
Martin Peres <martin.peres at free.fr> wrote:

> Hi Guys,
> 
> Following to the giant and impossible to read "Authorized clients" 
> thread, I said I would take the time and write everything we talked 
> about down, for convenience and to check I took everyone's idea and 
> needs into account.
> 
> I published the whole article on my blog [1] but I also wanted to copy 
> the relevant information in this email, so as it could be easier for 
> people to comment inline (since I'm really interested in feedback here), 
> sorry for the markdown syntax but that's what I use for my website.
> 
> I added Martin Graesslin in CC because he has shown interest in this and 
> I'm sure his experience can benefit all of us.
> 
> Hope something close to this proposal will be satisfactory to everyone 
> and work can begin in this direction!
> 
> Cheers,
> Martin Peres
> 
> [1] 
> http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and-how-to-handle/
> 

Nice work! :-)

> #### Recommendations to restricted Wayland interface designers
> 
> I have never designed an interface for Wayland and don't know what the 
> best practice is. However, I know that restricted interfaces should 
> never be considered as always usable.
> 
> The first important point is that before being able to use an interface, 
> a client should first bind to it. This binding process could either 
> succeed or fail, depending on the compositor's security policy. Clients 
> are mandated to test that binding worked well before using the 
> interface. In case it didn't, clients should fail gracefully and tell 
> the user what restricted interface couldn't be bound. Also, binding a 
> restricted interface could take some time and the application shouldn't 
> block on it.

It can be done, but with a little more effort than implied here.
Binding to an interace means wl_registry.bind request, and failing that
is always a fatal error, which terminates the client connection. All
errors in Wayland are fatal like that.

Instead, the interface should be always bindable, but include explicit
protocol to indicate failure in using its requests.

> To support privileges revocation, a revoke signal should be added to the 
> interface in order to inform clients their rights to access the 
> restricted interface have been revoked. Clients should fallback 
> gracefully and tell the user they received such a signal.
> 
> #### Launching privileged Wayland clients from the compositor
> 
> The most-secure way of launching clients requiring restricted interfaces 
> is to let the compositor run them by itself. This way, it can control 
> the environment in which the process has been launched which lowers the 
> risks of environment attacks such as the ``LD_PRELOAD`` one exposed earlier.
> 
> Implementing such a system is difficult as the compositor needs to 
> remember that the PID of the client it launched should be granted the 
> privileges to access one or more restricted interfaces when this 
> (soon-to-become)client connects to the Wayland compositor. Not only does 
> it mean that the compositor needs to have a separate table of which PIDs 
> are supposed to get which privileges, it also means the compositor needs 
> to keep track of the death of the client's PID to avoid another process 
> from re-using the PID of this client and gaining access to privileged 
> interfaces it wasn't supposed to access.

FWIW, Weston already does track its children by pid also, so that it
can respawn them as needed if they e.g. crash.

> A simpler and more secure solution would be for the compositor to open a 
> UNIX socket to itself before exec'ing the client. Once opened, it should 
> be simpler for the compositor to set the client's capabilities to a flag 
> stored in the structure tracking the client and then execute the 
> client's binary. When running the exec() syscall, all the FDs that have 
> not been opened with the ``O_CLOEXEC`` 
> [flag](http://linux.die.net/man/2/open) will be passed on to the new 
> process. A run-time parameter of the Wayland client could then be used 
> to tell which FD represents the unix socket to the Wayland compositor. 
> An example of such parameter could be ``--wayland-fd=xxx``. The 
> compositor should however be careful it doesn't leak any un-needed FD to 
> the new client.

Weston already implements this, and libwayland-client directly supports
this with the environment variable WAYLAND_SOCKET. This is documented
on wl_display_connect(). That is, all Wayland clients automatically
support this, AFAIK.


Thanks,
pq