systemd 257 per sysadmin: le novità che contano e i CVE da patchare

Quando aggiorni un parco di server da Debian 12 a Debian 13 trixie, uscita il 9 agosto 2025, il salto che conta sotto il cofano è quello di systemd: si passa dalla 252 di bookworm alla 257, con in mezzo cinque anni di release upstream condensati in un solo aggiornamento. Non è un dettaglio da changelog: systemd è il primo processo che parte, governa ogni servizio, ogni socket, ogni log, e una sua major nuova cambia comportamenti che davi per scontati. In un lavoro di migrazione infrastrutturale per una PMI con qualche decina di macchine, la differenza tra un upgrade liscio e una nottata a rincorrere servizi che non ripartono sta quasi sempre nel sapere prima cosa è cambiato. systemd 257, oltre alle feature nuove, porta con sé una deprecazione importante e un CVE su systemd-nspawn che un sysadmin deve conoscere e patchare. Vediamo cosa cambia davvero nella gestione quotidiana, cosa va adottato, cosa va sorvegliato, e qual è il modo corretto di mettere mano a un'unit senza romperla al prossimo aggiornamento.

Le novità di systemd 257 che cambiano la gestione quotidiana

La lista completa è lunga, ma poche voci hanno impatto reale sul lavoro di chi gestisce servizi. La prima è run0, un'alternativa a sudo per acquisire privilegi elevati in modo temporaneo e interattivo, senza il setuid binary e con un modello di sicurezza diverso (l'elevazione passa per il service manager, non per un binario privilegiato). Non sostituisce sudo dall'oggi al domani, ma è il segnale di dove sta andando la gestione dei privilegi su Linux. Sempre tra i nuovi strumenti, systemd-vpick introduce un sistema di binary versioning che risolve i percorsi alle directory versionate .v/, permettendo di gestire più versioni di un'applicazione senza collisioni di path: utile quando devi tenere in piedi più release dello stesso servizio su una macchina. C'è poi varlinkctl, che consente di introspezionare e invocare i servizi Varlink, l'API IPC che systemd sta adottando per sempre più interfacce interne.

Sul fronte dell'osservabilità dei servizi arrivano due impostazioni che adotto volentieri: CPUPressureWatch= e IOPressureWatch=, con le relative soglie, che permettono a un servizio di ricevere notifiche sugli eventi di pressure (la metrica PSI del kernel) su CPU e I/O. È un modo nativo per agganciare logiche di backpressure senza tooling esterno, e si lega bene a un approccio di monitoring del VPS orientato alla prevenzione del downtime. Aggiungo alla lista delle adozioni RefreshOnReload=, che aggiorna credenziali ed estensioni quando l'unit viene ricaricata, e MinimumUptimeSec= (default 15 secondi), che definisce un uptime minimo del sistema ed evita certi cicli di riavvio patologici.

Per il debugging c'è una chicca utile: RestartMode=debug. Quando un servizio fallisce e deve essere riavviato, lo si invoca in modalità debug con la variabile d'ambiente $DEBUG_INVOCATION impostata a 1, così lo script di avvio può comportarsi diversamente solo nel riavvio diagnostico. Infine, una novità che consiglio di adottare subito sul piano della sicurezza: systemd-sysusers ora crea account completamente bloccati con il modificatore ! sulle righe u. Per quasi tutti gli account di sistema, che non devono permettere login interattivi, è la scelta giusta di default.

cgroup v1 è deprecato: cosa significa per i tuoi servizi

La notizia che pesa di più non è una feature, è una deprecazione. Da systemd 257 il supporto per cgroup v1 è considerato obsoleto e il service manager, per impostazione predefinita, ignora le configurazioni che lo abilitano. Esiste una via di fuga temporanea, la variabile SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1, ma è esattamente questo: temporanea. La systemd 258 ha in programma la rimozione completa del supporto a cgroup v1, insieme agli script di servizio in stile System V.

Se hai ancora servizi o container che dipendono dalla gerarchia cgroup v1, systemd 257 è l'ultimo avviso prima del muro. Il momento di migrare a cgroup v2 e a unit native è adesso, non quando la 258 arriverà e ignorerà del tutto la vecchia configurazione.

Nel concreto, questo tocca soprattutto chi gira runtime di container datati o tooling di resource accounting costruito su cgroup v1. La verifica è semplice e va fatta in fase di pianificazione dell'upgrade, non dopo: controllare che i propri carichi non assumano la gerarchia legacy e, dove serve, aggiornare il runtime.

