Il futuro trusted di systemd/Linux

Nella keynote del Linux App Summit 2026, Lennart Poettering ha parlato di un tema tanto tecnico quanto concreto: come rendere il desktop Linux resistente a manipolazioni fisiche e logiche. Poettering è lo sviluppatore storico di systemd, un tempo contributore GNOME, oggi chief engineer della startup Mutable. Il punto di partenza della sua riflessione non è una teoria astratta: racconta di laptop lasciati in hotel durante viaggi in Cina e Ucraina che al rientro avevano tutte le viti cadute allo stesso tempo. Un segnale che, a suo dire, suggerisce con ogni probabilità un tampering non rilevabile.

Da lì la domanda che attraversa tutta la talk: nel 2026 possiamo ancora accettare sistemi operativi che si limitano a criptare i dati senza autenticare il sistema che li decifra?

Lo scenario d'attacco: la "evil maid"

L'attacco di riferimento è la cosiddetta evil maid attack. Lasci il laptop in camera d'albergo e nel frattempo l'attaccante può:

1. Copiare il disco
2. Modificare il disco
3. Re-flashare la firmware
4. Installare un keylogger

Il quarto è il più insidioso, perché un keylogger può essere nascosto sulla scheda madre e non è rilevabile senza competenze hardware. Gli altri tre, secondo Poettering, possono essere resi rilevabili e prevenibili con le tecnologie giuste.

Due concetti chiave: offline security e state space

Per inquadrare la proposta, Poettering introduce due definizioni:

• Offline security: i dati a riposo devono restare confidenziali e non modificabili; il sistema operativo stesso non deve poter essere manomesso; e deve sempre esistere un modo per tornare a uno stato definito, il factory reset.
• State space (spazio degli stati): l'insieme degli stati in cui un sistema può troversi. L'obiettivo di sicurezza e robustezza è ridurlo drasticamente, eliminando a priori gli stati "cattivi".

Le distribuzioni attuali, osserva, non funzionano così.

Modello 1: le distro classiche a pacchetti

Le distro basate su RPM e pacchetti Debian sono finemente granulari: ognuno combina localmente decine di migliaia di pacchetti, e quella combinazione è unica. Di conseguenza:

• timestamp, ordine di installazione e scriptlet rendono ogni installazione diversa;
• le aggiornamenti interrotti, come una batteria scarica a metà update, sono altamente problematici, perché l'installazione non è atomica;
• l'autenticazione avviene solo al download: verificato il pacchetto, si installa e da quel momento si fida per sempre, in contrasto diretto con il modello di offline security;
• la separazione tra dati locali (/var, /home) e OS (/usr) è vaga e sullo stesso filesystem;
• nessun factory reset possibile, robustezza pessima, spazio degli stati enormemente grande.

Sul caso specifico dell'initrd, un membro del pubblico ha chiesto se cifrare il disco non risolvesse tutto. "No", ha risposto Poettering, "la crittografia è confidenzialità, non autenticità". Un attaccante con accesso fisico può comunque modificare la partizione di boot, inserire un initrd malevolo e rubare le password. Quanto agli IDS, gli intrusion detection system: non funzionano se girano dentro il sistema che dovrebbero proteggere, perché la prima cosa che fa un attaccante è disattivarli. La protezione deve venire da un livello superiore all'OS.

Modello 2: le distro immutable basate su OSTree

I sistemi immutabili alla Fedora Silverblue/OSTree sono un passo avanti: alberi di file generati in build time, contenuto uniforme, timestamp azzerati, aggiornamenti essenzialmente atomici (scarica, prepara, commuta). Ma Poettering ne sottolinea i limiti:

• la grandezza dell'immagine binaria del filesystem varia comunque a seconda degli update saltati;
• l'autenticazione resta al download;
• la separazione dati/OS è superficiale, perché sono comunque sullo stesso filesystem e a livello di blocchi tutto varia;
• il factory reset è debole.

Nemmeno Composable OS con la sua integrazione fs-verity lo convince del tutto: riduce lo spazio degli stati della vista del filesystem, non del filesystem stesso.

Modello 3: la proposta, immagini disco con dm-verity

Qui arriva la tesi centrale della talk. Il modello che Poettering propone è basato su immagini disco (EROFS o SquashFS) generate in build time:

• uniformità bit a bit: tutti gli utenti hanno la stessa copia esatta, strutture del filesystem comprese;
• aggiornamenti sicuri: o hai l'immagine o non l'hai, non esistono stati intermedi corrotti;
• autenticazione ad ogni accesso tramite dm-verity: un Merkle tree, come in Git, la cui root hash, firmata, fissa l'intero contenuto del disco. Ogni settore viene verificato prima di raggiungere il filesystem;
• severa separazione tra OS e dati locali: il filesystem dell'OS è intrinsecamente non scrivibile, i dati vivono su una partizione separata, factory reset vero.

Su questo si basa il concetto di DDI, Discoverable Disk Image: un'immagine disco formata da tre partizioni, filesystem (EROFS/SquashFS), database verity e un frammento JSON con le firme, incollate da un header GPT. L'intero OS, dalle immagini base alle app, verrebbe composto da DDI.

