XDC2012: Graphics stack security

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate thiscontent and would like to see more of it, your subscription willhelp to ensure that LWN continues to thrive. Please visitthis page to join up and keep LWN onthe net.

Martin Peres and Timothée Ravier's session on day one of XDC2012 lookedat security in the graphics stack. They considered user expectations aroundsecurity in the graphical user interface (GUI), reviewed these expectationsagainst the implementations in X11 and Weston (the reference compositingwindow manager for Wayland), and covered some other ground as well. Martinbegan their presentation by noting that they had done quite a bit ofresearch on the topic, and although they are Linux security engineersrather than X developers, he expected that they would nevertheless haveuseful things to tell the audience.

User security expectations and the X server

Martin began with a review of security on the X server that focused onthe three classical areas: confidentiality, integrity, and availability.In each case, he described security weaknesses in the X server.

Starting with confidentiality issues, Martin used the example of a userentering a credit card number while shopping online. In this case, thecredit card number could be stolen if a key logger was running on themachine, or another program was taking screen shots periodically. Thisviolates the user's expectations of the GUI: applications should not beable to spy on each other's input events or output buffers. From theuser's point of view, the only time that arbitrary applications shouldobtain information from one another is under explicit user control (forexample, cut-and-paste). However, under X11, any application that canprovide themagiccookie generated by the X server has full access to other applications'input and output. In other words, X11 provides isolation only betweenusers, not between applications run by the same user. Thus, anyapplication that is launched by the user has the potential to breakconfidentiality in the manner of the credit card example.

Martin's second example concerned application integrity. A uservisits a bank web site, and, being a sophisticated user, carefully checksthat the URL shown in the browser's address bar shows "https" plus thecorrect domain. However, the user is unaware that they are visiting a fakedomain, and that the browser's address bar has been redrawn by a maliciousapplication. Consequently, the user's bank information is passed to athird party. This can happen under X11's Digital Rendering Infrastructure(DRI) version 1. (This problem is addressed in DRI2, which has been thedefault for a few years now.) In addition, virtual keyboards can injectinput to the X server; since the X server broadcasts input events, thevirtual-keyboard input can reach any application (just like a realkeyboard).

Martin's third point was that applications should not be able to makeother applications or the entire system unavailable. Under X11,applications can, however, act as screen lockers, denying access to thesystem. In addition, in the past, a virtual keyboard was able to killother applications using theXF86ClearGrab feature that wasintroduced in X server 1.11 (a feature that led toa high-profile security flaw that made itpossible to break into a screen-locked system by typing a particular keycombination).

Mitigating X server security issues

At this point, Timothée took the lead to discuss techniques that havebeen developed to mitigate these security problems. The first of theapproaches that he described wasXSELinux. XSELinuxprovides finer-grained control within the X server, allowing control overfeatures such as drag-and-drop or access to the mouse. However, the levelof control provided by XSELinux is still too coarse-grained to be useful:it allows per-application control of access to X features, but cannot (forexample) restrict input to the currently selected application.Consequently, it is either not provided, or disabled, in mostdistributions. A sometimes recommended alternative for confiningapplications that use the X server isXephyr, whichimplements sandboxing by launching an X server inside another Xserver. Although this provides a good degree of isolation betweenapplications in different sandboxes, a sandboxing solution has problems ofits own: it becomes complicated to share information between applicationsin different sandboxes.

Timothée went on to describe two projects that have tried, in differentways, to bring greater security to the X server: QubesOS and PIGA-OS.Both of these projects aim to confine applications, control whichapplications can access input buffers of other applications, and so on.

QubesOS groups applications into"domains" that have similar levels of security. Each domain runs its Xserver in a separate Xen virtual machine. For example, surfing the web ina browser would be conducted in a low-security domain, while readingcorporate email is done in a separate, higher-securitydomain. Functionality such as cut-and-paste and drag-and-drop betweendomains is provided by means of a daemon that runs in the privileged dom0virtual machine that implements mandatory access control. QubesOS providesa high degree of isolation between applications.

However, Timothée described a number of drawbacks to QubesOS. It requiresmany virtual machines, which results in slow performance on desktop andlaptop systems. It is not feasible on mobile systems, because of heavyresource-usage requirements and the almost-mandatory requirement forhardware-assisted virtualization in order to achieve satisfactoryperformance. Furthermore, one can't be sure that Xen can isolate virtualmachines, so there might be ways to access buffers in other virtualmachines.

PIGA-OS [PDF], asystem that Martin and Timothée have worked on, takes a different approachfrom QuebesOS. Each application is placed in a separate SELinux domain andXSELinux is used to provide confinement in the X server. SELinux plusXSELinux provide many of the pieces needed for a secure X server, but somepieces are still missing. Therefore, PIGA-OS adds a daemon, PIGA-SYSTRANS,that grants rights to applications and prompts users when they switchbetween different domains as a consequence of their activities.

PIGA-OS has some notable advantages. It does not require virtualmachines. It dynamically adjusts (under user control) the permissions ofapplications according to the user's activity. However, a significantdownside of the PIGA-OS approach is that it requires quite some effort toset up the global SELinux policy that governs applications andactivities. (This is a one-time effort, but the policy must be updated ifan application acquires new features that require new types of privilegedaccess.)

Wayland and Weston

Timothée then turned to the subject of theWayland, the display server protocol positedas a replacement for X11, and Weston, the reference implementation of thecompositing window manager for Wayland. His goal was to look at how Waylandand Weston have fixed some of the problems of the X server described aboveand outline the problems that remain.

Timothée divided up the discussion of security somewhat differently inthis part of the presentation, beginning by talking about the security ofinput in Wayland/Weston. On this front, the new system is in goodshape. Because Weston knows where applications are on the screen, it isable to decide which application should receive input events (this differsfrom the X server). This defeats key logging applications. Regardingintegrity of input, the kernel limits access to the two main sources(/dev/input and/dev/uinput) to the root useronly. Because Wayland/Weston does not (yet) support virtual keyboards it isnot (yet) possible to forge input. (The topic of virtual keyboards wasrevisited later in the talk.)

On the output side, Timothée observed that Weston does have someproblems with confidentiality and integrity. Weston uses theGraphics Execution Manager (GEM) to shareapplication buffers between the compositor and applications. The problemis that GEM buffers are referenced using handles that are 32-bitintegers. These handles can be guessed (or brute-forced), which means thatone application can easily access GEM buffers belonging to otherapplications. Martin noted that this problem would be resolved if and whenWeston moved to the use ofDMABUF (DMA buffersharing).

Timothée then considered how Weston should deal with applications thatneed exceptional handling with respect to security. The first of these thathe covered was virtual keyboards, which are pseudo-devices that arepermitted to send input events to the compositor. He made the general pointthat virtual keyboards should be "included" in the compositor, so that thecompositor knows that it can trust the input they provide. Peter Huttererraised a potential problem: each natural language (with a unique characterset) requires its own virtual keyboard, and it seems that every few monthssomeone starts a new virtual keyboard project for another language, withthe result that adding keyboards to the compositor would be a never-endingtask. In response, Timothée and Martin refined what they meant by"include". The compositor must not trust just any application to be avirtual keyboard. Rather, since the compositor knows which applications itis launching, it can choose which applications it will trust as virtualkeyboards. Peter agreed with this approach but noted that there may be some(solvable) complexities, since, when dealing with a multilingual user, aswitch from one language to another may involve not only a switch ofvirtual keyboards, but also a switch of the background framework thatgenerates input events.

Weston does not yet support screen-shot applications, but when thatsupport is added, some care will be needed to avoid confidentiality issues.Timothée's proposal was similar to that for virtual keyboards: thecompositor would allow only trusted applications that it has launched tomake screen shots. Again, there must be a method for specifying whichapplications the compositor should trust for this task.

Global keyboard shortcuts present a further problem. For example,media players commonly use keyboard shortcuts to provide functionalitysuch as pausing or skipping to the next track. Typically, media players are notvisible on the screen, and so do not receive input eventsdirectly. Therefore the compositor needs a way of registering specialkeystroke combinations and passing these to applications that haveregistered them. The problem is that this sort of functionality can allowthe implementation of a different kind of key logger: a maliciousapplication could register itself for many or all keystrokecombinations. Again, there needs to be a way of specify which applicationsare allowed to register global keyboard shortcuts, and perhaps whichkeystroke combinations they may register. Further complicating the problemis the fact that the user may change the global keyboard shortcuts that anapplication uses. Timothée said they had no solution to offer for thisproblem.

Peter Hutterer suggested what he called a "semantic approach" to theproblem, but noted that it would require a lot more code. Instead ofallowing applications to register keystroke combinations, the compositorwould maintain a global registry where applications would register to saythat they want to be notified for events such as "undo" or "cancel", andthe compositor would control the key that is assigned to the event. Thishas the potential advantage that shortcuts could be consistent acrossapplications. On the other hand, there will likely be conflicts betweenapplications over deciding which events are which. Peter noted that the GTKproject is currently doing some work in this area, and it may be worthcontacting people working on that project.

The situation with screen-locking applications is similar toscreen-shot applications. Currently, Weston does not support screenlocking, but when that support is added, there should be the notion ofhaving a restricted set of applications that the compositor permits to lockthe screen. Indeed, since the screen-locking code is typically small, andthe requirements are fairly narrow (so that there is no need for multipledifferent implementations), it may be sensible to implement thatfunctionality directly inside the compositor.

