systemd 262 locks sealed credentials to the TPM
The release blocks a man-in-the-middle route to TPM-sealed secrets, drops udev’s legacy control socket and tightens reloads for notify services.
systemd 262 is out, tagged on 22 September, and the change with the most security value is in how sealed credentials are protected. The project’s own changelog is long, as usual, but three entries matter more than the rest for anyone running Linux systems in anger.
Credentials are pinned to the chip that sealed them
TPM-sealed credentials are now pinned to the TPM’s storage root key. The stated purpose is to stop man-in-the-middle interposer attacks from stealing decrypted credentials, by making sure communication with the TPM is protected by a private key that only the same TPM the credential was sealed to actually knows. The change also makes sealed credentials usable when the TPM’s owner hierarchy is protected with a PIN, which was previously awkward.
There is a compatibility edge to it. Credentials minted after this change are not recognised by older systemd versions, while the new systemd continues to accept credentials sealed before it. In other words the direction of travel is one-way, and a rollback to an older release is where that bites.
udev loses its legacy control socket
The legacy socket used to control systemd-udevd has been removed, and udevadm now uses Varlink IPC unconditionally. The old UNIX socket at /run/udev/control, which plenty of monitoring scripts probe to decide whether udevd is running, has been replaced with a symlink to the Varlink socket. The symlink is deliberately kept so the socket is bound under the same conditions as before, but the legacy protocol is not supported on that path, so anything that speaks the old wire format needs updating.
Notify services must handle reload signals before they report ready
Services of Type=notify-reload now have to catch or block ReloadSignal= at the moment they send READY=1. A service that does neither will fail to start with a protocol error. Previously such a service was allowed to start even though a later reload could invoke the signal’s default action and terminate it, which turned a configuration mistake into an outage that arrived later, in the middle of a reload.
The smaller changes worth knowing
DNS-SD services registered through systemd-resolved’s D-Bus RegisterService() call are now unregistered automatically when the client that registered them disconnects from the bus, which matches how Avahi behaves. Clients must hold the bus connection open for as long as the service should stay registered, and one-shot registrations made with busctl or gdbus are withdrawn as soon as the tool exits. Anything that needs to outlive its caller should use a *.dnssd file instead.
The sysupdate units have been renamed: systemd-sysupdate.service and .timer become systemd-sysupdate-update.service and .timer, with compatibility symlinks provided, clearing the way for a Varlink-activated systemd-sysupdate@.service. Default OpenPGP keyring lookup now combines the vendor keyring in /usr/ with the local keyring in /etc/, so deployments that relied on a single /etc/ keyring to exclude vendor trust should set the keyring explicitly in the environment. systemd-repart no longer honours the legacy FactoryReset EFI variable inside the initrd, systemd-repart expands specifiers in symlink targets as well as sources, and five deprecated meson options covering libiptc, libidn, rc-local and the sysvinit paths have been removed.
What version 263 will take away
The changelog also announces two removals coming in 263. Support for the /run/boot-loader-entries/ directory and its related interfaces goes, on the grounds that no project appears to use it, while support for the UAPI.1 boot loader specification itself stays. The experimental systemd-sysupdated D-Bus API also goes, with clients expected to talk to systemd-sysupdate directly over Varlink instead.
Our opinion
The TPM change is the kind of security work that never makes a headline and quietly closes a whole class of attack. Pinning a sealed credential to the storage root key of the chip that sealed it is a much better answer than hoping nobody sits between the operating system and the TPM, and it is the sort of fix that only exists because somebody thought about the threat model rather than the changelog.
The udev socket removal is less comfortable. Turning /run/udev/control into a symlink keeps the socket present and keeps old health checks returning something, but it also keeps alive a check that no longer means what its author assumed. Systems that report healthy because a socket exists will keep reporting healthy, and the notification about that arrives when udev misbehaves rather than when it moves.