XDC2012: Graphics stack security

Posted Sep 26, 2012 17:00 UTC (Wed) by dlang (guest, #313)
Parent article: XDC2012: Graphics stack security

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)

to post comments

XDC2012: Graphics stack security

Posted Sep 26, 2012 17:50 UTC (Wed) by luto (subscriber, #39314) [Link] (6 responses)

>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

Posted Sep 26, 2012 19:04 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

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

Posted Sep 26, 2012 20:03 UTC (Wed) by luto (subscriber, #39314) [Link]

> 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

Posted Sep 28, 2012 9:15 UTC (Fri) by mjthayer (guest, #39183) [Link] (2 responses)

> 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

Posted Sep 28, 2012 19:13 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

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

Posted Sep 28, 2012 19:28 UTC (Fri) by mjthayer (guest, #39183) [Link]

> 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

Posted Oct 1, 2012 4:27 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> 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

Posted Sep 26, 2012 17:51 UTC (Wed) by dpquigl (guest, #52852) [Link] (4 responses)

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

Posted Sep 26, 2012 23:43 UTC (Wed) by mupuf (subscriber, #86890) [Link] (3 responses)

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

Posted Sep 27, 2012 0:15 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

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

Posted Sep 27, 2012 9:56 UTC (Thu) by Siosm (subscriber, #86882) [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.

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]

> 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

Posted Sep 26, 2012 19:06 UTC (Wed) by dlang (guest, #313) [Link] (3 responses)

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

Posted Sep 26, 2012 23:59 UTC (Wed) by mupuf (subscriber, #86890) [Link]

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

Posted Oct 1, 2012 4:38 UTC (Mon) by raven667 (subscriber, #5198) [Link] (1 responses)

> 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

Posted Oct 1, 2012 8:51 UTC (Mon) by renox (guest, #23785) [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.

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 (guest, #313) [Link] (3 responses)

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

Posted Sep 26, 2012 19:35 UTC (Wed) by jg (guest, #17537) [Link] (2 responses)

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

Posted Sep 26, 2012 21:24 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

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

Posted Sep 27, 2012 10:03 UTC (Thu) by Siosm (subscriber, #86882) [Link]

> 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

Posted Sep 26, 2012 20:18 UTC (Wed) by raven667 (subscriber, #5198) [Link] (2 responses)

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

XDC2012: Graphics stack security

Posted Sep 26, 2012 23:40 UTC (Wed) by mupuf (subscriber, #86890) [Link] (1 responses)

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

Posted Oct 1, 2012 3:54 UTC (Mon) by raven667 (subscriber, #5198) [Link]

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.