Linux

systemd 261: A Local Metadata Proxy That Doubles as a Security Control

The systemd-imdsd service brokering cloud metadata requests between local programs and the provider endpoint.

Most systemd release writeups lead with the feature count. The more interesting story in systemd 261 is that one of its new features is a defensive control against a class of cloud attack that has been quietly wrecking people for years: the metadata-server token theft that turns one application bug into full cloud-account takeover. The headline addition, systemd-imdsd, is billed as a convenience layer, but its access-restriction option is the part worth your attention. That framing shapes this rundown: the security-relevant changes first, the rest after. Credit to Bobby Borisov for the original release coverage.

systemd-imdsd and Why It Matters for Security

Every major cloud exposes an Instance Metadata Service (IMDS) at the link-local address 169.254.169.254, where a workload can fetch its identity, config, and short-lived credentials. The convenience is also the danger: any code that can make an outbound HTTP request from the instance, including code an attacker reaches through an SSRF or command-injection bug, can hit that endpoint and walk away with a service-account token. I walked through that full chain in how one bad parameter becomes a cloud takeover, and it remains one of the most reliable escalation paths in cloud infrastructure.

systemd 261 introduces systemd-imdsd, a local Varlink-based service that gives programs a unified interface to cloud metadata instead of each one talking directly to the provider's endpoint. It identifies the platform from SMBIOS data via a hardware database (hwdb.d/40-imds.hwdb) and supports the major clouds: Amazon EC2, Microsoft Azure, Google Compute Engine, Hetzner, Oracle Cloud, Scaleway, Tencent Cloud, Alibaba ECS, and Vultr.

The convenience angle is real, one API rather than nine provider-specific quirks. But the security angle is the one to plan around:

⚠️ systemd 261 also adds an option to restrict network access to the cloud metadata service for recognized clouds. The release notes recommend it for secure installations, and it's precisely the mitigation the token-theft chain needs: if arbitrary in-instance code can no longer reach 169.254.169.254 directly, and must instead go through a brokered, controllable interface, you've closed the raw-curl-to-the-metadata-endpoint path that most of these exploits depend on. This is the OS-level version of the egress-blocking mitigation I recommended in that attack writeup, now shipped in the init system rather than something you bolt on with firewall rules.

⚠️ The catch, and the release notes are honest about it: restricting direct metadata access conflicts with traditional IMDS clients like cloud-init, which expect to hit the endpoint directly. So this is not a flip-and-forget toggle. On a cloud-init-provisioned instance (which is most of them), turning on the restriction without routing cloud-init through the new interface breaks provisioning. The realistic near-term play is: enable it on instances that don't depend on direct-access IMDS clients, or on long-lived hosts after first-boot provisioning is complete, and watch for the ecosystem to catch up. It's the right direction, but it lands in a world built around the old assumption.

TPM and Measured Boot

Several changes here, relevant if you care about boot integrity:

ConditionSecurity=measured-os, a new unit condition that checks whether the system booted with measured-boot semantics. It's a more generic sibling to ConditionSecurity=measured-uki, applying where TPM functionality is provided at the OS level rather than tied specifically to a Unified Kernel Image.
systemd-boot and systemd-stub now measure SMBIOS Type 1, 2, and 11 data into PCR 1, covering the case where firmware fails to perform these measurements itself. That closes a gap where an unmeasured firmware left those values out of the attestation chain.

For anyone building attestation-gated services, ConditionSecurity=measured-os is the useful one: a unit that simply refuses to start unless the machine actually booted measured, expressed declaratively in the unit file rather than scripted.

Live Update, kexec Handover, and State Preservation

This is the operationally interesting cluster. The service manager now supports the kernel's Live Update Orchestration and Kexec Handover mechanisms where available. Practically:

System units can preserve their file-descriptor stores across a kexec if the kernel supports it and FileDescriptorStorePreserve=yes is set.
User session managers can now persist user units' FD stores too, so certain user services retain state across session restarts and kexec reboots.

⚠️ Worth being precise about what this does and doesn't give you. It preserves file descriptors, open sockets and files a service handed to systemd for safekeeping, across a kexec, so a service can survive a kernel swap without dropping its listening sockets or established connections. It is not live-migrating running process memory. For a socket-activated service, though, it's the difference between a kexec-based kernel update that drops every connection and one that doesn't, which matters on hosts where you'd otherwise avoid kexec updates entirely.

