Lennart Poettering
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…
Lennart Poettering
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
Lennart Poettering
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.
Lennart Poettering
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.
Lennart Poettering
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].
Lennart Poettering
… (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.
Lennart Poettering
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.
Lennart Poettering
@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, …
Timothée Ravier
@pid_eins The threat model is unclear here. How can you trust the system to really reset itself if you think it's compromised and run this command from a compromised environment?
Later you mention a boot entry, which makes more sense to me, but we would need something to not expose it too much as it would be too easy to select by mistake on boot. You would also likely need two reboots there, one to reset the TPM, and then do the reset?
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.