XDC2012: Graphics stack security

Posted Sep 26, 2012 17:50 UTC (Wed) by luto (subscriber, #39314)
In reply to: XDC2012: Graphics stack security by dlang
Parent article: XDC2012: Graphics stack security

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

to post comments

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.