Slashdot Mirror
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.
Flashback from the 90's: Telnet and X11 are inherently insecure - where's the news in that?
... 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.
What? I was assured that THIS was the year of the Linux Desktop!
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.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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
Whats being attacked is the unix ethos: do one thing and do it well. Capturing the key sequence to lock and faking the screen, while it may be easier in KDE alongside Systemd, is not easy in fluxbox or awesome. Its the explicit lack of widgets or sprockets or mindless dreck like this, and predefined key sequences that are captured by the window manager first. I use i3lock, which would mean attackers would have to find a way to get into /usr/bin to usurp my locker and at that point i have a far greater degree of concern than just the locker. X Forwarding and shared X in general has always been a security concern. ssh-agent should be avoided and if you have work to do on the server, do it in a tty over ssh. And this is the schism: newschool linux wants a sexy user experience that pops out of the box and is unified. They want the user to obey the vision of their design and use user switching, connection sharing, and fancy clock widgets and X just cant be (nor should it) Microsoft Windows. Old fogeys like myself will deck the halls of localhost when and if we want to. And it will always be on our terms, right down to color, shape, and font. Security will be our concern.
Good people go to bed earlier.
What do you mean "think it will kick in"? Activate it when you get up from your desk, period. For Windows it's an easy "winkey+L" combo as you get up from your desk. Done, workstation is secured and locked. That's our company policy anyway, you're supposed to lock your workstation when you step away. A timed lock screen is pointless, stupid and just gets in the way. If your mouse just happens to bounce a little, it'll reset the "inactive screen timeout".
They did go for C++. On Linux. It was more than just issues with .NET.
Comparing this to Windows is silly, because Windows doesn't have anything like the X11 protocol. On Windows, running code can disable the screen saver in other ways: patching or replacing DLLs, changing system configuration, etc. No difference from a security point of view.
I'm no Windows fanboy, but this is just factually incorrect.
(1) All those operations require elevation, so unless the user has lowered UAC from the default, they will require authentication. I suppose a malicious installer could do that, but it is emphatically incorrect that any running code can effect that change.
(2) Since 7, when Windows elevates it completely suspends the old 'Desktop' and creates a brand new one for the elevation prompt. If you look closely, you'll realize that all the other 'windows' are actually just a static screenshot of what happened on the unprivileged desktop at the point where the elevation prompt was created.
So "from a security point of view", on Windows you have a specific privilege required to change the SS that is mediated through a privileged interface where it cannot be snooped/intercepted by unprivileged processes.
[ Of course, this comparison is also patently unfair -- Windows 7 was written in the 2000s, X11 was written in the 1980s. Expecting them to be comparable in terms of security is pretty ridiculous. ]
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.
Ask me about repetitive DNA
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.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Jamie Zawinski has been wrong before, too, but in this case it's not even wrong. What we're talking about is the X protocol being fundamentally flawed; it's really pretty irrelevant what screen locker is being used.
And yet Jamie's xscreensaver hasn't been shown to be insecure by this guy. He's only proven what jwz said which is that a lockscreen using a toolkit on top of X11 is insecure.