Summary of the security discussions around Wayland and privileged clients

[Martin Peres]

Le 20/02/2014 13:04, Pekka Paalanen a écrit :
> 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! :-)
Thanks, the write up did take some time. However, it's not technically my
work since at least 7 people have been discussing about this. I merely
compiled the ideas as best as I could.

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

In this case, we can make something pretty simple, send a signal
to the application if rights to use this interface has been granted.

If the application tries to use the interface without having the rights
to do so, an EPERM signal can be sent (not to be confused with the
revokation signal that happens when .... rights have been revoked).

What do you think?
>
>> 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.
Oh, ok. But not all Wayland compositors want to support that. They certainly
don't have to!
>> 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.
Awesome, you managed to make it all transparent to the application!
That is really sweet.

Cheers,
Martin