Systemd 260: TPM2, sandboxing e nuove funzionalità in Linux

Guida all'hardware » Guide all'acquisto » Systemd 260: TPM2, sandboxing e nuove funzionalità in Linux

Con l'arrivo di systemd 260, le distribuzioni Linux compiono un altro importante passo verso un ecosistema più moderno e sicuro, orientato agli ambienti cloud, alla virtualizzazione e all'automazione. Questa versione non si limita a perfezionare i dettagli: introduce modifiche significative all'avvio, alla gestione dei servizi, alla rete, all'utilizzo del TPM2 per l'integrità e la crittografia e alle funzionalità di sandboxing a livello di unità.

Al contempo, il progetto sta rafforzando la sua documentazione e il suo approccio alla collaborazione con gli agenti di intelligenza artificiale , chiarendo che systemd è un pilastro fondamentale a cui si connettono sempre più strumenti di sviluppo e osservabilità. Se gestite sistemi Linux su server, nel cloud, su desktop aziendali o in laboratorio, vale la pena dedicare un momento a esaminare tutte queste nuove funzionalità per pianificare aggiornamenti e modifiche alla configurazione.

Un addio definitivo a System V e alla totale dipendenza dalle unità native.

Uno dei cambiamenti più eclatanti in systemd 260 è la completa rimozione del supporto per gli script di System V. Il classico processo di avvio basato su /etc/init.d era stato gradualmente abbandonato da anni, ma ora scompare definitivamente dal codice di systemd.

Ciò significa che i componenti responsabili del collegamento tra gli script SysV e le unità native sono stati rimossi: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator e systemd-sysv-install non esistono più. Di conseguenza, qualsiasi servizio che dipenda ancora da questi meccanismi obsoleti semplicemente non si avvierà sui sistemi che adottano systemd 260.

Durante il processo di pulizia, diverse opzioni di compilazione di Meson sono state contrassegnate come obsolete o rimosse. I flag -Drc-local=, -Dsysvinit-path= e -Dsysvrcnd-path= sono stati relegati negli archivi, mentre altri come -Dintegration-tests= e -Dcryptolib= sono stati rimossi del tutto. Questo invia un messaggio chiaro: ora tutto deve essere gestito da unità native e dalla moderna infrastruttura systemd.

Per molte infrastrutture europee che si affidano ancora a componenti obsoleti, questo cambiamento rende necessaria una revisione dei servizi interni, degli script personalizzati e delle implementazioni legacy. La migrazione a file di unità ben definiti non è più solo consigliata, ma obbligatoria se si desidera continuare a eseguire servizi su distribuzioni che integrano systemd 260.

Requisiti del kernel più elevati e attenzione agli ambienti attuali

La nuova versione alza l'asticella per il kernel: d'ora in poi, la versione minima di Linux supportata è la 5.10 , lasciando indietro rami molto vecchi come la 5.4. Inoltre, il progetto indica che idealmente gli utenti dovrebbero lavorare su un kernel 5.14 o superiore , e raccomanda in particolare la serie 6.6 per sfruttare appieno tutte le funzionalità disponibili.

Questo aumento dei requisiti non rappresenta solitamente un problema nelle distribuzioni moderne, ma può complicare le cose in ambienti molto conservativi o in soluzioni embedded mantenute per molti anni. Prima di aggiornare a systemd 260, è consigliabile verificare quale kernel viene utilizzato, soprattutto nei data center europei con implementazioni a lungo termine o immagini personalizzate.

All'estremo opposto dello spettro, le distribuzioni rolling release come Arch Linux o openSUSE Tumbleweed, molto popolari tra coloro che desiderano le funzionalità più recenti, tendono a integrare rapidamente sia i nuovi kernel che i nuovi rami di systemd. Altre, come Fedora, mantengono un certo grado di stabilità nella versione principale di systemd per tutto il ciclo di vita di ogni release, il che consente un po' più di tempo per pianificare le migrazioni.

Supporto per TPM2, integrità dell'avvio e SRK avanzato

Uno degli ambiti in cui systemd si sta evolvendo maggiormente è l'integrazione con il TPM2 (Trusted Platform Module 2.0) . Questo chip, sempre più diffuso nelle moderne schede madri UEFI e nell'hardware di fascia media e alta, consente di ancorare le informazioni sensibili allo stato del sistema, misurare le fasi di avvio e sbloccare automaticamente i volumi crittografati quando l'ambiente corrisponde alle condizioni previste.

