attestos

Immagine sperimentale di attestazione dell'avvio di Linux e harness di evidenze per testare ciò che un venditore anti-cheat potrebbe verificare invece di affidarsi a una allowlist basata sul nome della distribuzione.

Il meccanismo, il modello di minaccia e la specifica per i venditori vivono in plunder707/attested-gaming. Questo repository è l'immagine che produce le evidenze.

STATO: ANTEPRIMA DEI MECCANISMI DEL SORGENTE. NON INSTALLABILE NÉ AFFIDABILE PER LA PRODUZIONE.

Le esecuzioni di GitHub Actions 31157890393 e 31159951490 hanno compilato un'immagine QCOW2 derivata da Bazzite, l'hanno avviata sotto QEMU/OVMF con swtpm e senza rete guest, hanno creato handle EK/AK persistenti e verificato una quote grezza su SHA-256 delle PCR 7, 11, 12 e 15 dall'interno del guest. La sua ricevuta delimitata ha SHA-256 ad5ef12592cb5f4d1dfa8f0da88148931d48f0e6018924b2de4c766e1523ddaf. Un workflow di verifica separato 31160003873 ha esercitato il commit finale dell'agente b918392 di questo repository contro una TPM software isolata e ha superato l'arruolamento AK, la verifica della quote grezza, il rifiuto del replay, il rifiuto della manomissione della firma e il cablaggio TPM QEMU/OVMF.

Il risultato dell'avvio conferma anche il blocco della policy di Bazzite: nessun file UKI o segnale systemd-stub era presente, gli argomenti di lockdown previsti erano assenti e le PCR 11 e 15 sono rimaste a zero. Anche la PCR 12 era a zero, ma non si tratta di un fallimento indipendente: la riga di comando UKI incorporata appartiene alla PCR 11, mentre la PCR 12 registra gli input esterni della riga di comando e può correttamente rimanere a zero quando non ne vengono forniti. L'arruolamento delle chiavi Secure Boot, la misurazione della riga di comando basata su UKI, la provenienza hardware, il replay del registro eventi, il binding del trasporto e l'ammissione della boot-policy restano irrisolti. Nessuna delle due esecuzioni verdi stabilisce un sistema di attestazione funzionante per la produzione.

Un controllo positivo separato su immagine Fedora sigillata è passato due volte in run 31218059725 e di nuovo sul commit di testa della sorgente integrata in run 31219745053. Dimostra che l'harness può avviare un UKI immutabile firmato a monte, unire il percorso selezionato dal firmware e l'hash del file caricato all'ispezione pre-boot, osservare una PCR 11 non zero e rifiutare una mutazione non firmata di .cmdline. Si tratta solo di un controllo dell'harness: tutti i flag di fiducia del produttore, della policy e della produzione rimangono falsi, e non rende installabile l'anteprima Bazzite.

Il percorso separato dell'add-on di policy PCR 12 firmato è poi passato due volte in run 31234464516. L'UKI a monte e la PCR 11 sono rimasti byte-identici; entrambi gli avvii firmati hanno applicato lockdown=confidentiality module.sig_enforce=1 esattamente una volta e hanno riprodotto la PCR 12 ca62dd5f...a8f5; la manomissione post-firma è stata rifiutata e si è tornati alla baseline con PCR 12 a zero. Questo dimostra un meccanismo delimitato, non una gerarchia di chiavi distribuibile né una policy di fiducia del sistema operativo.

Questo sorgente è disponibile per la revisione e l'emulazione riproducibile. Nessuna immagine GHCR è pubblicata e non è una distribuzione affidabile installabile.

L'esperimento Bazzite completato è specificato in BOOTED_IMAGE_CANARY.md. Le istruzioni di riproduzione e compilazione del sorgente sono in BUILDING.md. Le evidenze di base UKI e i suoi criteri di ammissione indipendenti sono registrati in UKI_BASE_DECISION.md. L'esperimento dell'add-on di policy PCR 12 firmato è specificato separatamente in FEDORA_PCR12_ADDON_CANARY.md. L'ordine delle milestone e le regole di arresto sono tracciati in ROADMAP.md. Il controllo separato dell'harness su UKI caricato è specificato in FEDORA_SEALED_POSITIVE_CONTROL.md.

