Luks+Sleep: Login screen security?

Question

Situation: A Desktop Linux (eg. Debian, Xfce desktop, Lightdm login) with LUKS-encrypted partitions (as far as possible, eg. Efi files are not encrypted of course).
The computer is in sleep mode (not hibernate, ie. Luks in unlocked and key in RAM).

Now a thief steals the computer and wants to find a way in.

• Anything that involves turning it off will of course not help because of the disk encryption.
• Installing hardware keyloggers, replacing Bootloader/Efi with something maliciours, and similar things won't help because the owner knows it is stolen and it can't be trusted.
• Elaborate attacks that eg. read the keys directly from RAM through some means are outside of the thiefs capabilities and/or a risk that the owner takes for being able to use sleep instead of shutdown.
• That leaves the risk that the login screen (of LightDM) can be bypassed somehow, given the already running Desktop behind it.

My question is, what things I do need to be aware to prevent this?

Following points I already know:

• Switching terminals (CtrlAltFn).
  • It the GUI is started with startx, this allows to get an TTY where the user is logged in already. However there is no such TTY when using LightDM.
  • There is also a GUI screen which just displays "This session is locked, will switch to login in few seconds" (or similar message). However it doesn't appear that there is an easy way to break out from that.
• X Server has a DontZap config option which allows to kill X with the shortcut CtrlAltBackspace. This might help in the "locked" screen or even Lightm, however it is disabled by default, so no problem.
• There is another X shortcut CtrlAlt* (star) (config AllowClosedownGrabs) which kills all processess that hold a "lock" (whatever lock this means). This too is disabled by default.
• Kernel SysRQ shortcut F for OOM killer. Can be disabled, and maybe the two GUIs are among the processes protected against it (I tried about 50 times and and failed to kill LightDM, just not sure about the exact reason).

What other risks might be there in 2018?

Answer 1

Assuming all relevant SysRq features are disabled when the lock screen is active (SAK, sending SIGTERM or SIGKILL to all processes, triggering the OOM killer as you mentioned, etc), and assuming advanced attack vectors like DMA attacks, cold boot attacks, and network exploitation are out-of-scope, then there is no way to bypass the lockscreen short of exploiting a bug in the code that is currently unknown (they are not too uncommon, though). In short:

• Bypass may be possible by using other SysRq features you have not mentioned.
• Bypass may be possible by exploiting an unknown bug in the lock software.
• Infoleaks may be possible by plugging in a large monitor, triggering a resize.^*
• A local process could (intentionally or unintentionally) interfere with locking.

There are other, more secure lock programs out there. An example is vlock which works by opening a new TTY that it controls and disabling TTY switching. It also disables SysRq while it is active. It should be noted though that, if it is run from a terminal, it will exit if the terminal crashes for any reason (this is a bug which is easy to fix). The reason vlock is particularly secure is because it does not rely on the security of your X server, which itself has fundamentally no concept of lock screens. Instead, it is designed to utilize TTY isolation which is something that was designed with security in mind. Another alternative might be xsecurelock, a simple graphical lock screen created by Google which emphasizes security against crashes. However, like most screen lock software, it does not disable any SysRq features by itself, so you must do that yourself if it is enabled.

_{* If a large monitor is plugged into the locked computer, the root window may automatically resize itself. If the lock screen does not detect this and maximize itself again, it may be possible to see beyond the lock. This is not an issue with virtual terminal-based lock software like vlock, since the X server is in another TTY.}

Answer 2

While locked, networking capabilities are still active. So, the device is susceptible to having vulnerabilities exploited. Network attack vectors include USB network adapter, Ethernet and Wi-Fi. Although, Wi-Fi will require looking at probes being sent out and creating an AP with the same SSID and network security (passphrase if secured).

Another idea is extracting the encryption keys from RAM. However, I feel most the ideas discussed in that document are beyond the capabilities of most people.

Bypassing the lock screen is somewhat limited. Linux based distros often use a variety of different graphical user interfaces. While this does not discredit this idea, it is simply worth less than finding an Android or iOS lock screen bypass.