Systemd 260: TPM2, sandboxing, and new capabilities in Linux

Hardware Guide » Buying Guides » Systemd 260: TPM2, sandboxing, and new capabilities in Linux

With the arrival of systemd 260, Linux distributions are taking another important step towards a more modern, secure ecosystem geared towards cloud environments, virtualization, and automation. This version doesn't just polish details: it introduces significant changes to booting, service management, networking, the use of TPM2 for integrity and encryption, and drive-level sandboxing capabilities.

At the same time, the project is strengthening its documentation and its approach to working with artificial intelligence agents , making it clear that systemd is a critical pillar to which more and more development and observability tools are connecting. If you manage Linux systems on servers, in the cloud, on corporate desktops, or in labs, it's worth taking a moment to review all these new features to plan for updates and configuration adjustments.

A final goodbye to System V and total dependence on native drives

One of the most striking changes in systemd 260 is the complete removal of support for System V scripts . The classic boot process based on /etc/init.d had been phased out for years, but now it effectively disappears from the systemd code.

This means that the components responsible for bridging between SysV scripts and native units have been removed: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator, and systemd-sysv-install no longer exist. As a result, any service that still depends on these legacy mechanisms will simply not start on systems that adopt systemd 260.

During the cleanup process, several Meson build options have also been marked as obsolete or removed. The flags -Drc-local=, -Dsysvinit-path=, and -Dsysvrcnd-path= have been relegated to the archives, while others like -Dintegration-tests= and -Dcryptolib= have been removed altogether. This sends a clear message: everything must now be handled by native units and the modern systemd infrastructure.

For many European infrastructures that still rely on older components, this change necessitates a review of internal services, custom scripts, and legacy deployments. Migrating to well-defined unit files is no longer just recommended; it's mandatory if you want to continue running services on distributions that integrate systemd 260.

Higher kernel requirements and a focus on current environments

The new version raises the bar for the kernel: from now on, the minimum supported Linux version is 5.10 , leaving behind very old branches like 5.4. Furthermore, the project indicates that ideally, users should work on a 5.14 kernel or higher , and especially recommends the 6.6 series to take full advantage of all available features.

This increase in requirements is not usually a problem in modern distributions, but it can complicate matters in very conservative environments or embedded solutions maintained for many years. Before upgrading to systemd 260, it's advisable to verify which kernel is being used, especially in European data centers with long-term deployments or custom images.

At the opposite end of the spectrum, rolling release distributions like Arch Linux or openSUSE Tumbleweed, very popular among those who want the latest features, tend to quickly incorporate both new kernels and new branches of systemd. Others, like Fedora, maintain a degree of stability in the major version of systemd throughout the lifecycle of each release, which allows for a bit more time to plan migrations.

TPM2, boot integrity, and advanced SRK support

One of the areas where systemd is evolving the most is in its integration with TPM2 (Trusted Platform Module 2.0) . This chip, increasingly common in modern UEFI motherboards and mid-range and high-end hardware, allows for anchoring secrets to the system state, measuring boot phases, and automatically unlocking encrypted volumes when the environment is as expected.

Systemd 260 further enhances this integration by adding tools and services that cover different stages of the boot process. A key component is systemd-tpm2-setup , responsible for preparing the infrastructure around the TPM's Storage Root Key (SRK) . This root key serves as the cryptographic foundation for securing communication with the chip and for securely storing other secrets.

During boot, two phases are distinguished: a very early one in the initrd and another once in the root system. In the first, a service called "Early TPM SRK Setup" checks if the TPM already has a stored SRK and, if it doesn't exist, creates it and makes it temporarily available under /run/systemd/tpm2-srk-public-key.* . Later, once the real filesystem is mounted, the service will consolidate the SRK and verify that the key stored in /var/lib/systemd/tpm2-srk-public-key.pem matches the one in the TPM.

