7️⃣ Here's the 7th installment of posts highlighting key new features of the upcoming v257 release of systemd.
-
7️⃣ Here's the 7th installment of posts highlighting key new features of the upcoming v257 release of systemd.
The graphical login prompt you see when your computer boots up is a sensitive UI: typically, when starting to work, without much thinking you'll type in your username and password, expecting it to log you in and provide you with your desktop session. However, what if someone just opened a website in a browser in full screen mode with contents that just *looks* like your login screen, …
-
Lennart Poetteringreplied to Lennart Poettering last edited by
… but actually is just some malware that exfiltrates the password you type in?
Since this kind of attack scenario is not new, many OSes provide a "SAK" concept, which stands for "Special Attention Key". The idea is that there's a special key combination you can hit first, which no web page, or web browser, or app, or even desktop environment could possibly hook into that always brings you back to your *real* login screen, regardless where you are.
-
Lennart Poetteringreplied to Lennart Poettering last edited by
Hence, to securely log in, you'd always hit the SAK key combination first (on Windows, that's Ctrl-Alt-Del), and once the real login screen pops up, you are ready to go.
The Linux kernel has been supporting a SAK concept for a long time too. (see: https://www.kernel.org/doc/html/v5.6/security/sak.html – it's also available via magic sysrq K). However, the way it is implemented is a bit too drastic: it simply kills *anything* with an open fd to the console.
-
Lennart Poetteringreplied to Lennart Poettering last edited by
It's in fact so drastic that it even kills PID 1 if it is currently in the process in writing its pretty status update messages to the console, instantly killing your system. (Because of this, PID 1 will only briefly open the console when doing an update, but it's still racy)
Moreover the kernel SAK concept is relatively easy to circumvent: if a user has access to the console, and their processes that have the console open are killed then nothing stops them to immediately reopen the console…
-
Lennart Poetteringreplied to Lennart Poettering last edited by
… and continue with their nefarious deeds.
With systemd v257 we added support for an alternative SAK implementation that should not suffer by these limitations: logind will now watch input devices for the Ctrl+Alt+Shift+Esc key combination, continously, regardless which session is in the foreground. Once it sees the combination being hit, it fires off a D-Bus signal.
The idea is then that the display manager sees this signal, and switches back to the the login screen in a reliable manner.
-
Lennart Poetteringreplied to Lennart Poettering last edited by
This should be a much friendlier SAK implementation: the original session is not terminated, but just switched away, taking away control of the keyboard, mouse and screen, without chance for the unprivileged code to interfere.
Note that before this actually becomes useful the display managers of the various desktop environments need to be updated to watch for the SAK signal. But the groundwork is laid now.
And that's it for today.
-
@pid_eins is DBus robust enough for this kind of security mechanism? I would have thought that systemd can do something more drastic like freezing all sessions and switching to a "login" target
(speaking as someone very far out the sidelines) -
@mariusor well, if dbus is hosed, systemd is pretty much hosed. SAK is probably the least of you problems then.
-
@pid_eins I understand, I think I was asking more in the idea of this SAK message having to be secured some way against being intercepted by malicious listeners. I guess I don't really know enough about the situation to actually form a pertinent question, sorry.
