Le 20/02/2014 13:04, Pekka Paalanen a écrit :
On Wed, 19 Feb 2014 17:11:03 +0100
Martin Peres <[email protected]> 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
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