In well-configured scenarios, journal entries such as "SRK is already stored in the TPM" and messages indicating that the SRK footprint matches the expected one will be displayed. However, if the environment is not properly configured (for example, in setups using Yocto or on boards like Raspberry Pi with SPI-based TPM and custom boot methods such as U-Boot and measured boot), situations may arise where systemd fails to create these files under /var/lib/systemd, raising doubts about whether the SRK has been configured correctly.

When the TPM state has changed, partitions have been modified, or the boot sequence has been altered, the associated policy may no longer be valid. In such cases, some maintainers recommend clearing the TPM slot or policy and re-registering the key , following procedures similar to those described in disk encryption guides with TPM in environments like openSUSE, which detail how to recreate the PCR policy and re-link volume unlocking.

Aside from the SRK, another practical improvement is the introduction of an internal utility called tpm2_id in udev . This integrated tool runs when the system detects a TPM2 device and automatically extracts the manufacturer and model identifier . This simplifies the inventory of security hardware, which is very useful in public administrations, regulated companies, or critical infrastructures where it's essential to know precisely which TPM modules are deployed.

Integration with the boot measurement infrastructure is further strengthened by specific units like systemd-pcrextend , which log events such as "enter-initrd", "leave-initrd", "sysinit", and "ready" in various PCRs (e.g., PCR 11). This sequence of extensions allows the TPM to accumulate a cryptographically verifiable record of the boot flow, which can then be used for Trusted Boot policies or for UKI (Unified Kernel Images) to validate the machine's state before releasing keys.

Security measures and sandboxing of services with systemd

Systemd not only starts processes, but also offers a comprehensive set of sandboxing directives to isolate services and limit damage in the event of a compromise. This "defense in depth" approach relies on cgroups, namespaces, kernel capabilities, and system call filters (seccomp).

To assess the security of a specific service, systemd includes the systemd-analyze security tool . Running it generates a report with an exposure score on a scale of 0 to 10, where a lower score is better. The report breaks down which protections are enabled or disabled (network isolation, file system access, device access, etc.), making it easy to identify missing settings and verify whether changes actually improve the score.

Instead of editing the original unit—which would be lost in future package updates—it is recommended to create a override en /etc/systemd/system/mi-servicio.service.d/ with a file, for example, sandbox.confAfter modifying it, simply reload the configuration with systemctl daemon-reload and restart the service so that the new restrictions take effect.

At the file system level, one of the most important options is ProtectSystem=Values ​​such as strict, full o true They mount different parts of the tree in read-only mode. The usual practice, when possible, is to use ProtectSystem=strictThis makes /usr, /boot, /efi, and /etc read-only for the service. If an application needs to write to specific directories, it is allowed to do so using ReadWritePaths=/path in unity.

To further enhance privacy, it is also recommended to restrict access to user directories using `ProtectHome=true` , which prevents the service from reading `/home`, `/root`, or `/run/user`. Additionally, `PrivateTmp=true` creates isolated `/tmp` and `/var/tmp` spaces, preventing cross-visibility of temporary files between processes.

In devices, `PrivateDevices=true` hides the actual `/dev` tree and replaces it with a minimal set of safe pseudo-devices (null, zero, random, etc.). If a drive needs a specific device (for example, a serial port or a disk block), it can be granted using `DeviceAllow=/dev/xxx rw` or in read-only mode.

The network is also a key vector. With PrivateNetwork=true An isolated network namespace is created, leaving only the loopback; the service will not see physical interfaces and will not be able to communicate with the outside world. Alternatively, you can restrict which address families it can use by RestrictAddressFamilies=allowing only AF_INET and AF_INET6 for IPv4/IPv6, AF_UNIX for local sockets or even none to fully Japanize network capabilities.

Regarding privileges, the `NoNewPrivileges=true` directive is one of the most powerful: it prevents the process from acquiring new privileges through setuid binaries or capability changes. In short, even if the service executes vulnerable code, it should not be able to escalate to root through traditional mechanisms. Combined with `CapabilityBoundingSet=` , which defines the exact list of allowed capabilities (for example, only `CAP_NET_BIND_SERVICE` to listen on low ports), the attack surface is minimized.