Se stai pianificando l'aggiornamento di un parco server Debian e vuoi affrontarlo con un metodo invece che a tentoni, nel mio profilo professionale trovi l'esperienza concreta su hardening e gestione di infrastrutture Linux in produzione, dalla migrazione al disaster recovery.

CVE-2026-40226: l'escape-to-host di nspawn, e perché su Debian 13 non si patcha con la 260

Veniamo al punto che un sysadmin non può ignorare. systemd-nspawn, il gestore leggero di container e macchine incluso in systemd, è affetto da CVE-2026-40226, una vulnerabilità di escape-to-host pubblicata ad aprile 2026. Il difetto sta in bug di parsing delle opzioni PivotRoot=, BindUser= ed Ephemeral= nei file di configurazione opzionali che accompagnano un'immagine: in certe condizioni il container viene avviato sul filesystem root dell'host invece che sull'immagine, e con privilegi elevati. Il punteggio è CVSS 3.1 pari a 6.4, fascia media, e va letto bene: il vettore è locale, la complessità è alta e i privilegi richiesti sono alti. Non è una falla worm-abile esposta su Internet, e non va triagiata come tale, ma su un host che esegue container nspawn alimentati da immagini di provenienza non pienamente fidata è un rischio concreto, perché la condizione chiave è che il file di configurazione malevolo venga raccolto da nspawn.

La vulnerabilità colpisce systemd dalla 233 alla 259, ed è corretta upstream nella systemd 260, rilasciata il 9 aprile 2026. Ed è qui che scatta l'errore di chi legge solo il titolo: Debian 13 trixie non monta la 260, monta la serie 257 (al momento dell'upgrade, le versioni pacchettizzate sono 257.x-deb13u). Su Debian stable non si "aggiorna a systemd 260" per chiudere il CVE: si applica l'aggiornamento di sicurezza che porta la correzione backportata sulla serie 257. È la differenza tra inseguire il numero di versione upstream e capire come funziona il security backporting di una distribuzione stabile. In pratica: apt update && apt upgrade con i repository di sicurezza abilitati, verificando che il pacchetto systemd installato sia la revisione deb13u che incorpora il fix. Come mitigazione immediata, finché non si applica la patch, ci si assicura che nessuna parte non fidata possa depositare file di configurazione nelle directory da cui nspawn li raccoglie automaticamente.

Vale la pena notare che la stessa systemd 260 ha chiuso altri due problemi locali: un privilege escalation in systemd-machined raggiungibile via Varlink e un'esecuzione come root in udev tramite dispositivi hardware malevoli. Tutti e tre seguono la stessa logica di patching su Debian: backport sulla serie 257, non salto di major.

Il pattern corretto degli override: modificare un'unit senza romperla

C'è un errore che vedo fare di continuo e che il prossimo aggiornamento punisce sempre: editare direttamente il file di unit fornito dal pacchetto, quello sotto /lib/systemd/system/. Quel file è di proprietà del package manager, e al primo apt upgrade di systemd o del servizio viene sovrascritto, portandosi via le tue modifiche senza un avviso. Il modo corretto è il drop-in override.

# crea (o apre) il drop-in in /etc/systemd/system/<unit>.d/override.conf
systemctl edit nginx.service

Il file che si apre è vuoto e va riempito solo con le direttive che vuoi cambiare. C'è però una trappola specifica sulle direttive di tipo lista, come ExecStart=: per ridefinirle devi prima azzerarle con un'assegnazione vuota, altrimenti la nuova si aggiunge alla vecchia invece di sostituirla.

[Service]
# prima azzera, poi ridefinisci: senza la riga vuota, ExecStart si accumula
ExecStart=
ExecStart=/usr/sbin/nginx -g 'daemon off; master_process on;'
# esempio di hardening incrementale che sopravvive agli upgrade
ProtectSystem=strict
PrivateTmp=true

Dopo l'edit servono systemctl daemon-reload e il restart del servizio. Per verificare il risultato effettivo, systemctl cat nginx.service mostra l'unit di base con tutti i drop-in applicati in ordine, e systemd-delta elenca ovunque la configurazione locale sovrascrive quella del vendor. Questo pattern è la differenza tra un hardening che resta e uno che evapora al primo aggiornamento, e si sposa con l'approccio incrementale che descrivo nell'hardening di server Debian e Ubuntu per applicativi PHP.