Il costo in prestazioni? Circa il 10%. È piccolo oggi perché le CPU sono brave a fare hash, anche se su sistemi molto deboli come una Raspberry Pi l'impatto si sente.

W^X esteso ai filesystem

Dai DDI discende un principio famoso ai gestori di memoria, W^X (writable o eseguibile, mai entrambi), esteso all'intero filesystem: ogni file è o eseguibile e proveniente da un DDI firmato, o scrivibile in locale, mai entrambi. Impossibile iniettare ed eseguire codice a piacere. La politica sarebbe imposta a livello esterno da un modulo di sicurezza (BPF LSM), con regime più rilassato dentro container e namespace, dove il mondo container mescola tutto. Per gli interpreti, Python e compagni, serve un supporto dedicato: l'interprete chiede al kernel se può eseguire lo script. Una hack necessaria, ammette Poettering.

TPM, attestation e il ruolo della crittografia

Il TPM mantiene un log di hash anti-tampering, l'event log, di ogni immagine attivata: OS, app, firmware. Da lì:

• Local attestation: la chiave di decrittazione del disco viene generata dal TPM e rilasciata solo se l'event log è nello stato previsto. Solo un sistema bootato pulito può accedere ai dati. Copiare il disco su un'altra macchina non serve a nulla, perché la chiave non esiste altrove. Windows lo fa da anni, con una recente enorme falla dovuta a un'implementazione errata.
• Remote attestation: un secondo dispositivo di cui ci fidiamo, ad esempio il nostro telefono, verifica lo stato del laptop. L'idea: sono molto più tranquillo a lasciare il laptop in hotel se col telefono posso controllare che sia ancora nello stato corretto. Il FSF la critica come DRM, ma secondo Poettering è una visione ristretta: se l'altro sistema è qualcuno che non ti fidi, è un problema; se è tu, è un valore. È un prototipo, non è ancora realtà.
• Aggiornamenti: lo spazio degli stati validi non è un singolo valore ma non esplode. Una decina di stati, forse sotto le 50 combinazioni, contando versione corrente e successiva dell'OS e stati della firmware. Gli hash dell'OS e del bootloader si possono pre-calcolare; quelli della firmware no, perché i vendor, tranne case come Nova, non li pubblicano. Lo scorciatoia: per un aggiornamento firmware si abbassa temporaneamente la policy TPM, sperando che nessuno lo estragga nel frattempo. "Succhia, ma è così".

Secure Boot vs Verified Boot

Distinzione netta:

• Verified Boot: la catena firmware → bootloader → OS misura ogni componente nell'event log. Politiche locali, nessuno deve chiedere il permesso a nessuno. Poettering è un grande fan: è democratico.
• Secure Boot: ogni fase verifica le firme contro una lista di chiavi derivata da Microsoft. Succhia, perché i requisiti per farsi firmare sono minimi, quindi il valore di sicurezza è basso e si crea solo burocrazia. E, dice Poettering, è molto anti-democratico: devi chiedere a Microsoft.

Cosa significa per il desktop

Nella parte finale, alcune applicazioni concrete:

• Flatpak dovrebbe usare i DDI al posto dello stile OSTree; systemd-mount DDI fa già tutta l'autenticazione in modo unprivileged, ideale per i desktop. C'è anche systemd-portabled, a metà tra container e app.
• Il problema della condivisione: filesystem separati significano meno sharing di memoria e disco, perché tutti replicano la stessa glibc. La soluzione è EROFS con page cache sharing: due file con lo stesso hash in immagini diverse vengono magicamente mappati insieme, senza sforzo da parte di chi costruisce le immagini.
• Snap: usa SquashFS/EROFS e potrebbe beneficiare del page sharing, ma Canonical ha avuto tutte le building block giuste senza fare l'ultimo miglio per estrarne il beneficio di sicurezza. Niente verity.
• La shell: oggi non è un'app e può essere influenzata da dati locali come .bashrc. Sarebbe possibile una base image senza shell, con la shell installata come prima app o estensione. Poettering spera che gli sviluppatori di GNOME Shell e KDE Plasma capiscano che c'è un confine di sicurezza tra shell e app, cosa che Wayland, scritta tenendo a mente quel confine, già presuppone.

Conclusione

La keynote di Poettering è una tesi architetturale: la sicurezza di un sistema Linux si ottiene comprimendo lo spazio degli stati, autenticando ogni accesso a livello di blocco e separando in modo netto ciò che è del vendor da ciò che è dell'utente. Le distro a pacchetti perdono su tutti e tre i fronti, gli immutabili a OSTree migliorano ma restano un compromesso, il modello a immagini disco con dm-verity, DDI, TPM e W^X esteso ai filesystem è la direzione che, secondo l'autore di systemd, dovrebbe diventare lo standard per il desktop Linux.

Il miglior riassunto della sua filosofia arriva forse dalla risposta sulla differenza tra crittografia e autenticità: "Il crittografo ti direbbe che non capisci la crittografia". Nel 2026, con laptop che tornano dai viaggi con le viti cadute, è una distinzione che non possiamo più permetterci di ignorare.