Posted on

Animations on lock screen – Plasma Wallpaper support

With Plasma 5.7 released I’m allowed to blog about new features in Plasma 5.8. One of the features missed by many users in the Plasma 5 series was the lack of animations in the lock screen architecture. With Plasma 5 we dropped support for the old XScreenSaver and went QtQuick only. Now technically it was always possible to have animations on the lock screen. Our lock screen architecture loads the QtQuick files through the lookandfeel package mechanism, which means that one could provide an animation in a lookandfeel package.

But so far, nobody did that. Which means we don’t have animations on the lock screen. Today I’m happy to announce that this situation is going to change with Plasma 5.8. Our lock screen architecture gained support for Plasma Wallpaper plugins. All the wallpaper plugins available for the desktop are now also available for the lock screen. By default it uses the image wallpaper set to the default wallpaper, but one can also have slide shows, or fancier animations. In fact one could even try to provide a Plasma Wallpaper plugin for the old XScreenSavers.

The support for wallpaper plugins got added as a scratch-your-own-itch solution. For a personal project I must be able to show a slide show on a locked screen and looked at possible solutions for this. Pretty quickly I came to the conclusion that adding Plasma wallpaper support is the best solution and also provides something for all Plasma users. But it also makes me wonder why nobody did that before.

Posted on

Lock screen security of phones

These days we can read a lot about a lock screen vulnerability in the Android system. Given that I have spent quite some thought on how we can use Plasma’s lock screen on our phone system I take the incident as an opportunity to share some thoughts about the topic. The tldr is “much ado about nothing”.

In Plasma we have an in my opinion rather secure infrastructure for the lock screen. Of course it suffers from the general problems of X11, but once it’s ported to Wayland it will be truly secure (till the first exploit is found). Given that I would like to use our lock screen architecture also on the phone. It’s secure by not letting anyone in even if the lock screen crashes (one of the problems hit in the Android exploit), by ensuring nothing else is rendered and no input is passed to any other application. So awesome! It will be secure!

But on second look we notice that the requirements on phone and desktop are different. On a phone we need to allow a few exceptions:

  • Accept phone calls even if screen is locked
  • Interact with notifications (e.g. alarm clock)
  • Allow emergency phone calls

The last item is also an important part of the puzzle for the Android exploit. These exceptions directly conflict with the requirements for our lock screen on the desktop. To quote:

Blocking input devices, so that an attacker cannot interact with the running session

It allows interacting with the running session (even more with the hardware) and it doesn’t block input devices any more.

I have over the last months spent quite some time thinking about how we can combine these requirements without compromising the security and so far I haven’t come to a sufficient solution. All I see is that if we allow applications (e.g. phone app) to bypass the lock screen, we in truth add a hole into the architecture and if there is a hole you can get through it. There will be ways to bypass the security then. No point in fooling ourselves. A phone app is not designed for the secure requirements of a lock screen.

Now phone calls are not all we need to care about on a lock screen – this could be solved by e.g. integrating the functionality into the greeter app. Users might want to take photos without having to unlock the screen (another piece of the Android exploit). It’s from a security perspective a questionable feature, but I can understand why it got added. Now this feature directly adds a huge hole into it: it writes to the file system. I can easily imagine ways to bypass the lock screen from a camera app, get to the file system, etc.

At this point we need to take a step back and think about what we want to achieve with a lock screen. On the desktop it’s clear: if there is a keyboard somewhere you should not be able to penetrate the session even if you have hours to try. But on a phone? Does this requirement hold? If I have the chance to unattended attack the lock screen of a phone, it means I own it. For desktop hardware we can say that the lock screen doesn’t protect against screw drivers. This also holds for phones. If one has enough time, it’s unlikely that one can keep the attacker out and the lock screen is most likely not the weakest link in the chain. Phones have things like finger print readers (easy to break), various easy to reverse construct passphrase systems, simple passwords, etc. So the lock screen itself is relatively easy to bypass and then we have not even looked at all the things one can do when attaching a usb cable…

Given that the requirements for phone security might be different? Maybe it’s not about blocking input devices, preventing anyone to get in? Maybe the aim is only to hold of people having access to it when unattended for a few moments?

If that’s the aim our lock screen architecture of the desktop might even be over done, adding holes to it would be wrong and we shouldn’t share the code? It also means that the Android vulnerability doesn’t matter. The exploit is a complicated process needing quite some time. The lock screen prevents access for uneducated people and also for those having just a few moments of unattended access. It only breaks in situation where it might not matter: when you already physically own it.

Posted on

Global Shortcuts and the Lock Screen

With Plasma 5 our lock screen architecture changed significantly. For example we do no longer support screen saver hacks or widgets on top of the locked screen. Both are very unlikely to make a return in future releases. This means that bug reports against the old infrastructure might no longer apply to our current code base. Two weeks ago I went through all bug reports and feature requests to evaluate whether they still apply to our new infrastructure or should be closed.