Systemd 260 migliora ulteriormente questa integrazione aggiungendo strumenti e servizi che coprono diverse fasi del processo di avvio. Un componente chiave è systemd-tpm2-setup , responsabile della preparazione dell'infrastruttura attorno alla Storage Root Key (SRK) del TPM . Questa chiave radice funge da base crittografica per proteggere la comunicazione con il chip e per archiviare in modo sicuro altri segreti.

Durante l'avvio, si distinguono due fasi: una molto precoce nell'initrd e un'altra nel sistema root. Nella prima, un servizio chiamato "Early TPM SRK Setup" verifica se il TPM dispone già di una chiave SRK memorizzata e, in caso contrario, la crea e la rende temporaneamente disponibile in /run/systemd/tpm2-srk-public-key.* . Successivamente, una volta montato il filesystem effettivo, il servizio consoliderà la chiave SRK e verificherà che la chiave memorizzata in /var/lib/systemd/tpm2-srk-public-key.pem corrisponda a quella presente nel TPM.

In scenari ben configurati, verranno visualizzate voci di registro come "SRK è già memorizzato nel TPM" e messaggi che indicano che l'impronta SRK corrisponde a quella prevista. Tuttavia, se l'ambiente non è configurato correttamente (ad esempio, in configurazioni che utilizzano Yocto o su schede come Raspberry Pi con TPM basato su SPI e metodi di avvio personalizzati come U-Boot e avvio misurato), potrebbero verificarsi situazioni in cui systemd non riesce a creare questi file in /var/lib/systemd, sollevando dubbi sulla corretta configurazione di SRK.

Quando lo stato del TPM cambia, le partizioni vengono modificate o la sequenza di avvio viene alterata, la policy associata potrebbe non essere più valida. In questi casi, alcuni manutentori consigliano di cancellare lo slot o la policy del TPM e di registrare nuovamente la chiave , seguendo procedure simili a quelle descritte nelle guide alla crittografia del disco con TPM in ambienti come openSUSE, che illustrano in dettaglio come ricreare la policy PCR e ricollegare lo sblocco del volume.

Oltre all'SRK, un altro miglioramento pratico è l'introduzione di un'utilità interna chiamata tpm2_id in udev . Questo strumento integrato si avvia quando il sistema rileva un dispositivo TPM2 ed estrae automaticamente l'identificativo del produttore e del modello . Ciò semplifica l'inventario dell'hardware di sicurezza, il che è molto utile nelle pubbliche amministrazioni, nelle aziende regolamentate o nelle infrastrutture critiche dove è necessario sapere con precisione quali moduli TPM sono installati.

L'integrazione con l'infrastruttura di misurazione dell'avvio è ulteriormente rafforzata da unità specifiche come systemd-pcrextend , che registrano eventi quali "enter-initrd", "leave-initrd", "sysinit" e "ready" in vari PCR (ad esempio, PCR 11). Questa sequenza di estensioni consente al TPM di accumulare una registrazione crittograficamente verificabile del flusso di avvio, che può quindi essere utilizzata per le policy di Trusted Boot o per UKI (Unified Kernel Images) per convalidare lo stato della macchina prima del rilascio delle chiavi.

Misure di sicurezza e sandboxing dei servizi con systemd

Systemd non solo avvia i processi, ma offre anche un set completo di direttive di sandboxing per isolare i servizi e limitare i danni in caso di compromissione. Questo approccio di "difesa a più livelli" si basa su cgroup, namespace, funzionalità del kernel e filtri per le chiamate di sistema (seccomp).

Per valutare la sicurezza di un servizio specifico, systemd include lo strumento di sicurezza systemd-analyze . Eseguendolo, viene generato un report con un punteggio di esposizione su una scala da 0 a 10, dove un punteggio inferiore indica una maggiore sicurezza. Il report specifica quali protezioni sono abilitate o disabilitate (isolamento di rete, accesso al file system, accesso al dispositivo, ecc.), facilitando l'identificazione delle impostazioni mancanti e la verifica dell'effettivo miglioramento del punteggio in seguito alle modifiche apportate.

Invece di modificare l'unità originale, che andrebbe persa nei futuri aggiornamenti del pacchetto, si consiglia di crearne una Override en /etc/systemd/system/mi-servicio.service.d/ con un file, ad esempio, sandbox.confDopo averlo modificato, è sufficiente ricaricare la configurazione con demone systemctl-ricarica e riavviare il servizio affinché le nuove restrizioni abbiano effetto.

A livello di file system, una delle opzioni più importanti è ProtectSystem=Valori come strict, full o true Montano diverse parti dell'albero in modalità di sola lettura. La pratica usuale, quando possibile, è quella di utilizzare ProtectSystem=rigorosoQuesto rende /usr, /boot, /efi e /etc di sola lettura per il servizio. Se un'applicazione deve scrivere in directory specifiche, è consentito farlo utilizzando ReadWritePaths=/path in unità.

