Notices by Lennart Poettering (pid_eins@mastodon.social)

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

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

One of systemd-resolved's fundamental jobs is to maintain per-interface and global DNS configuration (as well as per-delegate configuration, as described earlier in this series). We always provided D-Bus APIs to query the current state of this, and "resolvectl" to a large degree is just a wrapper around that.

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

The concept of system credentials has existed since a while in systemd. It allows parameterizing the system (and the services running on it) in a secure and hierarchical way. You can pass them into containers and into VMs, for example via SMBIOS Type #11 vendor strings. While the transport is low-level and firmware compatible, they can reasonably only be consumed in userspace.

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

Most Linux folks probably spend much of their day in their terminal emulator. Such emulators ultimately reimplement in software what dedicated hardware terminals did in the 1980's and before. While the protocol terminals speak didn't change much in its most basic concepts, various extensions have been added over the years to integrate terminal emulators better with the windowing…

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

On modern Linux systems the persistent hostname is configured in /etc/hostname. Linux people treating their devices like pets tend to come up with nice, imaginative names for their hosts.

But this doesn't scale: if you have a large number of devices to manage (i.e. "cattle") then you typically want something more automatic: the hostnames used should follow some specific pattern, …