Desktop Flickers Past Lock Screen

Question

I'm using Fedora 22 with Gnome 3. I have a password set for my user account, so when my laptop awakens from sleep, I am presented with the lock screen and must enter my password before getting to my desktop. Frequently (maybe 10% of the time), when awaking my computer from sleep mode, I see a very brief "flicker" of my desktop (with all my windows still open) before being presented with the lock screen. It would seem to me that a properly designed security mechanism would not even have the desktop open at all until the user is authenticated. Is this a sign of a serious security hole? Is it a preventable design decision?

Answer 1

It's not a "security flaw" in the sense that something is broken or that the flickers indicate a bug or an attack. Rather, it's an issue with the underlying graphic stack of Linux and the lack of semantics for privileged desktop clients.

Just to get this out of the way, the flicker is most likely caused by a poor interaction between your GPU drivers and GNOME Shell or whatever built-in Wayland compositor there is in GDM. It's completely unrelated to security.

Now onto why you see your desktop below the lock screen...

Historical situation

X11, the protocol and graphic stack server used on all Linux systems, was not designed with the ability to isolate windows from one another effectively, and both the original X11 protocol and a number of extensions to it make it possible and easy for apps to spoof authentication UI dialogs and steal input from other clients.

Traditionally hence, lock screens are merely programs that:

• spawn full screen, on top of all other windows (by using specific WM options on their window
• grab all input (in practice, they can go as far as binding every single key combination on your keyboard to ensure all input events are dispatched to them first)

At this stage you could open a TTY and kill the userland process that grabs the input and covers the screen, and you could probably try to pop some other window on top of it (but it couldn't receive keyboard events). Also note that in X11 keyboard events are not properly dispatched when there is a menu open. So if you can spawn an app and make it open a menu, you might be able to prevent the lock screen from getting input. So far so good.

The most obvious security flaw that comes to mind is that graphic stack servers / compositors have no way to identify whether a specific window is a lockscreen, and whether a specific window claims to be a lockscreen but isn't. This is also a problem on OSX and Windows 8, and I've discussed it before at XDC. The only proper protection against lockscreen spoofs is to use 2-factor authentication.

Less acceptable forms of protection are secure attention sequences (Windows's Ctrl+Alt+Del) or special lockscreen-only capabilities that are hard to spoof and easy to identify (off-screen yet visible indicator, fullscreen only for lockscreen, etc.). In other words you need a trusted path between the user and the OS that triggers the lockscreen, and you also need the lockscreen to authenticate to the user.

Did GNOME-Wayland change anything?

Sadly not as much as it should have. You now have much stronger guarantees, thanks to Wayland's protocol for input dispatching) that your legit lockscreen will not have its input stolen away from it. But you have no way to determine whether it is your actual lockscreen that's in front of you.

Why? There was a strong incentive for GNOME to be the first to "implement" Wayland, and so they just copy/pasted some of the poor, insecure X11 protocols (in particular, selections, methods for accessing special hardware, for binding global shortcuts and accessing fullscreen). Lockscreens are easy to spoof without the requirements I've set up above, and the GNOME Shell developer(s) have not implemented counter-measures. I've discussed this topic privately with one of them and have come to the conclusion that they are not interested in discussing any cross-desktop defences to graphic stack security vulnerabilities. I was told they will solve all underpinning security issues with custom methods that will be somewhat better, at some point in the future.

There is no agenda set for such work to be done and no evidence that it will be carried out. Red Hat's security engineers being busy working on app sandboxing and Docker-related stuff, it's unlikely they will have any manpower to tackle desktop security issues any time soon, and now that the code is implemented and used in the wild, it's even less likely that someone will want to re-change the Wayland APIs. Worse yet, other DEs might want to follow GNOME and leave some APIs unsecured for the sake of not modifying toolkits or desktop apps again.

Last time I spoke to them, the KDE folks were interested in building 2FA, so there might be a workable, less insecure lockscreen for Linux desktops a few years away from now.