Per migliorare ulteriormente la privacy, si consiglia anche di limitare l'accesso alle directory utente utilizzando `ProtectHome=true` , che impedisce al servizio di leggere `/home`, `/root` o `/run/user`. Inoltre, `PrivateTmp=true` crea spazi isolati `/tmp` e `/var/tmp`, impedendo la visibilità incrociata dei file temporanei tra i processi.

Nei dispositivi, `PrivateDevices=true` nasconde l'albero `/dev` effettivo e lo sostituisce con un set minimo di pseudo-dispositivi sicuri (null, zero, casuale, ecc.). Se un'unità necessita di un dispositivo specifico (ad esempio, una porta seriale o un blocco disco), è possibile concederglielo utilizzando `DeviceAllow=/dev/xxx rw` o in modalità di sola lettura.

La rete è anche un vettore chiave. Con Rete privata=vero Viene creato uno spazio dei nomi di rete isolato, lasciando solo il loopback; il servizio non vedrà le interfacce fisiche e non sarà in grado di comunicare con il mondo esterno. In alternativa, è possibile limitare le famiglie di indirizzi che può utilizzare tramite RestrictAddressFamilies=consentendo solo AF_INET e AF_INET6 per IPv4/IPv6, AF_UNIX per socket locali o anche none per giapponesizzare completamente le capacità di rete.

Per quanto riguarda i privilegi, la direttiva `NoNewPrivileges=true` è una delle più potenti: impedisce al processo di acquisire nuovi privilegi tramite binari setuid o modifiche delle capacità. In breve, anche se il servizio esegue codice vulnerabile, non dovrebbe essere in grado di ottenere i privilegi di root tramite i meccanismi tradizionali. In combinazione con `CapabilityBoundingSet=` , che definisce l'elenco preciso delle capacità consentite (ad esempio, solo `CAP_NET_BIND_SERVICE` per l'ascolto su porte basse), la superficie di attacco viene ridotta al minimo.

Per andare ancora oltre, systemd consente di filtrare le chiamate di sistema con FiltroChiamataSistema=Invece di mantenere un elenco manuale di chiamate di sistema, vengono utilizzati gruppi predefiniti, come ad esempio @system-service, @network-io, @basic-io o negare gruppi come ~@privileged. Con systemd-analyze syscall-filter È possibile verificare quali chiamate specifiche appartengono a ciascun gruppo. Ciò consente di costruire un profilo di esecuzione molto limitato, simile a quello offerto da una sandbox dedicata.

Altre impostazioni rilevanti includono `ProtectKernelTunables=true` , che blocca la modifica dei parametri del kernel in `/proc/sys` e `/sys`; `ProtectKernelModules=true` , che impedisce il caricamento o lo scaricamento dei moduli; `ProtectKernelLogs=true` , che impedisce la lettura dei log del kernel; e `ProtectControlGroups=true` , che blocca le scritture nella gerarchia cgroups. Tutto ciò funziona perfettamente con le nuove funzionalità di isolamento degli utenti come ` PrivateUsers=full` , che nella versione 260 è stato aggiornato per mappare l'intera gamma di ID utente, eliminando le precedenti soluzioni alternative necessarie per gli ambienti systemd annidati.

Utenti privati, xaccess e nuovi controlli di accesso ai dispositivi

Il meccanismo PrivateUsers , progettato per consentire ai servizi di essere eseguiti in uno spazio ID utente isolato, è stato consolidato in systemd 260. L' opzione PrivateUsers=full ora mappa l'intera gamma di identificatori, semplificando le cose nei container e sui sistemi con istanze systemd annidate basate su versioni precedenti (anteriori alla 257). Questo miglioramento ha eliminato le soluzioni temporanee utilizzate in precedenza per rilevare queste istanze meno recenti.

Parallelamente, componenti come systemd-logind e systemd-udevd hanno introdotto il concetto di xaccess . Questo meccanismo integra la logica classica di uaccess , che concede l'accesso a determinati dispositivi (ad esempio, audio o video) agli utenti con sessioni grafiche in primo piano sulla macchina locale. Con xaccess, le autorizzazioni possono essere delegate agli utenti remoti con sessioni appositamente contrassegnate , in modo che, ad esempio, un utente connesso tramite desktop remoto possa accedere ai dispositivi di rendering GPU locali senza concedere autorizzazioni generali all'intero sistema.