Cosa questo aggiunge a Bazzite

Non viene rimosso nulla e non viene patchato nulla. Quattro elementi si aggiungono sopra:

1. tpm2-tools e tpm2-tss, di cui l'agente ha bisogno a runtime.
2. Una riga di comando del kernel in /usr/lib/attestos/cmdline che porta lockdown=confidentiality e module.sig_enforce=1.
3. attestos-provision, un'unità one-shot che crea identità RSA EK e AK persistenti e distinte all'interno della TPM e legge il certificato di endorsement dallo storage NV quando esiste.
4. attestos-agent, attivato via socket su loopback, che risponde a una sfida rigorosa attestos.tpm/v1 di identità, attivazione o quote con evidenze TPM grezze. L'agente non restituisce mai un verdetto di fiducia.

Perché la base è Bazzite

Bazzite deriva da Fedora, e la famiglia Fedora è ciò che le whitelist anti-cheat bloccano attualmente. Dimostrare che l'attestazione funziona qui è il caso che vale la pena dimostrare. Costruire su SteamOS non dimostrerebbe nulla, perché SteamOS è già consentito, quindi una demo riuscita lì otterrebbe un accesso che ha già.

Bazzite è inoltre progettata per essere stratificata. È un'immagine OCI, quindi questo repo è un Containerfile e una GitHub Action piuttosto che una distribuzione con mirror e installer alle spalle.

La policy deve essere autenticata e misurata prima del kernel

Questa è la parte che decide se tutto ciò significa qualcosa. lockdown=confidentiality blocca /dev/mem, le kprobe contro un kernel in esecuzione e il caricamento di moduli non firmati. Questa garanzia non vale nulla se la policy vive solo in una configurazione del bootloader che l'utente può modificare. Altrimenti un utente può eliminare gli argomenti, avviare la stessa misurazione del kernel e presentare una quote che non dice nulla sulla policy mancante.

Una Unified Kernel Image lega kernel, initrd e la sua riga di comando incorporata in un unico binario PE firmato misurato nella PCR 11. Un add-on della riga di comando systemd firmato separatamente può estendere ulteriore policy nella PCR 12 lasciando invariato quell'UKI a monte. Entrambe le vie devono essere collegate all'artefatto esatto caricato e riprodotte dal verificatore; la presenza di un file o una PCR non zero non basta.

Bazzite non usa UKI, e ora è confermato piuttosto che sospettato. Il suo Containerfile esclude attivamente i pacchetti kernel UKI:

dnf5 -y config-manager setopt "*fedora*".exclude="mesa-* kernel-core-* \
    kernel-modules-* kernel-uki-virt-* steam"

systemd-ukify non appare da nessuna parte nel repository. Quindi il file cmdline che questa immagine distribuisce è attualmente una dichiarazione di intenti e niente più: senza un UKI non c'è nulla che lo sigilli, un utente può modificarlo nel bootloader e la PCR 11 non misura ciò che il progetto assume che misuri.

Sistemare Bazzite non è una riga in build.sh. Richiede un percorso di misurazione pre-kernel affidabile, sia cambiando il modo in cui l'immagine si avvia, sia adottando una base che si avvia già tramite systemd-stub.

Gli esperimenti restringono le scelte pratiche:

1. Fare comunque il lavoro UKI su Bazzite e accettare la divergenza dalla base.
2. Usare un UKI Fedora sigillato a monte e aggiungere la policy attestos tramite un add-on systemd firmato separatamente e misurato nella PCR 12.
3. Trovare un altro percorso di misurazione pre-kernel autenticato. Una misurazione effettuata solo dopo l'avvio del kernel è una classe di evidenze più debole e non deve essere presentata come equivalente.

