Quick overview of where we are in Whonix 18 when it comes to screen locker backdoors:
Backdoor #1: Ctrl-Alt-Backspace .
Does not appear to be a problem. Ctrl-Alt-Backspace does nothing in Whonix-Workstation 18 with labwc. No files under /usr or /etc contain configuration that binds the Exit action in labwc to a keyboard shortcut, and it doesn’t appear at first glance that there is any keyboard shortcut designed to terminate labwc hardcoded in the source code.
Backdoor #2: Ctrl-Alt-F1 , Ctrl-Alt-F2 , etc.
Technically this is still a problem, but I don’t really consider this to be a backdoor at all. “If you’re logged in somewhere other than your graphical session, someone can switch to that session and have access” is just how systems that allow multiple logins work, if you log in somewhere and don’t log out, someone else could use that login. If we wanted to, we could disable additional VTs, but I see no tangible benefit in doing so, and would expect this would result in serious issues for users who end up with a broken GUI login.
Backdoor #3: Alt-SysRq-F .
Magic SysRq is entirely disabled on Whonix and has been for a while.
Backdoor #4: Ctrl-Alt-KP_Multiply .
Seems to be registered as a normal keypress with Swaylock, doesn’t do anything special. labwc does not appear to document any configuration options in labwc that allow force-unlocking the screen, nor does man swaylock. One possibly backdoor-like feature is that one can make swaylock unlock the screen without a password by sending a SIGUSR1 to the swaylock process, but that requires the ability to send signals to processes running as the user you are attacking, which is very close to (if not equivalent to) arbitrary code execution privileges. If an attacker has arbitrary code execution as the user they are attacking, bypassing the screenlocker is most likely the least of the victim’s worries.
One other related issue worth looking at:
As covered in XScreenSaver Manual, the OOM killer may take out a process like the screen locker even though Magic SysRq is disabled; all that has to happen is one must actually run out of memory. (This could happen if someone is using the system remotely over ssh while the screen is locked, or if the screen become locked while a lot of browser tabs were open and one of them is consuming more and more memory.) There is no good way to disable the OOM killer (the documented solution is to disable memory overcommit, but that’s a problem because some security features rely on it (in particular AddressSanitizer attempts to allocate somewhere around 20 terabytes of virtual memory, at least with the way it’s currently used in kloak). The other alternative is to enable panic_on_oom, which will cause the entire system to crash if it runs out of memory. I think the latter sounds like a good idea - it allows memory overcommit to work, and prevents unlocking the screen. The only real danger is that it could print out debugging details to a virtual terminal upon memory exhaustion, it’s unclear whether or not this may contain sensitive info or not. But I think we disable printing kernel messages to the display anyway…
tl;dr: of all the above - It looks like we’re mostly good, but we should consider enabling panic_on_oom.