La configurazione di queste sessioni prevede l'utilizzo di variabili d'ambiente esposte tramite PAM, in particolare PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , che consente di definire quali dispositivi specifici sono inclusi in questa logica. Questo approccio è pienamente conforme ai requisiti normativi e di protezione dei dati dell'Unione Europea, dove sono richiesti granularità e tracciabilità per l'accesso ad hardware sensibile.

mstack, systemd-mstack e nuovi strumenti per i container.

Nell'ambito della containerizzazione, systemd 260 introduce la funzionalità pila e un comando associato, systemd-mstackL'idea alla base di mstack è quella di consentire la definizione di un SovrapposizioneFS basato sulla struttura di una directory speciale chiamata .mstack/, che segue una specifica precisa per l'organizzazione dei suoi livelli.

Il nuovo strumento da riga di comando, systemd-mstack, semplifica l'interazione con questi stack di file system, offrendo maggiore flessibilità nella configurazione di ambienti a livelli per container o servizi altamente isolati. Questa funzionalità è inoltre collegata ai miglioramenti apportati a systemd-importd , che amplia il supporto per il download e la gestione delle immagini OCI , rafforzando così il ruolo di systemd come motore di containerizzazione e sandboxing, una pratica molto diffusa tra i provider di cloud europei e le moderne piattaforme di hosting.

Rete: Integrazione con ModemManager e nuove opzioni per le prestazioni

A livello di rete, systemd-networkd continua ad acquisire importanza. Una delle nuove funzionalità più rilevanti è l' integrazione con ModemManager tramite il protocollo "simple connect" , che consente di gestire modem e connessioni mobili direttamente da networkd senza dover ricorrere a strumenti esterni.

Per agevolare questo flusso, è stata aggiunta una nuova sezione. ai file di configurazione, con parametri quali APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Ciò facilita le implementazioni in aree rurali o ambienti con connettività basata su reti mobili, molto presente in alcuni territori europei dove non sempre sono disponibili fibra ottica o linee telefoniche fisse di qualità.

In termini di prestazioni, i file .link di systemd-networkd includono nuove opzioni specifiche per i dispositivi Ethernet. Tra queste figurano ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList e GenericReceiveOffloadUDPForwarding . Queste opzioni consentono di ottimizzare il trasferimento del lavoro all'hardware e ai driver, aspetto fondamentale nelle reti aziendali, nei data center e presso i fornitori di servizi che necessitano di ridurre al minimo ogni millisecondo di latenza.

Inoltre, le interfacce Varlink e JSON di systemd-networkd ora possono segnalare gli indirizzi IP in un formato leggibile dall'uomo (stringhe) pur mantenendo la rappresentazione come array di interi. Ciò semplifica l'integrazione con dashboard di monitoraggio, script di gestione o strumenti di terze parti che non vogliono avere a che fare con formati numerici poco intuitivi.

Portabilità dei servizi, macchine virtuali effimere e servizi non privilegiati

Il componente systemd-portabled , responsabile della gestione dei servizi "portatili" impacchettati in immagini, acquisisce una funzionalità molto interessante: ora può essere eseguito come servizio a livello utente . Ciò significa che gli utenti non privilegiati, nella loro normale sessione, possono avviare e gestire servizi portatili all'interno del proprio spazio senza dover ricorrere a sudo o privilegi elevati.

Inoltre, a partire da questa versione, portabled è in grado di generare policy e bloccare l'immagine associata a un servizio portatile , impedendone la modifica senza doverla ricollegare. Ciò consente agli utenti di configurare ambienti autonomi con maggiori garanzie di immutabilità, una funzionalità particolarmente interessante per laboratori, ambienti di sviluppo e sandbox di test.

D'altro canto, systemd-vmspawn , lo strumento progettato per avviare macchine virtuali in modo integrato con systemd, estende le sue capacità per registrarsi con systemd-machined all'interno della sessione utente . Introduce inoltre un'opzione `-ephemeral` per creare macchine effimere che vengono distrutte al termine del loro utilizzo. Questa soluzione è ideale per pipeline CI/CD, aule virtuali o piattaforme didattiche europee che richiedono la creazione e la distruzione rapida e controllata di macchine virtuali.

Controllo preciso di CPU, memoria e pianificazione con SCHED_EXT e THP

Systemd 260 approfondisce anche il controllo delle prestazioni con nuove politiche. L'opzione di servizio CPUSchedulingPolicy= ora accetta il valore ext, che attiva lo scheduler SCHED_ESTQuesto pianificatore alternativo apre le porte a esperimenti con diverse politiche di pianificazione agli standard del kernel, un aspetto che potrebbe essere di interesse nei laboratori di ricerca e sviluppo o in implementazioni altamente specializzate.

