A security context implementation for authenticating and/or authorizing clients

There are Wayland protocol extensions that need to be privileged: available to only very specific clients that are known to be trusted. The ability to take screenshots is an example of such privilege.

There are a couple of use cases for reliably identifying a client:

• authorizing a set of clients for privileged actions at system installation time, so that they will just work
• application specific permissions model (e.g. Android), where applications can ask for permissions for privileged actions. The granted permissions must be stored somewhere, and the returning client must be reliably identified as the same that was previously given permission.

Traditionally client authentication has been side-stepped completely by pre-creating an already authorized client connection and passing that to the client process via WAYLAND_SOCKET environment variable. Weston implements this for few special cases. The disadvantage of this is that the client process must be prepared and spawned by the compositor directly.

Another possible method is inspecting the client process' executable path, and using that as the client's identity. This involves fetching the process ID from the unix socket connection, and then looking at e.g. /proc/$pid/exe. This approach has several disadvantages:

• The process ID from the socket is the process that created the connection, which is not necessarily the client actually running.
• Inspecting /proc/$pid/exe is said to be easily spoofable.
• The executable file must be immutable by the user, otherwise a malicious program running as the user can simply replace the executable. (Applies to WAYLAND_SOCKET method as well.)

Attempting to isolate a unix user essentially from itself may be an ill-defined problem to begin with. Here we should concentrate on the Wayland connection only, and assume that e.g. ptraceing other clients or even the compositor is already made impossible.

One idea I have heard is that all untrusted applications should be executed inside jails or containers, where the application identity is tied to the specific container. Everything outside of containers would be implicitly trusted. Clients from containers could be identified by e.g. coming through a specific per-container Wayland listening socket, or through a Wayland proxy.

Another idea I have heard is inspecting the security labels from the Wayland connection file descriptor. I wonder if that is something that could have an implementation in Weston upstream. Libwayland-server already exposes the fd (wl_client_get_fd()).

If the implementation must be specific to a certain kernel security framework, the framework should be one that is easily usable in major distributions. If the method lends itself to containers as well, the better. Requiring the application executable to be immutable to the user is acceptable.

The goal is that when an application is installed from a distribution's package manager, it will be reliably identifiable as a Wayland client: no other program can successfully claim to be that application without gaining elevated privileges in the operating system.

What options are there, and how would they be used?