Amutable OS, il Linux a immagini senza shell, SSH e SUID
Il 6 novembre 2026 Lennart Poettering, Michael Vogt e Joaquim Rocha hanno pubblicato sul blog di Amutable la panoramica tecnica di Amutable Foundations, che si compone di due parti: Amutable OS (AOS), un sistema Linux image-based, e Amutable Control Plane (ACP), il sistema che traccia, controlla, aggiorna e verifica una flotta di installazioni AOS. Come spiega la pagina ufficiale di Amutable, AOS parte dai pacchetti delle distribuzioni classiche, inizialmente Fedora, ma li usa per preassemblare immagini disco immutabili in fase di build, invece di installarli sulla macchina finale.
Per chi gestisce server o nodi cloud, ogni sistema combina poche immagini grosse, tipicamente meno di cinque, identiche bit per bit su tutte le macchine. L’accesso, per ora, è solo in anteprima privata su iscrizione.
Cosa cambia: immagini al posto dei pacchetti
Secondo Amutable, nei sistemi a pacchetti la composizione avviene sulla macchina di destinazione, e anche con la stessa selezione di pacchetti l’ordine di installazione, la logica di aggiornamento e le strutture del file system fanno sì che i byte scritti su disco siano sempre diversi. Il fenomeno si chiama drift e rende i sistemi non riproducibili, difficili da confrontare e da testare.
Le immagini di AOS contengono invece tutto il codice e le risorse del sistema operativo. Le installazioni differiscono soltanto per lo stato locale acquisito durante l’esecuzione e restano riproducibili perché il numero di immagini da combinare è ridotto.
Come è fatto AOS: DDI, UKI, sysext e confext
Immagine di sistema, sysext e confext sono realizzati come UAPI.3 DDI: file system EROFS con dati Verity, firma crittografica e tabella delle partizioni GPT come involucro. I confext sono in più cifrati con LUKS. Amutable precisa che l’integrità è imposta non solo al download ma in modo continuo a runtime, e che la protezione copre anche le strutture dei file system. Il kernel viaggia come UKI (UAPI.5), protetto insieme all’initrd da UEFI SecureBoot e da misure e policy TPM.
Componenti voluminosi o specifici, come i driver grafici e per l’AI o gli agenti dei singoli cloud, sono separati in system extension (sysext), sovrapposte a /usr/, così da ridurre ingombro e superficie d’attacco. La scelta è in parte automatica: un database locale chiamato hwdb indica quali immagini aggiuntive installare se viene rilevato certo hardware o se l’ambiente di virtualizzazione segnala determinate identificazioni o funzioni.
La configurazione segue lo stesso schema con le configuration extension (confext), simili ai sysext ma sovrapposte a /etc/. Sono immagini preconfezionate e applicate in modo atomico: la configurazione compare per intero o per niente, ed è quindi anch’essa priva di drift.
Le protezioni attive di default
Amutable elenca le proprietà di sicurezza che l’approccio a immagini consente di imporre:
- nessuna shell UNIX, nessun accesso SSH e nessun interprete (Python, Perl e simili) installati di default, perché sulla maggior parte dei nodi non servono e la loro assenza elimina una classe di attacchi;
- possono essere attivate solo immagini con dati Verity firmati da una chiave presente nel keyring Verity;
- policy W^X: il codice non può risiedere su file system scrivibili, ma solo su sorgenti protette da Verity;
- bit SUID e SGID disabilitati del tutto e nessuna file capability: l’elevazione dei privilegi passa da IPC, con un processo privilegiato che opera per conto di quello meno privilegiato;
- tutte le immagini con codice o configurazione sono misurate tramite funzioni hardware in un log che rende rilevabili le manomissioni, e hanno Verity a livello di blocco e cifratura;
- factory reset integrato, per riportare in uno stato buono un sistema compromesso, mentre il ledger rende visibili molti exploit.
ACP e il ciclo di attestazione
L’ACP comprende l’enrollment dei nodi con fiducia hardware, un ricevitore e validatore di report con relativo ledger, un generatore di confext cifrati per nodo, un servizio di identità con credenziali a breve durata, un repository di immagini basato su TUF, uno scanner CVE che sfrutta gli SBOM verificati e un’interfaccia web. È multi-tenant, con chiavi di firma, storage e ruoli distinti per ciascun tenant.
A intervalli regolari ogni nodo invia un report, generato dallo strumento systemd-report, con lo stato di runtime e delle risorse e le informazioni crittografiche sulla composizione del sistema. Con un TPM il report contiene una quote che indica quali UKI e DDI compongono la macchina; con il Confidential Computing la quote è della CPU e descrive la composizione iniziale; esiste anche una firma puramente software. Le tre tecnologie lavorano in parallelo, per cui una confidential VM con vTPM può firmare il report tre volte, e il verificatore dell’ACP dà peso a quella più forte, mentre l’interfaccia indica quale è stata usata.
L’ACP controlla i report in modo superficiale (firma e chiavi di origine) e in dettaglio (UKI e DDI riconosciuti), li arricchisce con SBOM e informazioni CVE e li scrive in un ledger centrale che descrive la flotta, nella composizione e nello stato di runtime, risorse comprese.
In direzione opposta l’ACP invia confext DDI firmati, protetti da Verity e cifrati con una chiave specifica del nodo. Dove l’hardware lo consente, come con i TPM, sono sigillati alle chiavi hardware con una policy che rispecchia l’ultimo report: il nodo li apre solo se è ancora nello stato riportato, in una forma di attestazione locale. Secondo Amutable ciò riduce la finestra di vulnerabilità e permette ai nodi senza connettività continua di avviarsi comunque.
Report verso l’alto e confext verso il basso formano il Cryptographic Locked Loop (CLL) di Amutable. L’implementazione è opportunistica: funzionano in genere i TPM 2.0 moderni, in chip, firmware o virtualizzati, e sono supportati AMD SEV e Intel TDX; dove manca l’hardware si ripiega sulle firme software.
Gestione remota via Varlink
Report e confext sono asincroni e quindi robusti con connettività scarsa, ma poco adatti a debug e operazioni interattive. Per questi casi un nodo può passare in modalità Varlink remoto, attraverso l’ACP e varlink-http-bridge, con autenticazione mTLS o sshauth; l’ACP, precisa Amutable, è «content blind» e non ha accessi speciali.
In questa modalità il nodo espone via HTTPS l’intera API Varlink di systemd e dei servizi, per esempio io.systemd.Hostname, io.systemd.Unit, io.systemd.JournalAccess, io.systemd.SysUpdate e io.systemd.Manager (ricarica o riavvio). Le API sono autodescritte e per ciascuna interfaccia il nodo serve una descrizione OpenAPI 3.1, da cui generare client tipizzati in Python, Go, TypeScript e altri linguaggi.
Come provarlo
Chi vuole provare AOS e ACP può iscriversi all’anteprima privata di Amutable Foundations. Prezzi, licenza e data di disponibilità generale non sono indicati nella pagina.