Il problema dell'ammissione delle chiavi, irrisolto

Un UKI Fedora a monte può mantenere la sua firma di distribuzione, ma un add-on di policy attestos separato ha comunque bisogno di una chiave di firma ammessa da firmware, Shim o MOK. Un kernel di terze parti ha la versione più grande dello stesso problema. Le opzioni di distribuzione sono:

• Arruolamento MOK, in cui l'utente arruola una Machine Owner Key tramite una schermata blu del firmware al primo avvio. Universal Blue fa già questo per i moduli kernel fuori albero, quindi il meccanismo esiste, ma cambia l'affermazione da "Microsoft garantisce per questo kernel" a "l'utente si fida esplicitamente di questa chiave", e un venditore deve decidere se questo è accettabile.
• Uno shim firmato Microsoft, che è il percorso che una vera distribuzione segue ed è un processo di revisione piuttosto che un modulo.
• PK e KEK di proprietà dell'utente, che danno pieno controllo e quasi nessuna adozione.

L'harness Fedora usa e getta arruola un certificato locale all'esecuzione in un DB UEFI copiato e dimostra il meccanismo senza rivendicare un modello di distribuzione. Non esiste ancora un contratto accettato di arruolamento, revoca o recupero delle chiavi per l'utente finale. È una questione da relying party tanto quanto ingegneristica.

Installazione

Non esiste ancora un comando di installazione supportato. In particolare, ghcr.io/plunder707/attestos:latest non è pubblicato. L'anteprima attuale serve solo per la revisione del sorgente e la riproduzione isolata con QEMU/swtpm. Vedi BUILDING.md.

Struttura

Containerfile            base image and the single RUN that calls build.sh
build_files/build.sh     the attestation layer
system_files/            agent, provisioning script, systemd units
image-template.env       image name and registry organisation
.github/workflows/       build-only and isolated evidence canaries
Justfile                 local build and test targets

Tutto ciò che sta fuori da build_files/ e system_files/ proviene da ublue-os/image-template ed è opera loro.

Domande ancora aperte

• Se l'immagine si compila. Confermato per il commit 14e3a21 dall'esecuzione GitHub Actions 31143048491; la compilazione ha emesso due avvisi lint non fatali sullo stato DNF.
• Come un verificatore trasforma l'affermazione di deployment bootc status dell'agente a runtime in un'identità dell'immagine verificata. L'affermazione è metadati, non autorità firmata; sui sistemi senza bootc è esplicitamente unavailable.
• Il QCOW2 derivato da Bazzite supera il canary isolato dei meccanismi, ma le sue osservazioni negative su UKI e lockdown lo trattengono dall'ammissione alla policy.
• Se l'add-on di policy PCR 12 firmato separatamente rimane riproducibile sotto aggiornamenti, rollback, ordinamenti alternativi e un ciclo di vita delle chiavi di produzione. L'harness congelato a policy singola ora passa; questi casi di ciclo di vita no.
• Come compilare agente e policy in un candidato sigillato, verificare una quote firmata fuori dal guest e riprodurre i registri eventi pertinenti.
• Se la PCR 15 è popolata nel modo che il progetto assume su una root bootc.
• Se l'arruolamento MOK produce un valore PCR 7 abbastanza stabile su cui scrivere una policy.
• Se un venditore accetterebbe mai una gerarchia di chiavi arruolata via MOK.

Le domande sulla misurazione a runtime richiedono QEMU con OVMF e swtpm, che non necessita di hardware aggiuntivo. Il cablaggio e i meccanismi del protocollo TPM grezzo hanno ora superato la prova lì, ma avviare l'immagine compilata e validare il suo registro eventi e la sua policy restano esperimenti separati. L'accettazione da parte del venditore richiede una conversazione con il venditore.

Licenza

Apache-2.0, coerente con il template da cui è costruito.