I comandi che uso per verificare lo stato dopo l'upgrade

Un upgrade di systemd non è finito quando la macchina riparte: è finito quando hai verificato che nulla si è rotto in silenzio. La sequenza che eseguo è sempre la stessa e merita di entrare nella routine di chiunque gestisca server. Si parte da systemctl --failed, che elenca le unit andate in errore: su un sistema sano deve essere vuoto, e se non lo è quello è il primo posto dove guardare. Subito dopo journalctl -p err -b, che mostra solo gli errori dall'ultimo boot, per intercettare i problemi che non hanno fatto fallire un'unit ma hanno comunque lasciato traccia.

systemctl --failed                 # unit fallite: deve essere vuoto
journalctl -p err -b               # errori dall'ultimo avvio
systemd-analyze blame              # cosa rallenta il boot, ordinato
systemd-analyze critical-chain     # la catena critica del boot
systemd-delta                      # dove la tua config sovrascrive il vendor
networkctl status                  # stato e nomi reali delle interfacce

systemd-analyze blame e critical-chain servono a capire se l'upgrade ha introdotto regressioni nei tempi di avvio, che spesso sono il sintomo precoce di un servizio che attende un timeout. networkctl status è il controllo che chiude il cerchio sul problema dei nomi delle interfacce: se dopo il reboot un'interfaccia ha un nome diverso da quello atteso, è lì che lo vedi. Questa verifica sistematica vale tanto su un singolo VPS quanto su un parco, ed è la stessa disciplina di controllo che applico, in chiave correttiva, quando intervengo su un filesystem Debian che va riparato con fsck dopo un reboot andato male.

Conviene aggiornare a systemd 257 adesso, e cosa sorvegliare?

Sì, ma non alla cieca: l'upgrade a Debian 13 porta tre cambiamenti di comportamento che possono rovinarti il reboot se non li conosci. Il primo, e il più insidioso su macchine senza accesso out-of-band, è il rinominamento delle interfacce di rete: systemd 257 usa un nuovo net.naming_scheme che, in certi casi (per esempio quando il firmware espone l'oggetto ACPI _SUN), assegna alle schede nomi diversi da quelli di bookworm, e un'interfaccia che cambia nome significa rete morta al riavvio. Si verifica prima con udevadm test-builtin net_setup_link, confrontando i nomi. Il secondo: systemd-tmpfiles ora cancella regolarmente i file vecchi in /tmp (dopo 10 giorni e al reboot) e /var/tmp (dopo 30 giorni); su Debian è opt-in e l'upgrade crea /etc/tmpfiles.d/tmp.conf per preservare il vecchio comportamento, ma se hai processi che parcheggiano stato in /tmp è una cosa da sapere. Il terzo: se usi filesystem cifrati, assicurati che il pacchetto systemd-cryptsetup sia installato prima di riavviare.

Questi comportamenti sono documentati nelle note di rilascio ufficiali di Debian 13, che vanno lette prima di toccare la produzione. Nessuno di questi è un blocco, ma tutti e tre sono la ragione per cui un upgrade di sistema operativo si pianifica e si prova su una macchina di staging, non si lancia in produzione un venerdì pomeriggio. La regola che applico è banale e non mi ha mai tradito: leggere le release notes della distribuzione prima, fare l'upgrade su una macchina gemella, verificare rete, servizi e log, e solo allora replicare sul parco.

Tirando le fila, systemd 257 su Debian 13 è una buona release, ma è anche un punto di svolta che chiede attenzione su tre fronti distinti. Le feature nuove (run0, le notifiche PSI, gli account bloccati di systemd-sysusers) sono adozioni a basso rischio e buon ritorno; la deprecazione di cgroup v1 è un conto alla rovescia che va affrontato ora, prima che la 258 lo trasformi in un problema; e il CVE su nspawn è un promemoria che anche l'init system ha la sua superficie d'attacco, da patchare con la correzione backportata sulla serie 257, non inseguendo la 260 upstream. Sotto a tutto questo c'è il pattern degli override, che è la disciplina di base senza la quale ogni modifica che fai oggi è destinata a sparire al prossimo aggiornamento. Se gestisci un parco di server Linux e vuoi affrontare la migrazione a Debian 13 con un piano testato invece che a reazione, oppure se ti trovi con servizi che non ripartono dopo un upgrade andato storto, contattami per una consulenza diretta: di solito tra la diagnosi e la prima contromisura passano ore, non settimane.