Notices by Lennart Poettering (pid_eins@mastodon.social), page 2

4️⃣2️⃣ Here's the 42nd post highlighting key new features of the upcoming v258 release of systemd. #systemd258

Part of the protocol spoken between service processes and the service manager (if it is systemd, that is) are a number of environment variables. Specifically, $MAINPID and $MANAGERPID are two variables that have been part of the protocol for a long time: they contain the PID numbers of the main service process and of the service manager itself.

3️⃣6️⃣ Here's the 36th post highlighting key new features of the upcoming v258 release of systemd. #systemd258

systemd tries to bridge the gap between being modular and flexibily supporting a wide range of systems and devices on one hand, and being somewhat quick and efficient to boot up on the other. These two goals are sometimes opposing forces: on many systems step X has to be done on boot, but each such step X costs dearly on other systems where X is not needed.

3️⃣5️⃣ Here's the 35th post highlighting key new features of the upcoming v258 release of systemd. #systemd258

In various stateless situations it makes sense to boot directly into a root file system that is downloaded as part of the boot process and placed into system RAM. With v258 there's now native support for this: a new rd.systemd.pull= kernel command line option may be used to download DDIs or tarballs into a tmpfs, optionally authenticate them, and then boot into them.

3️⃣1️⃣ Here's the 31st post highlighting key new features of the upcoming v258 release of systemd. #systemd258

In v256 we added "systemd-ssh-generator", which – among other things – would bind sshd to an AF_VSOCK socket if that is supported on the system, i.e. if booted inside a VMM that supports AF_VSOCK communication. It greatly simplifies talking to a VM from the host, in environments that support this.

Except of course, it's not quite as easy as it might appear conceptually:

@agowa338 @siosm not sure what you are going on about, but the way the trust chain concept works on modern computers is that you boot up in a trusted state, and then chain everything else from there. Hence of course, you reboot to reset the state, to get your trust chain into a clean state again?

Note that all of systemd's factory reset work actually runs from the initrd, i.e. under the assumption of an UKI world in a fully vendor signed part of the OS with only minimal input from elsewhere.

@siosm you definitely need to reboot, to get back into an unbroken chain of trust. Now you have two ways to ensure this works. First of all you physically request the reset early during boot. That's why we have this in the boot menu. Or you ask for the reset from the compromised running system, and then use some form of attestation to validate that the reboot was genuine. The latter is stuff bigger deployments (i.e. companies which actually do attestation) can do, …

@agowa338 @siosm sure, if you can afford to dump all hw on the trash and never use them again, if you have the suspicion that they got compromised, knock yourself out. Not cool for the environment, kinda wasteful, but whatever.

I am pretty sure most people outside your bubble probably prefer a reasonable mechanism to maybe not waste all those resources, and get a clear and reasonably secure way to get the systems back to work.

@agowa338 @siosm

also, it's actually mostly fine to boot from a compromised disk as long as every resource involved is properly authenticated. Of course, the less you boot the better, but again when resetting the disks like this we do this from the initrd, i.e. from the signed, vendor-supplied UKI in a short-lived environment, not from the rootfs that might be user (and thus attacker) controlled.

But I think ultimately we can just agree to disagree on the security model, no?

@agowa338 @siosm

we are dumping the *state* on the trash. But a signed UKI isn't precisely "state". It's firmware-authenticated immutable vendor code.

But dunno, I think we should end this here. You have your security model, I have mine, let's just agree to disagree on it.

@agowa338 @bluca @siosm you can store the UKI signing key on any pkcs11 device btw, i.e. a yubikey if you like. An attacker who takes over your system shouldn't be able to get to that, if you lock it with pin + fingerprint.

@agowa338 @siosm sure if you make your UKI signing keys accessible to an attacker then of course there's no way to recover. Maybe don't do that then...

@agowa338 @siosm if you compile your own kernels you are your own OS vendor. In that case you better take care of your signing keys.

But this is not how most Linux distros or big installs are set up: they run kernels put together and signed on build systems, and those are distinct from the systems they are run on, and the signing keys are not available there.

1️⃣2️⃣ Here's the 12th post highlighting key new features of the upcoming v258 release of systemd. #systemd258

I believe a fundamental aspect of OS security must be a secure way to return the OS into a well-defined, secure state if a compromise has been identified.

Fending of an attacker is one thing, accepting that it might happen anyway and that you can recover from that in a reasonable way is another. And that's the case not only if you think about "cattle" style installs…

But only to some point. First of all "reinstalling your Linux" is not precisely a trivial operation, and secondly, in today's world it's actually not really going to suffice in many ways. That's because it's not sufficient to erase your HDD an reinitialize it. There's more state to reset. One of them in particular is the TPM: local key material is derived from or protected by a "seed" key stored on the TPM.

… (i.e. lots of similar systems running the same OS image), but equally on "pet" style installs (i.e. your personal device).

Or to turn this around, a system that doesn't come with a clean, well defined mechanism to reset it fully, erase all unauthenticated data and return it to a vendor image without any local modifications, is highly problematic I believe.

Now you might say: "I can always reinstall my Linux" and start from scratch. And to some point you are right even.

And once the system comes back again the system is fully reset.

This currently does not cover EFI var NVRAM reset natively, but there's a clean plugin interface now to do that eventually (two actually: one place where you can plug in such code *before* we reboot, and one place *after* we reboot). [I'd expect that in one of the next releases we'll add another plugin for this, that erases certain EFI vars in NVRAM].

With v258 we considerably extended this work.There's now a well defined way to extend the factory reset logic so that other subsystems can be reset too. And we do ship one plugin for that (which is enabled by default), that requests a TPM reset from the firmware.

If your OS is properly set up for that you can now issue "systemctl start factory-reset.target". This will initiate a reboot, but a special one, where first the firmware will reset the TPM, and then the OS will reset its own state.

If you do not invalidate the old seed key and generate a new one, then all secrets associated with the compromised install (and thus tainted) will remain valid.

And there's more: there are various bits stored in EFI vars NVRAM that need to be reset too (shim keys for example).

systemd for a longer time has had really nice support for resetting your HDD (i.e. securely erase partitions, via the systemd-repart FactoryReset= knob) if a factory reset is requested.

There's also now a Varlink based API to query the current factory reset state (i.e. is a factory reset pending for the next reboot, or are we currently executing one for the current boot, or did we already finish one for the current boot, or is none pending nor executing).

If you want to learn more about the factory reset concepts in systemd, there is a new document for this:

https://github.com/systemd/systemd/blob/main/docs/FACTORY_RESET.md

In v258 we updated this area substantially. There's now a Varlink IPC call to subscribe to all DNS configuration changes (io.systemd.Resolve.Monitor.SubscribeDNSConfiguration() on /run/systemd/resolve/io.systemd.Resolve.Monitor).

If you issue this you'll get a stream of updates of the DNS configuration as they happen.

Why is this useful? This is used by systemd-networkd-wait-online's new --dns switch. If specified it will not only wait until a suitable network interface with…