ConditionFraction: Staged Rollouts in the Init System

A genuinely useful addition for anyone managing a fleet: ConditionFraction=, a unit condition for percentage-based staged rollouts. It uses the machine ID plus a tag string to deterministically decide whether a unit runs on a given percentage of systems.

The value is that it's deterministic per machine, not random, so a given host stays consistently in or out of the rollout cohort across restarts as long as the tag and percentage hold. That makes it a canary mechanism at the unit level: ship a new unit to 5% of the fleet, confirm it behaves, widen to 25%, then 100%, all through a single condition rather than external orchestration. If you run configuration management across many hosts, this is a native alternative to templating rollout logic into your Ansible or writing a wrapper, the same fleet-staging problem the Terraform/Ansible workflow solves at the provisioning layer, now available at the unit level.

networkd and resolved

Networking gets several quality-of-life improvements:

networkctl dhcp-lease INTERFACE displays the acquired DHCP lease, including options received from the server, no more grepping lease files.
networkd exposes Varlink methods for describing, reconfiguring, renewing, and force-renewing links, and networkctl prefers them where possible.
systemd-resolved gains static DNS resource records from JSON drop-in files under systemd/resolve/static.d/, extending what /etc/hosts does with a more flexible drop-in model. It also adds cache-size settings for DNS, MulticastDNS, and LLMNR, and now re-reads /etc/hosts on reload.

The static-records drop-in is the sleeper feature: it lets you define local DNS data (not just A/AAAA host mappings but other record types) through the drop-in config model, which is far more manageable across a fleet than hand-editing /etc/hosts on every box. On Proxmox and homelab setups where you're juggling internal name resolution, this is a cleaner path than the usual /etc/hosts sprawl, and it complements the Netplan and resolved DNS setup on the systemd-resolved side.

Boot and Update Tooling

systemd-stub now maintains a "boot secret" derived from a persistent EFI variable, as fallback key material when a TPM is unavailable. It also detects the active EFI serial console and passes the matching console= parameter to the kernel, which simplifies serial-console deployments with UKIs.
systemd-boot keeps the previous binary as a fallback when installing a new version and creates a fallback UEFI boot entry, so a bad boot loader update doesn't strand the machine.
systemd-sysupdate is now non-experimental and installed in /usr/bin/ alongside other user-facing tools.

⚠️ The systemd-boot fallback is the quietly valuable one for remote/headless hosts: a botched boot loader install has historically meant a rescue-console trip, and an automatic fallback entry is exactly the safety net you want on a box you can't walk over to.

Containers and VMs

systemd-nspawn adds journal-forwarding from the payload to selected journal sockets, and can preserve the payload manager's FD store across container restarts.
systemd-vmspawn gets a substantial batch: bind-volume support, headless console operation, EFI NVRAM state handling, direct kernel boot without UEFI firmware, selectable image disk types, and runtime storage manipulation via the io.systemd.MachineInstance Varlink interface.

systemd-vmspawn is maturing into something genuinely usable for lightweight VM workflows, direct kernel boot without firmware in particular is a meaningful speedup for throwaway test VMs.

Deprecations Coming in 262

Plan ahead if any of this touches your tooling:

Support for /run/boot-loader-entries/ and related interfaces will be removed in 262 (UAPI Boot Loader Specification support stays).
The experimental systemd-sysupdated D-Bus API will be removed; clients should move to Varlink to talk to systemd-sysupdate directly.

Bottom Line

systemd 261 is a substantial release, but the piece worth acting on deliberately is systemd-imdsd and its metadata-access restriction, because it's a real OS-level control against the cloud-credential-theft chain, provided you sequence it around cloud-init's expectations rather than flipping it on blind. Past that, ConditionSecurity=measured-os for attestation-gated units, kexec FD-store preservation for connection-surviving kernel updates, ConditionFraction= for native fleet-staged rollouts, and the systemd-boot fallback entry for headless hosts are the changes most likely to earn their place in a production setup. As always with systemd, the feature list is long; the subset that changes how you actually run infrastructure is shorter, and this time it leads with a security win.