LWN: Comments on "XDC2012: Graphics stack security"

XDC2012: Graphics stack security

farnz — Thu, 04 Oct 2012 07:39:20 +0000

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

renox — Mon, 01 Oct 2012 08:51:20 +0000

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

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

raven667 — Mon, 01 Oct 2012 04:38:34 +0000

> 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)

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

raven667 — Mon, 01 Oct 2012 04:33:08 +0000

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

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

raven667 — Mon, 01 Oct 2012 04:27:44 +0000

> so if you want a different screensaver, you need to have a different compositor?

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

dlang — Mon, 01 Oct 2012 04:20:51 +0000

there are security options that can be turned on because they don't break anything (i.e. hashed passwords) and security options that should not be turned on by default because they do break things (the examples in this case that break all soft keyboards, screenshot programs, etc)

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

raven667 — Mon, 01 Oct 2012 04:11:05 +0000

> Security has to be _possible_, but not _mandated_.

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

raven667 — Mon, 01 Oct 2012 04:08:39 +0000

>> If it's not enabled by default, nobody will use it because it won't get testing and bugs won't be fixed.
>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.

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

raven667 — Mon, 01 Oct 2012 03:54:12 +0000

I was responding to someone else, sorry if it looked like I was responding to you. Thanks for putting this together and for taking the time to think it through and explain your thoughts to the LWN community.

XDC2012: Graphics stack security

Cyberax — Fri, 28 Sep 2012 21:54:06 +0000

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

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

mjthayer — Fri, 28 Sep 2012 19:28:50 +0000

> I said that the problem was with the permissions being the same for all apps from a single user.
>
> putting the cookie in one file and having all apps read it from that file would seem to match my criteria for a problem.

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

dlang — Fri, 28 Sep 2012 19:13:50 +0000

I said that the problem was with the permissions being the same for all apps from a single user.

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

dgm — Fri, 28 Sep 2012 10:34:53 +0000

> If it's not enabled by default, nobody will use it because it won't get testing and bugs won't be fixed.

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

dgm — Fri, 28 Sep 2012 10:08:06 +0000

> Right now, I can't.

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

mjthayer — Fri, 28 Sep 2012 09:15:29 +0000

> There's nothing inherently wrong with cookies, just with the permissions being the same for all apps from a single user.

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

nix — Thu, 27 Sep 2012 22:18:59 +0000

Maybe, but Martin is right that security has to be on by default, not off, at least for the most extreme stuff like keystroke monitoring or overpainting. I want selfspy to connect to the RECORD extension and record my keystrokes, but if anything else tries to do it I damn well want to refuse it. Right now, I can't.

XDC2012: Graphics stack security

DavidS — Thu, 27 Sep 2012 20:03:59 +0000

I really dig Peter Hutterer's notion of "semantic" global shortcuts. A privileged configuration panel can connect up keystrokes to "command slots" on each application and gone are the days of overlapping global shortcuts!

XDC2012: Graphics stack security

ortalo — Thu, 27 Sep 2012 16:37:24 +0000

I remember reading hardware documentation of something similar to adress translation tables for onboard VRAM on a Cirrus Logic Laguna3D graphics chipset circa... 1996. Good wheels get reinvented so often... ;-)

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

Siosm — Thu, 27 Sep 2012 14:50:25 +0000

> Regarding Wayland security, security has to be possible, but not mandated.

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

mupuf — Thu, 27 Sep 2012 13:42:12 +0000

I agree that the system should be made as flexible as possible. However, applications should NEVER be allowed to chose without control from distributions or the system administrator.

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

dgm — Thu, 27 Sep 2012 10:44:04 +0000

Regarding Wayland security, security has to be possible, but not mandated. By locking down applications we make them less useful. 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.

Having insecure input and output, _in_addition_ to secure ones, is clearly desirable and good.

Let applications chose.

XDC2012: Graphics stack security

Siosm — Thu, 27 Sep 2012 10:03:31 +0000

> Just don't make the mistake of thinking that those common use cases are the only use cases.

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

Siosm — Thu, 27 Sep 2012 09:56:38 +0000

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

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

dlang — Thu, 27 Sep 2012 00:15:19 +0000

causing an app to crash because it tries to do a screenshot and it wasn't allowed to seems like a very reasonable thing to have happen :-)

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

mupuf — Wed, 26 Sep 2012 23:59:57 +0000

Completely fair point! There is no association between the binary file and its window(s) and it can be misleading to the user in some cases.

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

mupuf — Wed, 26 Sep 2012 23:43:57 +0000

X cannot be made secure by nature. Even if we managed to do whatever we want with X, the applications aren't ready for that and would just crash because they don't always look at the error codes.

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

mupuf — Wed, 26 Sep 2012 23:40:03 +0000

I guess you are talking about me.

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

dlang — Wed, 26 Sep 2012 21:24:19 +0000

agreed, having sane defaults for common use cases is a GOOD thing.

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

raven667 — Wed, 26 Sep 2012 20:18:31 +0000

You seem to be in violent agreement with the engineers who put this presentation together.

XDC2012: Graphics stack security

luto — Wed, 26 Sep 2012 20:03:18 +0000

> so if you want a different screensaver, you need to have a different compositor?

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

jg — Wed, 26 Sep 2012 19:35:07 +0000

And many people seem to forget that "Mechanism, not policy" does *not* mean that the default policy should be insanity.... I've seen many who seem to think it does.
- Jim

XDC2012: Graphics stack security

dlang — Wed, 26 Sep 2012 19:11:35 +0000

Even the example of catching your interaction with a bank is not necessarily an evil thing

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

dlang — Wed, 26 Sep 2012 19:06:57 +0000

In addition, as long as you allow more than one app to have windows open at a time, there is some potential for an app to pop up a window that looks like another app (or a system password prompt)

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

dlang — Wed, 26 Sep 2012 19:04:27 +0000

so if you want a different screensaver, you need to have a different compositor?

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

dpquigl — Wed, 26 Sep 2012 17:51:46 +0000

X has an access control framework similar to the LSM kernel framework called XACE. XSELinux is a security module for the XACE framework that uses SELinux to define policy and make access control decisions (called a Userspace Object Manager in SELinux speak). You're welcome to write other access control modules for XACE and propose them for inclusion if you have a good idea for an access control module.

XDC2012: Graphics stack security

luto — Wed, 26 Sep 2012 17:50:06 +0000

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

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

dlang — Wed, 26 Sep 2012 17:00:15 +0000

One problem is that every weakness listed is something that has desirable users.

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

mupuf — Wed, 26 Sep 2012 16:42:51 +0000

Memory management on GPUs is very hardware-specific on GPUs. For instance, some buffers can be tiled or not depending on some conditions. It is also possible to "swap" VRAM buffers inside the RAM but certainly not on the hard disk drive. In its current forms, it is almost impossible to share code between the RAM allocator and GPU VRAM allocator (that is driver-dependent).

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

gioele — Wed, 26 Sep 2012 16:16:33 +0000

Why is VRAM treated differently from plain RAM? Can't a sanitizing step like https://lwn.net/Articles/334747/ be implemented for VRAM?

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

mupuf — Wed, 26 Sep 2012 13:52:14 +0000

This solution seems a bit over-complicated to me. The solution presented in the article can leverage policy kit too and doesn't necessitate another daemon neither dbus.

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.