.net News from the source
Martin Peres and Timothée Ravier's session on day one of XDC2012 looked at security in the graphics stack. They considered user expectations around security in the graphical user interface (GUI), reviewed these expectations against the implementations in X11 and Weston (the reference compositing window manager for Wayland), and covered some other ground as well. Martin began their presentation by noting that they had done quite a bit of research on the topic, and although they are Linux security engineers rather than X developers, he expected that they would nevertheless have useful things to tell the audience.
Martin began with a review of security on the X server that focused on the 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 user entering a credit card number while shopping online. In this case, the credit card number could be stolen if a key logger was running on the machine, or another program was taking screen shots periodically. This violates the user's expectations of the GUI: applications should not be able to spy on each other's input events or output buffers. From the user's point of view, the only time that arbitrary applications should obtain information from one another is under explicit user control (for example, cut-and-paste). However, under X11, any application that can provide the magic cookie generated by the X server has full access to other applications' input and output. In other words, X11 provides isolation only between users, not between applications run by the same user. Thus, any application that is launched by the user has the potential to break confidentiality in the manner of the credit card example.
Martin's second example concerned application integrity. A user visits a bank web site, and, being a sophisticated user, carefully checks that the URL shown in the browser's address bar shows "https" plus the correct domain. However, the user is unaware that they are visiting a fake domain, and that the browser's address bar has been redrawn by a malicious application. Consequently, the user's bank information is passed to a third party. This can happen under X11's Digital Rendering Infrastructure (DRI) version 1. (This problem is addressed in DRI2, which has been the default for a few years now.) In addition, virtual keyboards can inject input to the X server; since the X server broadcasts input events, the virtual-keyboard input can reach any application (just like a real keyboard).
Martin's third point was that applications should not be able to make other applications or the entire system unavailable. Under X11, applications can, however, act as screen lockers, denying access to the system. In addition, in the past, a virtual keyboard was able to kill other applications using the XF86ClearGrab feature that was introduced in X server 1.11 (a feature that led to a high-profile security flaw that made it possible to break into a screen-locked system by typing a particular key combination).
At this point, Timothée took the lead to discuss techniques that have been developed to mitigate these security problems. The first of the approaches that he described was XSELinux. XSELinux provides finer-grained control within the X server, allowing control over features such as drag-and-drop or access to the mouse. However, the level of control provided by XSELinux is still too coarse-grained to be useful: it allows per-application control of access to X features, but cannot (for example) restrict input to the currently selected application. Consequently, it is either not provided, or disabled, in most distributions. A sometimes recommended alternative for confining applications that use the X server is Xephyr, which implements sandboxing by launching an X server inside another X server. Although this provides a good degree of isolation between applications in different sandboxes, a sandboxing solution has problems of its own: it becomes complicated to share information between applications in different sandboxes.
Timothée went on to describe two projects that have tried, in different ways, to bring greater security to the X server: QubesOS and PIGA-OS. Both of these projects aim to confine applications, control which applications 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 X server in a separate Xen virtual machine. For example, surfing the web in a browser would be conducted in a low-security domain, while reading corporate email is done in a separate, higher-security domain. Functionality such as cut-and-paste and drag-and-drop between domains is provided by means of a daemon that runs in the privileged dom0 virtual machine that implements mandatory access control. QubesOS provides a high degree of isolation between applications.
However, Timothée described a number of drawbacks to QubesOS. It requires many virtual machines, which results in slow performance on desktop and laptop systems. It is not feasible on mobile systems, because of heavy resource-usage requirements and the almost-mandatory requirement for hardware-assisted virtualization in order to achieve satisfactory performance. Furthermore, one can't be sure that Xen can isolate virtual machines, so there might be ways to access buffers in other virtual machines.
PIGA-OS [PDF], a system that Martin and Timothée have worked on, takes a different approach from QuebesOS. Each application is placed in a separate SELinux domain and XSELinux is used to provide confinement in the X server. SELinux plus XSELinux provide many of the pieces needed for a secure X server, but some pieces are still missing. Therefore, PIGA-OS adds a daemon, PIGA-SYSTRANS, that grants rights to applications and prompts users when they switch between different domains as a consequence of their activities.
PIGA-OS has some notable advantages. It does not require virtual machines. It dynamically adjusts (under user control) the permissions of applications according to the user's activity. However, a significant downside of the PIGA-OS approach is that it requires quite some effort to set up the global SELinux policy that governs applications and activities. (This is a one-time effort, but the policy must be updated if an application acquires new features that require new types of privileged access.)
Timothée then turned to the subject of the Wayland, the display server protocol posited as a replacement for X11, and Weston, the reference implementation of the compositing window manager for Wayland. His goal was to look at how Wayland and Weston have fixed some of the problems of the X server described above and outline the problems that remain.
Timothée divided up the discussion of security somewhat differently in this part of the presentation, beginning by talking about the security of input in Wayland/Weston. On this front, the new system is in good shape. Because Weston knows where applications are on the screen, it is able to decide which application should receive input events (this differs from the X server). This defeats key logging applications. Regarding integrity of input, the kernel limits access to the two main sources (/dev/input and /dev/uinput) to the root user only. Because Wayland/Weston does not (yet) support virtual keyboards it is not (yet) possible to forge input. (The topic of virtual keyboards was revisited later in the talk.)
On the output side, Timothée observed that Weston does have some problems with confidentiality and integrity. Weston uses the Graphics Execution Manager (GEM) to share application buffers between the compositor and applications. The problem is that GEM buffers are referenced using handles that are 32-bit integers. These handles can be guessed (or brute-forced), which means that one application can easily access GEM buffers belonging to other applications. Martin noted that this problem would be resolved if and when Weston moved to the use of DMABUF (DMA buffer sharing).
Timothée then considered how Weston should deal with applications that need exceptional handling with respect to security. The first of these that he covered was virtual keyboards, which are pseudo-devices that are permitted to send input events to the compositor. He made the general point that virtual keyboards should be "included" in the compositor, so that the compositor knows that it can trust the input they provide. Peter Hutterer raised a potential problem: each natural language (with a unique character set) requires its own virtual keyboard, and it seems that every few months someone starts a new virtual keyboard project for another language, with the result that adding keyboards to the compositor would be a never-ending task. In response, Timothée and Martin refined what they meant by "include". The compositor must not trust just any application to be a virtual keyboard. Rather, since the compositor knows which applications it is launching, it can choose which applications it will trust as virtual keyboards. Peter agreed with this approach but noted that there may be some (solvable) complexities, since, when dealing with a multilingual user, a switch from one language to another may involve not only a switch of virtual keyboards, but also a switch of the background framework that generates input events.
Weston does not yet support screen-shot applications, but when that support is added, some care will be needed to avoid confidentiality issues. Timothée's proposal was similar to that for virtual keyboards: the compositor would allow only trusted applications that it has launched to make screen shots. Again, there must be a method for specifying which applications the compositor should trust for this task.
Global keyboard shortcuts present a further problem. For example, media players commonly use keyboard shortcuts to provide functionality such as pausing or skipping to the next track. Typically, media players are not visible on the screen, and so do not receive input events directly. Therefore the compositor needs a way of registering special keystroke combinations and passing these to applications that have registered them. The problem is that this sort of functionality can allow the implementation of a different kind of key logger: a malicious application could register itself for many or all keystroke combinations. Again, there needs to be a way of specify which applications are allowed to register global keyboard shortcuts, and perhaps which keystroke combinations they may register. Further complicating the problem is the fact that the user may change the global keyboard shortcuts that an application uses. Timothée said they had no solution to offer for this problem.
Peter Hutterer suggested what he called a "semantic approach" to the problem, but noted that it would require a lot more code. Instead of allowing applications to register keystroke combinations, the compositor would maintain a global registry where applications would register to say that they want to be notified for events such as "undo" or "cancel", and the compositor would control the key that is assigned to the event. This has the potential advantage that shortcuts could be consistent across applications. On the other hand, there will likely be conflicts between applications over deciding which events are which. Peter noted that the GTK project is currently doing some work in this area, and it may be worth contacting people working on that project.
The situation with screen-locking applications is similar to screen-shot applications. Currently, Weston does not support screen locking, but when that support is added, there should be the notion of having a restricted set of applications that the compositor permits to lock the screen. Indeed, since the screen-locking code is typically small, and the requirements are fairly narrow (so that there is no need for multiple different implementations), it may be sensible to implement that functionality directly inside the compositor.
Timothée summarized the proposals for controlling application security in Wayland and Weston. There should be a mandatory access control (MAC) framework as in the X Access Control Extension (XACE). Suitable hooks should be placed in the code to allow control of which applications can interact with one another and interact with Wayland to perform operations such as receiving input. The MAC framework should be implemented as a library, so that access control is unified across all Wayland compositors.
Timothée ran through some of the factors blocking rootless Weston. One problem is that Weston needs access to /dev/input, which is accessible only to root. Root privilege is also required to send output to the screen and to support hot plugging of keyboards and screens. The solution he proposed was to isolate the code that requires root privileges into a separate small executable that is run with root privileges. In the case where Weston needed access to a privileged file, the small executable would then open the required file and pass a file descriptor via a UNIX domain socket to Weston. There was little comment on this proposal, which may signify that it seemed reasonable to everyone present.
Martin returned to the microphone to talk about hardware and driver security. He began with the simple observation that graphics drivers and hardware should not allow privilege escalation (allowing a user to gain root access) and should not allow one user to read or write graphics buffers belonging to another user. Various platforms and drivers don't live up to these requirements. For example, on the Tegra 2 platform, the GPU permits shader routines to have full read and write access to all of the video RAM or all of the graphics-hosting RAM. Another example is the NVIDIA driver, which provides unprivileged users with access to nearly all of the GPU registers.
Martin emphasized the need for a sane kernel API that isolates GPU users and doesn't expose GPU registers to unprivileged users. GPU access to RAM also needs to be restricted, in order to prevent the GPU from accessing kernel data structures. (The lack of such a restriction was the source of the recent vulnerability in the NVIDIA driver that allowed root privilege escalation.)
One approach to isolating GPU users would be to apply a virtual-memory model to video memory, so that applications cannot touch each other's memory. This approach provides the best security, but the problem is that it is not supported by all graphics hardware. In addition, implementing this approach increases context-switching times; this is a problem for DRI2, which does a lot of context switching, and for Qt5, where all applications that use QML (which is the recommended approach) have an OpenGL context. The Nouveau driver currently takes this approach, and some other modern GPUs are also capable of doing so.
An alternative approach for isolating GPU users is for the kernel to validate the user commands submitted to the GPU, in order to ensure that they touch only memory that belongs to the user. This approach has the advantage that it can be implemented for any graphics hardware and context-switching costs are lower. However, it imposes a higher CPU overhead. Currently the Radeon and Intel drivers take this approach.
Moving to another topic, Martin observed that a GPU buffer is not zeroed when it is allocated, meaning that the previous user's data is visible to the new user. This could create a confidentiality issue. The problem is that zeroing buffers has a heavy performance impact. He suggested two strategies for dealing with this: zeroing deallocated buffers when the CPU is idle and using the GPU to perform zeroing of buffers. Lucas Stach pointed out that even if one of these strategies was employed, on embedded devices the memory bandwidth required for zeroing buffers was simply too great. Martin accepted the point, and noted that the goal was to allow the user to choose the trade-off between security and performance.
The final topic of the presentation concerned plug-ins. Since the compositor has full access to input events and application output buffers, this means that compositor plug-ins potentially have the same access, so that a (possibly malicious) plug-in could cause a security vulnerability. Martin said that they didn't have too many concrete proposals on how to deal with this, beyond noting that, whenever possible, plug-ins should not have access to user inputs and output buffers. He suggested that address-space layout randomization inside the GPU virtual memory may help, along with killing applications that access invalid virtual addresses.
In some concluding discussion at the end of the session, Matthieu Herrb remarked that most X11 applications are not ready to handle errors from failed requests to the X server, and that if the graphics server is going to implement finer-grained access control, then it's important that applications have a good strategy for handling the various errors that may occur. Martin agreed, adding "We don't want to fix X; it's not possible. We can't ask people to rewrite [applications]. But with Wayland being new, we can do things better from day one."
From the various comments made during the presentation, it's clear that the X developers are well aware of the security problems in X11. It's equally clear that they are keen to avoid making the same mistakes in Wayland and Weston.
The X.Org wiki has pointers to the slides and video for this presentation, as well as pointers to the slides and video for a follow-on security-related presentation (entitled "DRM2").
XDC2012: Graphics stack security
Posted Sep 25, 2012 22:25 UTC (Tue) by JohnLenz (subscriber, #42089) [Link]
This has the advantage of using already existing authentication infrastructure (policykit) and not force weston to define an explicit list of events.
XDC2012: Graphics stack security
Posted Sep 26, 2012 13:52 UTC (Wed) by mupuf (subscriber, #86890) [Link]
However, a lot of work is left to be done on all this matter. We don't pretend to understand every valid use cases and the need of every applications so I may not be able to understand your point.
XDC2012: Graphics stack security
Posted Sep 26, 2012 11:23 UTC (Wed) by k3ninho (subscriber, #50375) [Link]
Is that 'zero-ing when not busy' actually a request for an in-kernel TRIM thread? Such a thread might also need to make promises about when its work eventually gets done, but that could be mitigated with a fallback plan for a on a busy system: explicitly wipe the memory before it's re-used. Do I hear "show me the code"?
Ken.
XDC2012: Graphics stack security
Posted Sep 26, 2012 13:43 UTC (Wed) by mupuf (subscriber, #86890) [Link]
The wiping process should be run on the whole VRAM at boot time and then can be scheduled when the pool of wiped pages is getting low. This should lower the number of wiping and thus, lower the VRAM bandwidth usage.
I expect the performance-impact to be minimal in most cases. However, it makes the allocation more complicated and more memory-consuming.
On the other hand, if we want all buffers to be wiped at allocation time, then we can lower the allocation complexity at the expense of memory-bandwidth usage (more wiping are needed).
XDC2012: Graphics stack security
Posted Sep 26, 2012 16:16 UTC (Wed) by gioele (subscriber, #61675) [Link]
A more general question: why are GPUs being treated differently from CPUs or coprocessors? We are there: GPUs need scheduling, process compartmentalisation, per-user limits, and so on, just like CPUs. It looks like people are reinventing everything on GPUs instead of just extending the existing concepts (if not code) to GPUs.
XDC2012: Graphics stack security
Posted Sep 26, 2012 16:42 UTC (Wed) by mupuf (subscriber, #86890) [Link]
In the end, we are "reinventing the wheel" but the concepts still holds (I didn't have the idea overnight for VRAM sanitization). However, the code is completely different because GPUs are more complex than CPUs.
As for why GPUs aren't considered like CPUs, the reason is that they are built for throughput and aren't ready for being considered as a new processor (allmost no GPUs support preemption). We are slowly but surely going towards this direction but it is too early for us to design an API that would accommodate for both CPUs and GPUs.
In the end, we can say that we indeed extend the already-existing CPU concepts to GPUs but it takes time and the GPU ecosystem is much fragmented than the CPU world. Moreover, most GPUs (if not all), aren't ready to be considered as an equivalent of the x86 (not even remotely).
XDC2012: Graphics stack security
Posted Sep 27, 2012 16:37 UTC (Thu) by ortalo (subscriber, #4654) [Link]
But even if common hardware protection features are not (uniformly at least) available on GPUs, from what we know about other hardware, it seems that memory protection and priviledged instructions are foundational features for practical security mechanisms.
If these features are not in the hardware I wonder if it's even possible to adress the issue of graphics stack security for multiple applications without:
1) either emulating them (something which apparently has started to appear but does not seem to be universally agreed upon);
2) or evolving the security model to adress a different kind of security features (for example: forbidd applications with conflicting security requirement to use the same "screen").
By the way, maybe option 2 is really workable in the context of graphical applications. Maybe there is a need for a risk/attacks analysis at a higher level and more thinking about the most important security features in order to provide a decent (if not completely satisfactory) implementation.
For example, I would not mind trading a long context switch time (~1s) for access to full hardware control for a fullscreen application (game) while I may be reluctant to do that for a text editor and framebuffer security may even be a reason not to use a GUI for an encryption tool.
XDC2012: Graphics stack security
Posted Sep 26, 2012 17:00 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
you want to be able to do screenshots, or even create a video of what you are doing.
you want to be able to have one application take over the screen and not let you do anything else, without that you couldn't have 'screensavers' that are also session locks. Kiosk mode for applications could not be done, etc.
virtual keyboards are extremely useful in some cases.
the problem isn't the capability for _some_ program to do these things, it's the capability for _any_ program to do these things.
you shouldn't have to through out the capability to do these things, just change the control.
X already requires the "magic cookie", so there is enough mechanism in place to allow this to work, we just need to change things so that you don't use the same cookie for every app, and don't give every cookie the same permissions.
It would be best if this ability wasn't tied to SELinux (I'm not sure if XSELinux is, or is just a similar name)
XDC2012: Graphics stack security
Posted Sep 26, 2012 17:50 UTC (Wed) by luto (subscriber, #39314) [Link]
IMO this belongs in the compositor, not as a separate application. Screensavers / screenlockers are fragile and buggy on X right now [1][2].
If the (Wayland-style) compositor handled screen locking, then, if the compositor crashed, you're still secure -- the whole session goes away.
[1] See, for example, the old bug where funny key combos caused the screen to unlock.
[2] On the machine I'm typing on, sometimes the password prompt is completely invisible, and it's quite common for the unlocked screen to flash above the screen locker when DPMS comes back.
That being said, I mostly agree with the rest of your comments. File descriptors might be a nicer way to handle permissions than magic cookies, though.
XDC2012: Graphics stack security
Posted Sep 26, 2012 19:04 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
the 'funny key combos cause the screen to unlock' were not an accident, that was a deliberate feature for debugging that accidently got enabled by default.
as one of those people who routinely uses X remotely, file descriptors have a significant problem ;-). There's nothing inherently wrong with cookies, just with the permissions being the same for all apps from a single user.
XDC2012: Graphics stack security
Posted Sep 26, 2012 20:03 UTC (Wed) by luto (subscriber, #39314) [Link]
Or the compositor could have specific support for pluggable screensavers. In any case, I think that the Wayland compositor will end up being more line gnome-shell than compiz, so you may not have a choice anyway.
> the 'funny key combos cause the screen to unlock' were not an accident, that was a deliberate feature for debugging that accidently got enabled by default.
Except that it was a feature to release screen grabs, which ought to be harmless for anything except screen lockers.
> as one of those people who routinely uses X remotely, file descriptors have a significant problem ;-). There's nothing inherently wrong with cookies, just with the permissions being the same for all apps from a single user.
Presumably this will get solved the same way as the rest of Wayland remoting which, AIUI, doesn't really exist right now. Maybe magic cookies would still be better for the remoting server, whatever it is, to tell what privileges its clients have.
XDC2012: Graphics stack security
Posted Sep 28, 2012 9:15 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
If you put the cookie in a file in the user's home directory, as is done for the current X server cookies then yes. If you imagine different cookies for different privileges (reading from the screen, sending input events, whatever) there is no reason why there should not be different mechanisms for the clients which need them to obtain them. For example you could put them in global files readable only to a particular user group, or you could use DBus and PolicyKit to pass them (just an example, as I know that DBus and remote X don't get along very well at present), or even both.
XDC2012: Graphics stack security
Posted Sep 28, 2012 19:13 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
putting the cookie in one file and having all apps read it from that file would seem to match my criteria for a problem.
But there's nothing saying that you couldn't have a different cookie for each app, and then give different cookies different permissions.
this wouldn't be a matter of 'user this cookie for screenshots' type of thing, but a matter of 'application X was given cookie Y, application X is a screenshot app, so allow cookie Y to do screenshots'
Assuming apps do something sane and only read this cookie once at startup, you could replace the file they read it from with something that's an interface to an application that can use SCM_CREDENTIALS to find out what app is talking to it, and return different contents to different apps. You can then have that program either give a different cookie to every app, or make whatever policy decisions it wants about what cookies to give to different apps.
XDC2012: Graphics stack security
Posted Sep 28, 2012 19:28 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
Quite right; in fact my mind was on the track of SETGID or similar applications, but thinking again that is probably not such a great idea in this context.
XDC2012: Graphics stack security
Posted Oct 1, 2012 4:27 UTC (Mon) by raven667 (subscriber, #5198) [Link]
As I recall xscreensaver supports its different timewasters by each being an external program from the main screen lock, it would seem that a lock implemented in the compositor would likely operate the same way. The screen lock itself has a very well defined function and UI and could easily be hardwired in, especially if that gets rid of a bunch of failure cases.
XDC2012: Graphics stack security
Posted Sep 26, 2012 17:51 UTC (Wed) by dpquigl (guest, #52852) [Link]
XDC2012: Graphics stack security
Posted Sep 26, 2012 23:43 UTC (Wed) by mupuf (subscriber, #86890) [Link]
The point of the presentation wasn't to fix X, it was to fix DRM, to talk about security in Wayland and discuss about a security policy for it.
XDC2012: Graphics stack security
Posted Sep 27, 2012 0:15 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
While I expect that doing checks on these half dozen or so 'special' priviledges would break a few things, I don't think it would be that many, and if the capaibility was available, distros would experiment with them.
After all, we know that SELinux breaks things, but it's being deployed. I would expect that SELinux has broken far more things than a handful of permission checks in X would.
> The point of the presentation wasn't to fix X, it was to fix DRM
this writeup makes it sound like it was talking about problems in X not in the DRM layer.
XDC2012: Graphics stack security
Posted Sep 27, 2012 9:56 UTC (Thu) by Siosm (subscriber, #86882) [Link]
I don't think we will be able to fix the input problems in X.
> After all, we know that SELinux breaks things, but it's being deployed. I would expect that SELinux has broken far more things than a handful of permission checks in X would.
SELinux is mostly used in a "targeted" way in Red Hat/Fedora, and thus does not protect GUI apps. It is a lot of work to create and maintain an SELinux policy for every GUI applications.
> this writeup makes it sound like it was talking about problems in X not in the DRM layer.
The second talk deals with DRM problems. This one was done to recap known problems and make sure we do not do the same "mistakes" with Wayland/Weston
XDC2012: Graphics stack security
Posted Oct 1, 2012 4:33 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Most SELinux permissions checks happen where applications should already expect them to be occurring such as on filesystem objects. Putting in permissions where there weren't any before and where there is a lot of backwards compatibility requirements for very old software seems like a very bad idea and quite likely to break the world.
XDC2012: Graphics stack security
Posted Sep 26, 2012 19:06 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
Server-side window decorations have the potential to label each window as to what app it is part of (users may still ignore the data, but at least it can't be faked by the app)
but if you either allow the client to tell the server what to label a window, or do client-side decorations where the client is in full control, it's impossible for the user to be able to trust any window completely.
XDC2012: Graphics stack security
Posted Sep 26, 2012 23:59 UTC (Wed) by mupuf (subscriber, #86890) [Link]
As you said, this is fixable with server-side decoration rendering but it isn't when the client renders everything. I guess we could actually display the name of the binary in the compositor when hovering the mouse on top of the application bar but that's not obvious to most users.
XDC2012: Graphics stack security
Posted Oct 1, 2012 4:38 UTC (Mon) by raven667 (subscriber, #5198) [Link]
IIUC applications can set their window title or argv[0] to anything they want and I don't think that's a feature that would likely be dropped making the point moot.
XDC2012: Graphics stack security
Posted Oct 1, 2012 8:51 UTC (Mon) by renox (subscriber, #23785) [Link]
And in a secure environement with server side decoration, this application's provided tittle can either be ignored or be added in addition to a color or text which provide the server's view of the application.
That said, one could have virtual desktop/environment which would group application by security level even with client side decoration, of course for single applications this is annoying..
XDC2012: Graphics stack security
Posted Sep 26, 2012 19:11 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
what if you are trying to create a video to demonstrate how to use the bank website?
This is why the mantra "provide mechanism not policy" exists.
XDC2012: Graphics stack security
Posted Sep 26, 2012 19:35 UTC (Wed) by jg (subscriber, #17537) [Link]
XDC2012: Graphics stack security
Posted Sep 26, 2012 21:24 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
Just don't make the mistake of thinking that those common use cases are the only use cases.
I remember listening to you talk at some USENIX event a decade or so ago and talking about all the new things that were popping up on desktop systems (transparent terminal windows and similar IIRC) and you commented that when developing X you not only never considered such things, but if asked you would have said that it wasn't possible.
Because the mechanism was flexible enough, new things that the initial developers never imagined were possible.
It seems like a lot of people have forgotten that.
Ubuntu is the force that it is today, not because they were doing any hard technical things that nobody else was doing, but in large part because they were offering sane defaults (with some technical effort in automating configs and device detection) that nobody else was doing at the time.
XDC2012: Graphics stack security
Posted Sep 27, 2012 10:03 UTC (Thu) by Siosm (subscriber, #86882) [Link]
As said in the article, the goal in not to prevent people from adding things to Wayland/Weston, but to deny access to security-related features by default, and to provide a way for distribution/developers to make sure access to those features is allowed, by default, only the applications really requiring it, not just any application.
XDC2012: Graphics stack security
Posted Sep 26, 2012 20:18 UTC (Wed) by raven667 (subscriber, #5198) [Link]
XDC2012: Graphics stack security
Posted Sep 26, 2012 23:40 UTC (Wed) by mupuf (subscriber, #86890) [Link]
Well, I'm not in violent agreement with one them, I am one of them (Martin Peres). I'm here to clarify our views if needed.
XDC2012: Graphics stack security
Posted Oct 1, 2012 3:54 UTC (Mon) by raven667 (subscriber, #5198) [Link]
XDC2012: Graphics stack security
Posted Sep 27, 2012 10:44 UTC (Thu) by dgm (subscriber, #49227) [Link]
Having insecure input and output, _in_addition_ to secure ones, is clearly desirable and good.
Let applications chose.
XDC2012: Graphics stack security
Posted Sep 27, 2012 13:42 UTC (Thu) by mupuf (subscriber, #86890) [Link]
It's like saying that applications should be able to decide if they want raw access to disks or not. Willing to do so is suicidal.
XDC2012: Graphics stack security
Posted Sep 27, 2012 14:50 UTC (Thu) by Siosm (subscriber, #86882) [Link]
If it's not enabled by default, nobody will use it because it won't get testing and bugs won't be fixed.
> By locking down applications we make them less useful.
Only a very limited set of applications has to be "locked down" in the Wayland/Weston case. Any "classic" application won't even notice the change.
> Think for instance what will happen if the Unix shell mandated integrity of input or confidentiality of output for all programs: pipes would be impossible.
This is hardly comparable. On a classic *nix system, you use different users to separate tasks which should not interact with each others. Communications channels between users (pipes...) must be explicitly created, most of the time by the most privileged user. Without MAC (Mandatory Access Control) there is no confinement between applications from the same user.
With GUI applications, everything runs under the same user, so we can not rely on user separation anymore. In the Wayland/Weston case, only explicit user controlled channels allow interactions between applications (drag&drop, copy&paste).
> Having insecure input and output, _in_addition_ to secure ones, is clearly desirable and good.
Again, people will naturally choose the easy way over the hard way.
In order to work, security has to be default built-in design feature which should make common operation easy, and control uncommon operations.
XDC2012: Graphics stack security
Posted Sep 28, 2012 10:34 UTC (Fri) by dgm (subscriber, #49227) [Link]
Sorry for the harsh words, but this is the LAMEST possible argument you could make. If it was useful for someone people would use it. If it's not used it's because it's not useful, so we're all better without it.
This strategy did not work all that well for GNOME, please do not repeat this mistake again.
> Only a very limited set of applications has to be "locked down" in the Wayland/Weston case. Any "classic" application won't even notice the change.
Nope, you got it wrong. Take virtual keyboards, for instance. Currently they are not possible in Wayland because it has been decided that the compositor should not touch input in any way, applications receive it directly from the kernel. This decision effectively locks down _all_ applications, even those for which input integrity is of no use.
> With GUI applications, everything runs under the same user
This does not need to be this way.
> Without MAC (Mandatory Access Control) there is no confinement between applications from the same user.
And that is, the ability to pass information between applications, is what makes them useful. What we need is a mechanism to confine _selected_ applications.
> Again, people will naturally choose the easy way over the hard way.
True. Also, people chose what works over what does not.
XDC2012: Graphics stack security
Posted Sep 28, 2012 21:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
And that's good. You can implement a virtual keyboard right way, by writing a CUSE driver. This way every app in the system will be able to access it. Or you can extend the compositor to do this.
XDC2012: Graphics stack security
Posted Oct 1, 2012 4:08 UTC (Mon) by raven667 (subscriber, #5198) [Link]
It may be lame but it's true, non-default options don't get as much testing as default options, especially in volunteer-tested software, the less-used code paths are more likely to be buggy. Sure, some people will use non-default config options but their experience may be sub-par because of it.
In any event, reasonable security options should be enabled by default. Imagine that something like password hashing were a non-default feature. What would happen is that most people would never turn it on and have plenty of bad things happen as a result. After the second or third time the security design problem bites them maybe they'd turn on the more secure feature but then would find themselves locked out of their system or some other horrible fate after which they'd find out that nobody turns the security feature on because it doesn't work. So then they'd just accept the additional risk of doing things in a more risky way that is likely to have a bad outcome because that's just the way things work.
It seems that this kind of scenario has played out many times over the years, like MS Windows putting people in the Administrators group to get around the entire permissions checking system. The Windows issue with the Administrators group and all the trouble that has caused over the years seems to be exactly the kind of thing they are trying to avoid.
XDC2012: Graphics stack security
Posted Oct 1, 2012 4:20 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
many security people fall into the trap where they consider security the most important thing. In the real world it isn't. Security is a matter of risk, and you have to balance risk vs benefit.
XDC2012: Graphics stack security
Posted Oct 4, 2012 7:39 UTC (Thu) by farnz (guest, #17727) [Link]
Nope, you got it wrong. Take virtual keyboards, for instance. Currently they are not possible in Wayland because it has been decided that the compositor should not touch input in any way, applications receive it directly from the kernel. This decision effectively locks down _all_ applications, even those for which input integrity is of no use.
Have you a cite for that? My recollection, backed by the protocol spec is that the Wayland compositor is the only application that gets input directly from the kernel; everything else is notified of events by the compositor. This is essential if the compositor is to transform events in arbitrary fashion - how can a surface know where it is in kernel-global coordinates if the compositor is the only thing that knows about the arbitrary transform applied to it?
XDC2012: Graphics stack security
Posted Sep 27, 2012 22:18 UTC (Thu) by nix (subscriber, #2304) [Link]
XDC2012: Graphics stack security
Posted Sep 28, 2012 10:08 UTC (Fri) by dgm (subscriber, #49227) [Link]
And that's the point of my argument. Security has to be _possible_, but not _mandated_. With X11, right now, it's not possible. That is another way in which Wayland is an improvement over what we have right now.
That doesn't mean, though, that many more steps in that direction are equally as good. We should be careful to not overshoot.
XDC2012: Graphics stack security
Posted Oct 1, 2012 4:11 UTC (Mon) by raven667 (subscriber, #5198) [Link]
That is a very situational judgement on a technology by technology and setting by setting basis. There are often ways to organize things more securely without being a burden for the user.
XDC2012: Graphics stack security
Posted Sep 27, 2012 20:03 UTC (Thu) by DavidS (guest, #84675) [Link]
Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the
Creative
Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds