 7️⃣ Here's the 7th post highlighting key new features of the upcoming v257 release of systemd. #systemd257 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, … 11 comments
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. 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… … 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. 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 Can I define a custom key combination? How are alternate keyboard layouts handled (e.g. Mac)?  @mariusor well, if dbus is hosed, systemd is pretty much hosed, too. SAK is probably the least of you problems then.  You can Connect to me now via SimpleX Chat https://simplex.chat/contact#/?v=2-7&smp=smp%3A%2F%2FPtsqghzQKU83kYTlQ1VKg996dW4Cw4x_bvpKmiv8uns%3D%40smp18.simplex.im%2FD1yZe9VTHaaYgGw5orbCq5dKNRuXn67I%23%2F%3Fv%3D1-3%26dh%3DMCowBQYDK2VuAyEA8jxuVUwBtzlwikmHx9Tqpstet3raCJyvenI2ql6lWyk%253D%26srv%3Dlyqpnwbs2zqfr45jqkncwpywpbtq7jrhxnib5qddtr6npjyezuwd3nqd.onion
I've made it easy and convenient everyone to easily get to me and have quick convo !❤️jack |
Gregory's Server
… 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.