This is something I do not like to do. I find it extremely sad to close bug reports because they are outdated. Especially if the bugs have been open for several years without any activity. After going through all those reports it is obvious that we offered too many possibilities to configure the screen locker with too few people caring about it. The number of available screen savers was just immense – especially if one considers that there are also 3rd party savers. While it’s easy to install them, there is basically nobody who cared about them. Some are decades old with the devs having moved on years ago.

Apart from that one could also notice that there were important features missing in our lock screen: audio and multimedia control. The problem is obvious: you suspend your notebook while audio is playing, resume in a place where it should not play audio (e.g. classes) and first need to unlock the screen before being able to mute the audio. An unpleasant experience.

The problem here is that media keys are not supposed to work. The lock screen grabs all keyboard input and prevents other applications to get the keyboard input. This includes our global keyboard infrastructure. We cannot just forward all keys to the global keyboard infrastructure as that could be used to create a key logger when the screen is locked. Even more: most short cuts shouldn’t be invokable when the screen is locked, e.g. you don’t want the desktop to switch.

After brooding over it for a few days I had an idea on how to resolve the problem: the lock screen needs to integrate with our globalshortcut handling. When the screen gets locked we get the available shortcuts from the daemon and map them against a white list of allowed shortcuts. Whenever a key is now pressed while the screen is locked, it’s verified against the fetched list. If we have a match the shortcut is invoked. Not all shortcuts are supported, though. The architecture ensures that one cannot abuse the infrastructure to turn it into a key logger. All alphanumeric keys are excluded. In addition it uses as mentioned a white list, which is not configurable, but hard coded on purpose. At the moment we support only a very limited set of global shortcuts: volume keys, brightness keys and media control keys.

Media control keys were also an interesting topic to work on. Our Plasma session didn’t have any global shortcuts for media handling, so there was nothing which our lock screen could do about it. It cannot figure out whether there is a media application running and then invoke an action on it.

So I stepped back and thought about whether there is a better way to solve it in a general way. Plasma supports the mpris2 interface allowing to control any mpris2-enabled media application. What if the mpris2 engine inside Plasma binds the multi media keys? They could forward to the currently running media player, give us a consistent way to interact with media players and allow us to expose it in the lock screen. So now we have by default mapped the media player controls as global shortcut delegating to any media application. If you press the “Play” button it will Play/Pause VLC, no matter whether it’s the active application or not. And in addition also in the lock screen.

Now there was just one problem to solve: pressing shortcuts and not having visual feedback is not that good. On the desktop we show an on-screen-display whenever the volume changes, but as the screen is locked, we cannot see it. So this architecture also needed enhancement. With a few more changes our lock screen is now able to listen to the requests for on-screen-display information and integrate them:
New lock screen with audio info

All just for supporting shortcuts in the lock screen.

Posted on

Locking the screen before system suspends

Our Plasma workspace has offered the feature to lock the screen when resuming from suspend for a long time. Ideally the screen gets locked right before the system goes to suspend to ensure that the screen is properly locked when the system wakes up.

The process was controlled by powerdevil: when powerdevil decided that it should suspend the system, it invoked the lock screen to get the screen locked. But this has drawbacks. For example the screen locker doesn’t know that the system is going to suspend. Neither does powerdevil know when the screen is fully locked (the lock process includes multiple stages and the actual lock is hold before the screen gets blanked). Also it only works with powerdevil, if one suspends the session in a different way (e.g. through systemctl suspend) the screen doesn’t get locked. The worst drawback was that sometimes it was still possible that the system woke up and expose the session for a split second as the screen locker has no way to indicate to the system to wait with the suspend till everything is settled.

With the upcoming Plasma 5.2 release this will significantly improve by leveraging functionality provided by logind. The lock screen on resume functionality is moved from powerdevil into the screen locker. This already means that the screen locker has a more complete picture of what is going on and allowed us to streamline the settings: whether the screen locks on resume is now found in the same configuration module as all other screen locker related settings.

The most important change is that we are now able to ensure that the screen is locked before going to suspend. For this the screen locker holds an inhibitor lock. When the screen is going to suspend, the screen locker is notified by logind, can start the lock process and remove the inhibitor lock once the screen is properly locked. This means under normal condition the screen will be locked before going to suspend (of course a timeout in logind could be hit if everything takes too long or if the screen cannot be locked).

Obviously this will only work if the system is suspended through logind, which powerdevil does if logind is available. So our users who use logind get an improved experience. For our users who do not yet use logind nothing changes: powerdevil notifies the screen locker that it’s going to suspend and the screen locker starts the lock process. This obviously has the same limitations as described above.