Nell'area relativa alla memoria, troverete `MemoryTHP=` , che consente di gestire l'utilizzo delle Transparent Huge Pages (THP) per ogni singolo servizio. Invece di un'impostazione globale a livello di sistema, è possibile decidere se una specifica unità debba utilizzare le THP, disabilitarle o adottare modalità intermedie. Per le applicazioni critiche in ambito bancario, assicurativo o governativo, questo controllo granulare può fare una differenza significativa in termini di latenza, consumo di memoria e prestazioni.

Nuovi comandi in systemctl e utilizzo ampliato di Varlink

Il noto comando systemctl si arricchisce di una nuova opzione: enqueue-marked . Questa azione richiama internamente il metodo D-Bus EnqueueMarkedJobs() e consente di lavorare con code di job e servizi pre-contrassegnati. Sebbene possa sembrare un dettaglio di poco conto, per i team operativi che gestiscono grandi server farm, rappresenta un ulteriore strumento per perfezionare i flussi di lavoro di distribuzione e automazione.

Parallelamente, il progetto continua ad espandere l'utilizzo di Varlink come meccanismo di comunicazione tra i componenti. Molte parti di systemd espongono interfacce Varlink stabili, che facilitano l'integrazione con strumenti esterni, dashboard personalizzate o agenti di monitoraggio che richiedono un accesso strutturato alle informazioni di sistema.

Campi di identificazione del sistema ed esperienza utente

Una nuova caratteristica curiosa ma utile per alcune distribuzioni è l'introduzione del campo NOME_FANTASIA= nel file /etc/os-releaseQuesto campo assomiglia a PRETTY_NAME, ma consente Sequenze ANSI e caratteri Unicode più elaboratiGrazie a ciò, distribuzioni ed edizioni specifiche possono essere presentate con nomi più accattivanti o distintivi.

Il valore di FANCY_NAME può essere visualizzato tramite il gestore systemd, utilizzando systemd-hostnamed o interrogando hostnamectl . Sebbene si tratti di una piccola modifica, negli ambienti desktop e nei pannelli di amministrazione grafici può essere utile per identificare rapidamente il sistema gestito, soprattutto quando si gestiscono molte varianti derivate.

Documentazione specifica per agenti di intelligenza artificiale e flusso di lavoro di revisione assistita

Uno degli indizi più interessanti della direzione in cui si sta sviluppando systemd è la comparsa di documentazione specificamente pensata per gli agenti di intelligenza artificiale . Il repository include un file AGENTS.md , progettato per aiutare gli strumenti di analisi del codice e gli assistenti di programmazione, nonché alcune guide tecnologiche , a comprendere meglio l'architettura, lo stile, il flusso di sviluppo e le linee guida per i contributi del progetto.

Questo documento descrive i componenti, i percorsi di compilazione, le modalità di esecuzione dei test e delle integrazioni, nonché le linee guida per la generazione di patch valide. L'obiettivo è fornire agli agenti di intelligenza artificiale che esaminano il codice o apportano modifiche una solida comprensione dell'organizzazione di systemd , riducendo errori e suggerimenti inappropriati.

Accanto al file AGENTS.md si trova un file chiamato CLAUDE.md , che fa esplicito riferimento al primo ed è progettato per guidare lo strumento Claude Code, uno degli assistenti di sviluppo basati sull'intelligenza artificiale più diffusi. In questo modo, il progetto integra esplicitamente l'IA nel suo ciclo di sviluppo.

Inoltre, è incluso un file di configurazione. claude-review.ymldove viene definito come deve essere esaminato il processo di analisi delle richieste di modifica (pull request), con l'aiuto di Claude Code. In questo contesto, i contributi che hanno utilizzato l'IA devono incorporare etichette di divulgazione come Co-developed-by nelle patch, lasciando tracce del fatto che uno strumento automatizzato ha partecipato alla creazione del codice.

Con questa serie completa di modifiche – che include la pulizia del supporto legacy, il perfezionamento del sandboxing, il miglioramento di TPM2 e SRK, l'integrazione di rete avanzata, nuove funzionalità di portabilità e la documentazione pensata per gli agenti intelligenti – systemd 260 rafforza il suo ruolo centrale nel moderno ecosistema Linux. Per gli amministratori e gli sviluppatori in Spagna e in Europa, la sfida immediata consiste nel rivedere i kernel, adattare le configurazioni di avvio e i servizi e sfruttare queste funzionalità per costruire infrastrutture più sicure e automatizzate, in linea con l'attuale utilizzo del sistema.