To go even further, systemd allows filtering system calls with SystemCallFilter=Instead of maintaining a manual list of syscalls, predefined groups are used, such as @system-service, @network-io, @basic-io or deny groups like ~@privileged. With systemd-analyze syscall-filter It's possible to inspect which specific calls belong to each group. This allows for the construction of a very limited execution profile, similar to what a dedicated sandbox would offer.

Other relevant settings include `ProtectKernelTunables=true` , which blocks modification of kernel parameters in `/proc/sys` and `/sys`; `ProtectKernelModules=true` , which prevents loading or unloading modules; `ProtectKernelLogs=true` , which prevents reading kernel logs; and `ProtectControlGroups=true` , which blocks writes to the cgroups hierarchy. All of this works seamlessly with new user isolation capabilities such as ` PrivateUsers=full` , which in version 260 is updated to map the full range of user IDs, eliminating previous workarounds required for nested systemd environments.

PrivateUsers, xaccess, and new device access controls

The PrivateUsers mechanism , designed to allow services to run in an isolated user ID space, is consolidated in systemd 260. The PrivateUsers=full option now maps the full range of identifiers, simplifying things in containers and on systems with nested systemd instances based on older versions (prior to 257). This improvement has eliminated hacks that were previously used to detect these older instances.

In parallel, components like systemd-logind and systemd-udevd introduced the concept of xaccess . This mechanism complements the classic logic of uaccess , which grants access to certain devices (for example, audio or video) to users with foreground graphics sessions on the local machine. With xaccess, permissions can be delegated to remote users with specially marked sessions , so that, for example, a user connected via remote desktop can access local GPU rendering devices without granting broad permissions to the entire system.

The configuration of these sessions involves environment variables exposed via PAM, specifically PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , which allows defining which specific devices are included in this logic. This approach is highly aligned with the regulatory compliance and data protection requirements of the European Union, where granularity and traceability are demanded for access to sensitive hardware.

mstack, systemd-mstack and new container tools

In the area of ​​containerization, systemd 260 introduces the functionality mstack and an associated command, systemd-mstackThe idea behind mstack is to allow defining a OverlayFS based on the structure of a special directory called .mstack/, which follows a specific specification for organizing its layers.

The new command-line tool, systemd-mstack, makes it easier to work with these file system stacks interactively, adding flexibility when setting up layered environments for containers or highly isolated services. This functionality is also linked to improvements in systemd-importd , which expands its support for downloading and managing OCI images , thus reinforcing systemd's role as a containerization and sandboxing engine, something very common among European cloud providers and modern hosting platforms.

Network: Integration with ModemManager and new performance options

At the network layer, systemd-networkd continues to gain importance. One of the notable new features is its integration with ModemManager via the "simple connect" protocol , which allows modems and mobile connections to be managed directly from networkd without relying on external tools.

To support this flow, a new section is added. to the configuration files, with parameters such as APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=This facilitates deployments in rural areas or environments with connectivity based on mobile networks, very present in certain territories of Europe where there is not always fiber or quality landlines.

In terms of performance, the systemd-networkd .link files include new options specifically for Ethernet devices. These include ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList, and GenericReceiveOffloadUDPForwarding . These options allow for fine-tuning the offloading of work to the hardware and drivers, which is crucial in corporate networks, data centers, and service providers that need to minimize every millisecond of latency.

Furthermore, systemd-networkd's Varlink and JSON interfaces can now report IP addresses in a human-readable format (strings) while maintaining the representation as an integer array. This simplifies integration with monitoring dashboards, management scripts, or third-party tools that don't want to deal with unintuitive numeric formats.

Service portability, ephemeral virtual machines, and unprivileged services

The systemd-portabled component , responsible for managing "portable" services packaged in images, gains a very interesting capability: it can now run as a user-level service . This means that unprivileged users, in their normal session, can launch and manage portable services within their own space without resorting to sudo or elevated privileges.

