@mariusor well, if dbus is hosed, systemd is pretty much hosed. SAK is probably the least of you problems then.

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.

… 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.

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…

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.

… 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.

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, …

At Linux' best conference, All Systems Go! 2024 in Berlin this year I gave a (brief) talk about Varlink, and why you should consider it. If you want to know more about the concept, this might be a good starting point:

Varlink Now!

Why bother with Varlink IPC, and why now? The Varlink IPC has been around for a while, but recently we started using it heavily in syste...

(media.ccc.de)

And that's all for now, enjoy!

i.e. for example handles base64 encoding/decoding for handling binary blobs within JSON automatically, or it helps you with dealing with JSON's >53bit integer problem, and various other things.

Right now, documentation for sd-varlink and sd-json is scarce (one could even say "barely existing"), but there are plenty of real-life examples in the systemd source tree, of course.

You are of course right if you say that there are already so many of those, why another? And you'd be right. My answer to that is that sd-json is much nicer to use than most, since it doesn't just allow you deal with JSON objects, it also helps you with building them from C data structures, and to map JSON objects back to C data structures. It also helps you with higher level operations that the low-level JSON datatypes leave you in the cold with:

There are various bindings for Varlink available from the Varlink project, but with systemd v257 we now make systemd's own C implementation available publically too: sd-varlink.

sd-varlink has been around for quite a while, and is quite well tested (including fuzzed) by now hence. It's already driving your systemd installations, except mostly internally so far.

Since Varlink uses JSON for marshalling its messages, sd-varlink comes with a companion API: sd-json. It's another C library for JSON.

…supported JSON output anyway, the output side was done pretty much anyway.

Anyway, there are many other stories like that.

Suffice to say, in v257 there are now 19 Varlink interfaces/services, which we added in a short time, for various things that never had them before when D-Bus was our sole focus, because it was so nasty to add that.

(For comparison: we provide only 11 D-Bus API services at this time).

we just let systemd's socket activation logic listen on an AF_UNIX/SOCK_STREAM socket, and then let it fork off a new bootctl instance for each connection. That instance then just processes that connection and is done. And it's easy: it just does what it usually does, but instead of reading the commands to execute from the command line it just reads them from a small JSON object it gets from STDIN. And it just writes its output as JSON to STDOUT, done.

In fact, because bootctl already…

To give one example, "bootctl" is a small tool that installs the systemd-boot boot loader into the ESP for you. It's a command line tool that synchronously copies a bunch of files into the target mount. We always had the plan to turn that into a D-Bus service, but never actually did it, because doing that is pain: we'd have to turn it into an event loop driven thing, which is just nasty for something so simple that just copies some files.

In a Varlink world, the problem goes away:

…, it's JSON use make it more conceptually compatible with the rest of the world and various other things.

It's also a lot easier to write Varlink services than D-Bus, because it allows you to handle each connection in a different process, thus being compatible with codebases that do not have event loops (D-Bus due to its multiplexing forces you to process all messages within the same process, and due to the global ordering within a single event loop).

4️⃣ Here's the 4th installment of posts highlighting key new features of the upcoming v257 release of systemd.

One of the key features of systemd we have talked about in the past years are UKIs, i.e. "unified kernel images", which is a combination of a Linux kernel, an initrd, and more into a single unified PE binary, that can be signed as a whole for SecureBoot, measured as a whole and updated as a whole.

In my PoV UKIs are a central concept of securing the Linux boot process.

@jejb sure, but that's what i meant with "passive" actually: within that minute all apps will talk to the TPM not knowing it is compromised. And a minute is a long time.

@jann @Foxboron If you can power cycle the TPM independently of the CPU, then this allows you to reset the PCRs, and that would of course compromise all of boot integrity. A hw bug like that is hard to fight.

Some aspects of that could probably be addressed with @jejb's recent kernel TPM work, but only passively (i.e. we could eventually detect that this happens, and reboot, but not stop people to continue access the TPM for a while with the reset PCRs).

@erincandescent cgroupfs actually exposes the cgroupid via ntha() and obha(). So yes, there's prior art for doing the same in pidfs. But it's a bit weird, because unlike cgroupfs pidfs is not an fs you can mount, hence you don't really have anything to invoke obha() on. You'd probably have to get a pidfd on your own pid first, before you can use it to use obha() to get to the pidfd you actually want to get to.

If you ask me, it's a fundamental requirement for any modern Linux-based OS to provide boot time integrity and as baseline provide unattended disk encryption bound to it. To make this happen, we added two essential TPM policy concepts to systemd-cryptenroll/systemd-cryptsetup:

1. Signed TPM PCR policies allow locking a disk to a public signing key of an OS vendor, ensuring that disks can only be unlocked if an OS signed by said vendor is booted.