Summary of the security discussions around Wayland and privileged clients

Martin Peres martin.peres at
Wed Feb 19 08:11:03 PST 2014

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!

Martin Peres



#### Current state of security within Wayland compositors

The first good point of the Wayland protocol is input management. At the 
moment, the protocol doesn't allow snooping on the input 
(confidentiality), generating input events (integrity) nor for an 
application to grab all events (availability). However, Wayland clients 
allowing ``LD_PRELOAD`` are still vulnerable to input attacks, as 
[demonstrated]( by 
Maarten Baert. This is not Wayland compositors' problem so it won't be 
taken into account in this discussion.

Just like with X, there are multiple ways for applications to send their 
output buffers to the graphics server. With Wayland/Weston, applications 
can use shared memory (SHM) or GEM's buffer sharing mechanism. SHM 
buffer sharing is meant for CPU-rendered application while GEM-based 
buffer sharing is meant for GPU-rendered applications.

SHM buffer sharing seems to be using anonymous files and [file 
descriptor(fd) passing]( in order to 
transmit buffers from the client to the compositor. This makes sure that 
only the creator and the receiver of the fd can access the (now-shared) 
resource, making it impossible for a third-party other than the kernel 
to spy on or modify the output of other applications (confused-deputy). 
Confidentiality and integrity seems to be guaranteed but I haven't 
dwelved into the implementation to make sure of it.

GEM buffer sharing [is known to be 
because shared buffers are referenced by a easily-guessable 32-bit 
handle. Once the handle is guessed, the buffer can be opened by other 
application run by the same user without access control. Once opened, 
the buffers may be read from or written into. This means confidentiality 
or integrity cannot be guaranteed on the output of applications using 
this buffer-sharing method.

On-going work [is being 
to make use of 
instead of GEM. DMA-Buf, just like SHM, is based on anonymous files and 
fd-passing and even allows different GPU drivers to exchange GPU 
buffers. Once the Wayland protocol and GPU applications start using it, 
confidentiality and integrity of the output buffers won't be a problem 

     |    Property     |  Input  |  Output  |
     | Confidentiality |   YES   |   WIP    |
     |    Integrity    |   YES   |   WIP    |
     |  Availability   |   YES   |   YES    |

#### The need for standardised privileged interfaces

Although Tim and I advised Wayland compositors [not to rely on external 
to perform privileged tasks, some people do think it is needed as they 
want to make it possible to develop cross-compositors applications 
performing privileged tasks. Examples of such applications would be:

- Screenshot applications (stills and video)
- Virtual keyboards and pointing devices
- Screen sharing (VPN, Skype)
- Hotkeys handlers (?)
- Session lockers

All of these applications are violating one or more security properties. 
Wayland compositors should thus control the access to the interfaces 
allowing those applications to work. Since we want these applications to 
be cross-compositors, a standardised way of granting/passing/revoking 
privileges should be described in the protocol or its implementation 
reference guide.

#### Allowing the user to securely break security properties

By default, the system should be enforcing all the security properties 
we defined earlier. However, sometimes, users need/want to automate some 
process, record their screens or lock the computer with a custom-app. 
This is why we need ways to by-pass the security when it is really 
needed. Without such means, people may refuse to use Wayland because it 
"takes freedom away from them". However an ideal design is so that 
someone will always come up first with the "right" way to do something. 
Here when it comes to distributors/vendors using Wayland, you want them 
to use your own preferred security property rather than entirely 
unlocking Wayland's safeguards to support the features of poorly-written 

The usual way of dealing with applications needing more privileges is to 
statically give them at launch time. Once an application has no use of 
the permission anymore, it can revoke its right to access it, until its 
next execution. This is very similar to what exists with 

The problem with such a system is that a malicious application could 
potentially take advantage of a poorly-coded application that holds an 
interesting capability (assigned statically at launch time), and use 
that application's capability to gain indirect access to the restricted 
interface it is interested in. This is because permissions aren't 
granted according to the immediate intent of the user. Indeed, a user 
would ideally always have a way to be aware of a reduced security state. 
This means the user has to take action in order to temporary reduce the 
security. The user should then be able to check whether the system's 
security is still reduced and should be able to revoke permissions. 
Capturing the user's intent can be done by:

- Waiting for a user to press the key with a clear semantic before 
launching the associated application (for instance, PrintScreen 
launching the screen-shot application)
- Prompting the user whenever an application tries to access a 
restricted interface
- Creating secure widgets that are drawn and managed by the compositor 
but can be imported in applications 
- Any other way?

The first solution requires absolute trust in the input integrity and 
requires the compositor to know which application it should run 
(fullpath to the binary). The second solution requires both trust in 
input integrity and output integrity (to prevent a malicious application 
from changing the content of the prompt window to change its semantic 
and turn it into a fake advertisement, for instance). The third solution 
requires secure widgets, unfortunately it is -ENOTQUITETHEREYET. We have 
ideas on how to implement them using sub-surfaces, they will be 
discussed again later on this very same blog ;)

While I think the user-intent method has a higher security than static 
privilege assignation, I think  both should be implemented with the 
latter used as a way for users to specify they are OK with potentially 
reducing the security of the desktop environment to let the application 
he/she wants to run properly. This will lower users' dissatisfaction and 
should result in a better security than bypassing some security 
properties for all applications. I am however worried that some stupid 
applications may be OK with creating snapshot capabilities from the 
command line, without requiring the user's input. A packager would then 
grant the privileges to this application by default and thus, the mere 
fact of having this application installed will make your desktop 
non-confidential anymore.

This is why once privileges have been granted, the user needs to have a 
way to keep track of who has access to restricted interfaces. This can 
be done by having a mandatory notification when an application accesses 
a privileged interface and a compositor-owned application in the systray 
whose colour would indicate the current security state (no threat, at 
least one application has the rights to use a restricted interface and 
at least one application is using a restricted interface). A click on 
this icon could provide more information about which restricted 
interfaces are used by which application. A button could then be added 
to each entry to allow users to revoke some privileges of applications. 
While I think the interface for the application providing this feedback 
should be specified, the user shouldn't have a choice on it and it 
should be hardcoded in the Desktop Environment.

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

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.

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]( 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.

#### Letting applications require more privileges at run time

Some times, application may require access to a restricted interface 
after it has been launched. In this case, they can use the binding call 
I described earlier and the compositor will grant access to it or not, 
depending on its configuration or policy.

The problem with allowing applications to require more privileges is 
that we do not control their environment and we cannot make sure it 
didn't get loaded with ``LD_PRELOAD`` or tampered with in any other way. 
As this decision really depends on which other security tools are being 
used on the computer, this isn't something Wayland compositors should 
hard-code. This leads us to our final proposal.

#### Wayland Security Modules

As seen earlier, granting access to a restricted interface or not 
depends on the context of the client (how it was launched, previous 
actions). The expected behaviour should be defined by a security policy.

As no consensus on the policy [can apparently be 
(as usual in security), we have all agreed that we needed to separate 
the policy from the code. This is very much alike [Linux Security 
or [X Access Control Extension 

 From a software engineering point of view, we would work on a security 
library called Wayland Security Modules (name subject to changes) that 
Wayland compositors would call when a security decision would need to be 
made. The library would then load the wanted security policy, defined by 
a shared-object that I will refer to as the security backend. In the 
case of allowing a client to bind a restricted interface or not, the 
corresponding WSM hook should return ``ACCEPT``, ``PROMPT`` or ``DENY``, 
prompt meaning the compositor would have to ask the user if he wants to 
accept the risk or not. Let me stress out that prompting should be a 
last-resort measure as numerous studies have been made proving that 
unless asked very rarely, users will always allow the operation.

Some additional hooks would also be needed in order to track the state 
of Wayland clients (open, close, etc...) but nothing too major should be 
needed. The compositors would just have to store this context in a 
``void *security;`` attribute in the Wayland client structure. Finally, 
WSM could be extended to control the access to the clipboard and maybe 
other interfaces I haven't thought about yet.

The design of this library has not started yet. If you are interested in 
helping out, I would love to have some feedback on what are your use 
cases for WSM.

##### POSIX security backend

Most users run their computers without Mandatory Access Control (MAC), 
it is thus important to provide the best security possible by default. 
The POSIX security backend shouldn't depend on any decision engine or 
MAC system (such as SELinux, Tomoyo, AppArmor, ...) and should be easy 
to configure.

A default policy could be specified in ``/etc/wayland/security.conf``. 
Per-client configuration could be stored in 
``/etc/wayland/authorized_clients.d/``. This would allow package 
managers to install application security policies along with the 
application. Each application-specific policy would define the full path 
of the allowed binary and which restricted interface the application 
needs to get access to and in which cases is it acceptable (only when 
run by the compositor? etc...). This is enables Trusted Path Execution 
(TPE) as only the binary specified by the fullpath will match this set 
of privileges.

Different UNIX users should be allowed to have different security 
parameters. The easiest way would be to store per-user configuration in 
different files in ``/etc/wayland/users.d/`` in order to simplify the 
logic. Another possibility would be to have ``~/.wayland/`` overriding 
the ``/etc/wayland/`` configuration folder. The latter solution would be 
harder to implement securely because only the compositor should be 
allowed to change the configuration.

In any case, to be considered valid, configuration files should all be 
root-owned and 644 to prevent malicious applications from changing the 
security policy. This means changing the security policy will be 
considered as an administrative task which sounds about right.

##### Other security backends?

Other security backends could be implemented/integrated with 
[Polkit]( or 
[SELinux]( You could even write 
your own security backend without needing to patch any Wayland 
compositor, unless you need new WSM hooks.

Please let me know about what security backend you would be interested in!

More information about the wayland-devel mailing list