Furthermore, starting with this version, portabled can generate policies and lock the image associated with a portable service , preventing modification of that image without reattaching it. This allows users to set up self-contained environments with added immutability guarantees, a particularly attractive feature for labs, development environments, and test sandboxes.

On the other hand, systemd-vmspawn —the tool designed to launch virtual machines in an integrated way with systemd—expands its capabilities to register with systemd-machined within the user session . It also introduces an `-ephemeral` option to create ephemeral machines that are destroyed upon completion of their use. This is a perfect fit for CI/CD pipelines, virtual classrooms, or European educational platforms that require the rapid and controlled creation and destruction of virtual machines.

Fine-tuned control of CPU, memory, and scheduling with SCHED_EXT and THP

Systemd 260 also delves into performance control with new policies. The service option CPUSchedulingPolicy= now accept the value ext, which activates the scheduler SCHED_EXTThis alternative planner opens the door to experiments with different planning policies to the kernel standards, something that may be of interest in R&D laboratories or in highly specialized deployments.

In the memory area, you'll find `MemoryTHP=` , which allows you to manage the use of Transparent Huge Pages (THP) on a per-service basis. Instead of a system-wide, global setting, you can decide whether a specific unit should utilize THP, disable it, or adopt intermediate modes. For critical applications in banking, insurance, or government, this granular control can make a significant difference in latency, memory consumption, and performance.

New commands in systemctl and expanded use of Varlink

The familiar systemctl command gains a new one: enqueue-marked . This action internally invokes the D-Bus method EnqueueMarkedJobs() and allows working with queues of pre-marked jobs and services. While it may seem like a minor detail, for operations teams orchestrating large-scale server farms, it's another tool for refining deployment and automation workflows.

In parallel, the project continues to expand the use of Varlink as a communication mechanism between components. Many parts of systemd expose stable Varlink interfaces, which facilitate integration with external tools, custom dashboards, or monitoring agents that require structured access to system information.

System identification fields and user experience

A curious but useful new feature for some distributions is the introduction of the field FANCY_NAME= in the File /etc/os-releaseThis field resembles PRETTY_NAME, but allows ANSI sequences and more elaborate Unicode charactersThanks to this, specific distributions and editions can be presented with more eye-catching or distinctive names.

The value of FANCY_NAME can be viewed through the systemd manager, using systemd-hostnamed or by querying hostnamectl . Although it's a small change, in desktop environments and graphical administration panels it can be useful for quickly identifying the system being managed, especially when handling many derivative variants.

Specific documentation for AI agents and assisted review workflow

One of the most interesting signs of the direction systemd's development is the appearance of documentation specifically geared towards artificial intelligence agents . The repository includes an AGENTS.md file , designed to help code analysis tools and programming assistants, as well as some technology guides , better understand the project's architecture, style, development flow, and contribution guidelines.

This document describes components, build paths, how to run tests and integrations, and guidelines for generating acceptable patches. The intention is to provide AI agents that review code or make changes with a solid understanding of how systemd is organized , reducing errors and misplaced suggestions.

Alongside AGENTS.md is a file called CLAUDE.md , which explicitly references the former and is designed to guide the Claude Code tool, one of the most widely used AI-based development assistants. In this way, the project explicitly incorporates AI into its development cycle.

Additionally, a configuration file is included. claude-review.ymlwhere it is defined how the process of analyzing change requests (pull requests) should be reviewed, with the help of Claude Code. In this context, contributions that have used AI are required to incorporate disclosure labels , the Co-developed-by in the patches, leaving evidence that an automated tool has participated in the creation of the code.

With this comprehensive set of changes—cleaning up legacy support, refining sandboxing, improving TPM2 and SRK, advanced network integration, new portability capabilities, and documentation designed for intelligent agents— systemd 260 reinforces its central role in the modern Linux ecosystem. For administrators and developers in Spain and Europe, the immediate challenge lies in reviewing kernels, adapting boot configurations and services, and leveraging these features to build more secure, automated infrastructures aligned with current system usage.