The status of Wayland security

Unlike its predecessor, X, Wayland was created with an eye toward security. In part, that is due to the threat landscape present at the time each was created—the twenty-first century is a much more dangerous time. While Wayland is designed to provide confidentiality and integrity, there are times when applications will need or want to circumvent those protections. How to safely allow that is the topic of some recent postings to the wayland-devel mailing list.

The discussion started back at the end of December in a thread on authorizing clients to use restricted interfaces for accessibility and other tools, though it had been touched on in the context of screen-grabbing applications even earlier. In mid-February, Martin Peres summarized the discussion thus far both on the mailing list and on his blog. He also referred back to a talk that he and Timothée Ravier gave at the 2012 X.Org Developer Conference. The current state of Wayland input security is good, Peres said, and there is work in progress for its output security, but it is the mechanisms to allow applications to violate those security constraints (under user control) that are still being worked out.

Unlike X, the Wayland input stack doesn't allow applications to snoop on the input of other programs (preserving confidentiality), to generate input events that appear to come from the user (preserving input integrity), or to capture all the input events to the exclusion of the user's application (preserving availability). Wayland clients are still susceptible to LD_PRELOAD-style attacks, but that is not something the Wayland protocol itself can preclude. It is no different than the situation with X clients today, though, so existing solutions can presumably be reused.

On the output side, Wayland does a lot better than X, in general, but there is still some work to do. The use of "graphics execution manager" (GEM) buffers between the client and server is known to be problematic because buffers are identified by 32-bit handles; any program that can guess a buffer's handle can access the buffer itself. Work has been done in Wayland to use DMA-buf sharing, which does not suffer from the same confidentiality and integrity problems because it relies on file descriptor passing, rather than a globally visible handle. In Mesa 10.0, released in November 2013, the Wayland client EGL code does have support for secure DMA-buf sharing.

But there is still the question of what to do about programs that need to circumvent some of those protections. For example, virtual keyboards need to be able to generate input events, screen readers and screen shot programs need to get access to the output buffers, screen lockers need to capture all input, and so on. As Peres put it, if users don't have the ability to allow these actions "people may refuse to use Wayland because it 'takes freedom away from them'".

There are two different ways to achieve the goal of letting users (broadly defined to include distributions as well) break the security barriers: either static capability-like assignment to binaries, or determining the user's intent at runtime. Peres thinks that both should be implemented for Wayland. In addition, he sees a need for users to be able to determine whether any programs are currently running with elevated Wayland permissions (via static assignment) and to revoke those permissions if so.

Clients requiring extra privileges can be launched by the compositor so that it can provide a known, secure environment for those programs. A file descriptor of a socket that will allow the client to connect back to the compositor can be passed to the client using the WAYLAND_SOCKET environment variable. The actual descriptor is inherited by the client across the fork() and exec() calls, but its integer value is passed via the environment. Since the compositor has opened the socket to itself, and controls which client is executed, it can apply any privileges that have been assigned to the client to any operations made over that socket.

Handling the security policy for programs is a difficult problem. Different types of users and distributions will want to be able to implement their own policies. As we have seen with the Linux kernel, finding consensus on security policies is somewhere between really difficult and impossible. Peres expects to see the equivalent of the modular approach taken by Linux Security Modules (LSMs) for Wayland (perhaps Wayland Security Modules or WSMs). That way, different kinds of Wayland consumers will be able to choose a policy framework, much like distributions today choose SELinux, Smack, AppArmor, or to create their own.

Peres has plans to start working on WSMs (or whatever the name ends up being) soon. He has outlined some of the considerations that would need to go into a cross-compositor security framework as part of the discussion. It is a wide-open topic, in many ways, and one that is in its earliest planning stages; those interested in those kinds of problems (and their solutions) should probably get involved.

As can be seen, Wayland starts from a much stronger security position than X, but that doesn't mean that all of the work is done. Beyond the inevitable bugs, there are still some fundamental issues to consider—and work on.