Timothée summarized the proposals for controlling application securityin Wayland and Weston. There should be a mandatory access control (MAC)framework as in theXAccess Control Extension (XACE). Suitable hooks should be placed in thecode to allow control of which applications can interact with one anotherand interact with Wayland to perform operations such as receivinginput. The MAC framework should be implemented as a library, so that accesscontrol is unified across all Wayland compositors.

Rootless Weston

Timothée ran through some of the factors blocking rootless Weston. Oneproblem is that Weston needs access to/dev/input, which isaccessible only to root. Root privilege is also required to send output tothe screen and to support hot plugging of keyboards and screens. Thesolution he proposed was to isolate the code that requires root privilegesinto a separate small executable that is run with root privileges. In thecase where Weston needed access to a privileged file, the small executablewould then open the required file and pass a file descriptor viaa UNIX domain socket to Weston. There was little comment on this proposal,which may signify that it seemed reasonable to everyone present.

Hardware and driver security

Martin returned to the microphone to talk about hardware and driversecurity. He began with the simple observation that graphics drivers andhardware should not allow privilege escalation (allowing a user to gainroot access) and should not allow one user to read or write graphicsbuffers belonging to another user. Various platforms and drivers don'tlive up to these requirements. For example, on the Tegra 2 platform, theGPU permits shader routines to have full read and write access to all ofthe video RAM or all of the graphics-hosting RAM. Another example is theNVIDIA driver, which provides unprivileged users with access to nearly allof the GPU registers.

Martin emphasized the need for a sane kernel API that isolates GPU users anddoesn't expose GPU registers to unprivileged users. GPU access to RAM alsoneeds to be restricted, in order to prevent the GPU from accessing kerneldata structures. (The lack of such a restriction was the source ofthe recent vulnerability in the NVIDIA driver thatallowed root privilege escalation.)

One approach to isolating GPU users would be to apply a virtual-memorymodel to video memory, so that applications cannot touch each other'smemory. This approach provides the best security, but the problem is thatit is not supported by all graphics hardware. In addition, implementingthis approach increases context-switching times; this is a problem forDRI2, which does a lot of context switching, and for Qt5, where allapplications that use QML (which is the recommended approach) have anOpenGL context. TheNouveaudriver currently takes this approach, and some other modern GPUs are alsocapable of doing so.

An alternative approach for isolating GPU users is for the kernel tovalidate the user commands submitted to the GPU, in order to ensure thatthey touch only memory that belongs to the user. This approach has theadvantage that it can be implemented for any graphics hardware andcontext-switching costs are lower. However, it imposes a higher CPUoverhead. Currently the Radeon and Intel drivers take this approach.

Moving to another topic, Martin observed that a GPU buffer is not zeroedwhen it is allocated, meaning that the previous user's data is visible tothe new user. This could create a confidentiality issue. The problem isthat zeroing buffers has a heavy performance impact. He suggested twostrategies for dealing with this: zeroing deallocated buffers when the CPUis idle and using the GPU to perform zeroing of buffers. Lucas Stachpointed out that even if one of these strategies was employed, on embeddeddevices the memory bandwidth required for zeroing buffers was simply toogreat. Martin accepted the point, and noted that the goal was to allow theuser to choose the trade-off between security and performance.

The final topic of the presentation concerned plug-ins. Since thecompositor has full access to input events and application output buffers,this means that compositor plug-ins potentially have the same access, sothat a (possibly malicious) plug-in could cause a securityvulnerability. Martin said that they didn't have too many concreteproposals on how to deal with this, beyond noting that, whenever possible,plug-ins should not have access to user inputs and output buffers. Hesuggested thataddress-spacelayout randomization inside the GPU virtual memory may help, along withkilling applications that access invalid virtual addresses.

In some concluding discussion at the end of the session, Matthieu Herrbremarked that most X11 applications are not ready to handle errors fromfailed requests to the X server, and that if the graphics server is going toimplement finer-grained access control, then it's important thatapplications have a good strategy for handling the various errors that mayoccur. Martin agreed, adding "We don't want to fix X; it's notpossible. We can't ask people to rewrite [applications]. But with Waylandbeing new, we can do things better from day one."

Summary

From the various comments made during the presentation, it's clear thatthe X developers are well aware of the security problems in X11. It's equallyclear that they are keen to avoid making the same mistakes in Wayland and Weston.

The X.Org wiki haspointersto the slides and video for this presentation, as well aspointersto the slides and video for a follow-on security-related presentation(entitled "DRM2").