Why Screen Lockers On X11 Cannot Be Secure

jones_supa writes: One thing we all remember from Windows NT is the security feature requiring the user to press CTRL-ALT-DEL to unlock the workstation (this can still be enabled with a policy setting). The motivation was to make it impossible for other programs to mimic a lock screen, as they couldn't react to the special key combination. Martin Gräßlin from the KDE team takes a look at the lock screen security on X11. On a protocol level, X11 doesn't know anything of screen lockers. Also the X server doesn't know that the screen is locked as it doesn't understand the concept. This means the screen locker can only use the core functionality available to emulate screen locking. That in turn also means that any other client can do the same and prevent the screen locker from working (for example opening a context menu on any window prevents the screen locker from activating). That's quite a bummer: any process connected to the X server can block the screen locker, and even more it could fake your screen locker.

Comments

Umm..and telnet is insecure.

[heavy_metal_drinker]

Flashback from the 90's: Telnet and X11 are inherently insecure - where's the news in that?

Re:Umm..and telnet is insecure.

[Dog-Cow]

Wow. Way to totally misunderstand everything.

X11(R6) is a protocol.
XFree86 and XOrg are implementations.

So to cicumvent the screen locker...

[Viol8]

... there has to be a trojan on the system or at least something connected to the X server over the network.

Hmm. I think by this time your security is already out the window and a borked lock program is the least of your worries.

Re:So to cicumvent the screen locker...

[Anonymous Coward]

This was fixed decades ago. Don't issue xhost + and you should be fine. X uses auth tokens that are files in /tmp with mode 600.

Re:Uh, okay?

[Enry]

What? I was assured that THIS was the year of the Linux Desktop!

Already solved!

[Qzukk]

systemd-screenlockerd saves the day!

Of course, it requires systemd-moused, systemd-keyboardd, systemd-windowd, systemd-X11d, and finally systemd-logind. Right now there's some compatibility issues that have been in the bug tracker for a year or so, so for best results you should also ditch KDE or gnome and go with systemd-windowd-managerd and systemd-menud. There's a few incompatible apps as well, if you have problems try using systemd-webbrowserd (requires systemd-networkd) and systemd-xtermd (requires systemd-fontd and systemd-shelld). Thunar works fine though for browsing files, as long as they're in the systemd folder.

Uses QT for screensaver, complains about security

[Anonymous Coward]

KDE uses QT, a gigantic toolkit, to implement the screen saver. In this case the UI relies on QT Quick.
Gnome's screensaver has the same problems with GTK.

Jamie Zawinski, who wrote the standard xscreensaver, has a FAQ page detailing how these are a fundamentally bad idea from a security perspective:
http://www.jwz.org/xscreensaver/toolkits.html

Xscreensaver

[gringer]

Jamie Zawinski has another explanation why screensavers on KDE can't be secure:

Like GNOME, KDE also decided to invent their own screen saver framework from scratch instead of simply using xscreensaver.

And Unity:

Guess what, they did it again! Ubuntu Unity's screen-locking framework is yet another rewrite, and it is completely broken, bug-ridden and insecure. At this time I don't have any information on how to turn it off and use xscreensaver instead. If you do, let me know.

He also has a writeup on toolkits, discussing why locking and unlocking is a hard problem, especially when accessibility features are required.

Re:If it's accessing your X server, it's elevated

[JesseMcDonald]

I'm not familiar with writing apps for X, but are you saying that every program that displays a window in X can log all keystrokes including in windows that are not associated with that program?

Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device. This is how things like global keybindings are typically implemented. Windows used for password entry (including lock screens) can grab the keyboard to prevent other programs from listening in. The problem is that this only works if no other program has already grabbed the keyboard.

Secure input handling is one of the many reasons why everyone is eventually planning to switch to Wayland. Under Wayland, only the compositor has access to the raw input or the ability to inject simulated input events. The compositor manages any global keybindings and forwards the remaining events exclusively to the active window.