attestos

Experimentelles Linux-Boot-Attestierungs-Image und Beweis-Harness zum Testen, was ein Anti-Cheat-Anbieter verifizieren könnte, anstatt sich auf eine Zulassungsliste von Distributionsnamen zu verlassen.

Der Mechanismus, das Bedrohungsmodell und die Herstellerspezifikation befinden sich in plunder707/attested-gaming. Dieses Repository ist das Image, das die Beweise erzeugt.

STATUS: VORSCHAU DER QUELLMECHANIK. NICHT INSTALLIERBAR ODER PRODUKTIONSVERTRAUENSWÜRDIG.

Die GitHub-Actions-Läufe 31157890393 und 31159951490 erstellten ein von Bazzite abgeleitetes QCOW2, booteten es unter QEMU/OVMF mit swtpm und ohne Gastnetzwerk, richteten persistente EK/AK-Handles ein und verifizierten einen rohen Quote über SHA-256-PCRs 7, 11, 12 und 15 von innerhalb des Gasts. Die begrenzte Quittung hat SHA-256 ad5ef12592cb5f4d1dfa8f0da88148931d48f0e6018924b2de4c766e1523ddaf. Ein separater Verifizierer-Workflow 31160003873 übte den finalen Agent-Commit b918392 dieses Repositorys gegen einen isolierten Software-TPM aus und bestand AK-Enrollment, Rohattest-Verifizierung, Replay- Ablehnung, Signaturmanipulations-Ablehnung und QEMU/OVMF-TPM-Verdrahtung.

Das gebootete Ergebnis bestätigt auch den Bazzite-Policy-Blocker: Es war keine UKI-Datei oder kein systemd-stub-Signal vorhanden, die beabsichtigten Lockdown-Argumente fehlten, und die PCRs 11 und 15 blieben null. PCR 12 war ebenfalls null, aber das ist kein unabhängiger Fehler: Die eingebettete UKI-Befehlszeile gehört zu PCR 11, während PCR 12 externe Befehlszeileneingaben aufzeichnet und korrekt null bleiben kann, wenn keine geliefert werden. Secure-Boot-Schlüssel-Enrollment, UKI-gestützte Befehlszeilenmessung, Hardware-Provenienz, Event-Log-Replay, Transportbindung und Boot-Policy-Zulassung bleiben ungelöst. Keiner der grünen Läufe etabliert ein funktionierendes Produktionsattestierungssystem.

Eine separate positive Kontrolle mit versiegeltem Fedora-Image bestand zweimal in run 31218059725 und erneut auf dem Head des zusammengeführten Quellcodes in run 31219745053. Sie beweist, dass das Harness ein unveränderliches, upstream-signiertes UKI booten, den von der Firmware ausgewählten Pfad und den Hash der geladenen Datei in die Pre-Boot-Inspektion einbeziehen, einen von null verschiedenen PCR 11 beobachten und eine unsignierte .cmdline-Mutation ablehnen kann. Dies ist nur eine Harness-Kontrolle: Alle Hersteller-, Policy- und Produktionsvertrauensflags bleiben falsch, und es macht die Bazzite-Vorschau nicht installierbar.

Der separate signierte PCR-12-Policy-Addon-Testlauf bestand dann zweimal in run 31234464516. Das Upstream-UKI und PCR 11 blieben byte-identisch; beide signierten Boots wandten lockdown=confidentiality module.sig_enforce=1 genau einmal an und reproduzierten PCR 12 ca62dd5f...a8f5; die Manipulation nach der Signatur wurde abgelehnt und kehrte zur Null-PCR-12-Basislinie zurück. Dies beweist einen begrenzten Mechanismus, keine einsetzbare Schlüsselhierarchie oder Betriebssystem-Vertrauensrichtlinie.

Dieser Quellcode ist zur Überprüfung und reproduzierbaren Emulation verfügbar. Es ist kein GHCR-Image veröffentlicht und es ist keine installierbare vertrauenswürdige Distribution.

Das abgeschlossene Bazzite-Experiment wird in BOOTED_IMAGE_CANARY.md beschrieben. Reproduktions- und Quellbuild-Anweisungen befinden sich in BUILDING.md. UKI-Basisbeweise und ihre unabhängigen Zulassungskriterien sind in UKI_BASE_DECISION.md festgehalten. Das signierte PCR-12-Policy-Addon- Experiment wird separat in FEDORA_PCR12_ADDON_CANARY.md beschrieben. Die Meilensteinreihenfolge und Stoppregeln werden in ROADMAP.md verfolgt. Die separate Harness-Kontrolle für geladene UKIs wird in FEDORA_SEALED_POSITIVE_CONTROL.md beschrieben.

Was dies zu Bazzite hinzufügt

Es wird nichts entfernt und nichts gepatcht. Vier Dinge kommen obendrauf:

1. tpm2-tools und tpm2-tss, die der Agent zur Laufzeit benötigt.
2. Eine Kernel-Befehlszeile unter /usr/lib/attestos/cmdline mit lockdown=confidentiality und module.sig_enforce=1.
3. attestos-provision, eine One-Shot-Unit, die im TPM eindeutige persistente RSA-EK- und AK-Identitäten erstellt und das Endorsement-Zertifikat aus dem NV-Speicher liest, wenn eines vorhanden ist.
4. attestos-agent, socket-aktiviert auf Loopback, der eine strenge attestos.tpm/v1-Identitäts-, Aktivierungs- oder Quote-Herausforderung mit rohen TPM-Beweisen beantwortet. Der Agent gibt nie ein Vertrauensurteil zurück.

Warum die Basis Bazzite ist

Bazzite ist von Fedora abgeleitet, und die Fedora-Familie ist das, was Anti-Cheat- Zulassungslisten derzeit blockieren. Zu beweisen, dass Attestierung hier funktioniert, ist der Fall, der sich zu beweisen lohnt. Die Entwicklung auf SteamOS würde nichts demonstrieren, weil SteamOS bereits durchgelassen wird; ein erfolgreicher Demo dort würde sich also Zugang verschaffen, den es bereits hat.

Bazzite ist außerdem dafür ausgelegt, geschichtet zu werden. Es ist ein OCI-Image, daher ist dieses Repository ein Containerfile und eine GitHub Action und keine Distribution mit Spiegeln und Installationsprogrammen dahinter.

Die Policy muss vor dem Kernel authentifiziert und gemessen werden

Dies ist der Teil, der entscheidet, ob das Ganze eine Bedeutung hat. lockdown=confidentiality blockiert /dev/mem, Kprobes gegen ein laufendes Kernel und das Laden unsignierter Module. Diese Garantie ist nichts wert, wenn die Policy nur in einer Bootloader-Konfiguration lebt, die der Benutzer bearbeiten kann. Andernfalls kann ein Benutzer die Argumente löschen, dieselbe Kernel-Messung booten und einen Quote vorlegen, der nichts über die fehlende Policy aussagt.

Ein Unified Kernel Image bindet Kernel, Initrd und seine eingebettete Befehlszeile in eine einzige signierte PE-Binärdatei, die in PCR 11 gemessen wird. Ein separat signiertes systemd-Befehlszeilen-Add-on kann zusätzliche Policy in PCR 12 erweitern, während das Upstream-UKI unverändert bleibt. Beide Wege müssen mit dem exakt geladenen Artefakt verbunden und vom Verifizierer wiedergegeben werden; das Vorhandensein einer Datei oder ein von null verschiedener PCR reicht nicht aus.

Bazzite unterstützt kein UKI, und das ist nun bestätigt und nicht nur vermutet. Sein Containerfile schließt die UKI-Kernel-Pakete aktiv aus:

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

systemd-ukify taucht nirgendwo im Repository auf. Die cmdline-Datei, die dieses Image mitliefert, ist derzeit also nur eine Absichtserklärung und nichts weiter: Ohne ein UKI gibt es nichts, das sie versiegelt, ein Benutzer kann sie im Bootloader bearbeiten, und PCR 11 misst nicht das, was das Design voraussetzt.

Bazzite zu reparieren ist keine Zeile in build.sh. Es erfordert einen vertrauenswürdigen Messpfad vor dem Kernel, sei es durch Änderung der Bootweise des Images oder durch Übernahme einer Basis, die bereits über systemd-stub bootet.

Die Experimente grenzen die praktischen Möglichkeiten ein:

1. Die UKI-Arbeit trotzdem auf Bazzite durchführen und die Abweichung von der Basis akzeptieren.
2. Ein upstream versiegeltes Fedora-UKI verwenden und attestos-Policy über ein separat signiertes systemd-Add-on hinzufügen, das in PCR 12 gemessen wird.
3. Einen anderen authentifizierten Messpfad vor dem Kernel finden. Eine Messung, die erst nach dem Kernelstart erfolgt, ist eine schwächere Beweisklasse und darf nicht als gleichwertig dargestellt werden.

Das Problem der Schlüsselzulassung, ungelöst

Ein Upstream-Fedora-UKI kann seine Distributionssignatur behalten, aber ein separates attestos-Policy-Add-on benötigt weiterhin einen Signaturschlüssel, der von Firmware, Shim oder MOK zugelassen wird. Ein Drittanbieter-Kernel hat die größere Version desselben Problems. Die Bereitstellungsoptionen sind:

• MOK-Enrollment, bei dem der Benutzer beim ersten Booten über einen blauen Firmware-Bildschirm einen Machine-Owner-Key einschreibt. Universal Blue macht das bereits für Out-of-Tree-Kernelmodule, die Mechanik existiert also, aber es ändert die Aussage von „Microsoft bürgt für diesen Kernel“ zu „Der Benutzer vertraut diesem Schlüssel ausdrücklich“, und ein Anbieter muss entscheiden, ob das akzeptabel ist.
• Ein Microsoft-signierter Shim, was der Weg ist, den eine echte Distribution geht, und eher ein Überprüfungsprozess als ein Formular ist.
• Benutzereigene PK und KEK, was volle Kontrolle und fast keine Verbreitung bietet.

Das Wegwerf-Fedora-Harness schreibt ein für den Lauf lokales Zertifikat in eine kopierte UEFI-DB und beweist den Mechanismus, ohne ein Bereitstellungsmodell zu beanspruchen. Es gibt immer noch keinen akzeptierten Vertrag für Endbenutzer-Schlüsseleinschreibung, Widerruf oder Wiederherstellung. Das ist ebenso eine Frage der vertrauenden Partei wie eine technische.

Installation

Es gibt noch keinen unterstützten Installationsbefehl. Insbesondere ist ghcr.io/plunder707/attestos:latest nicht veröffentlicht. Die aktuelle Vorschau dient nur der Quellcode-Überprüfung und der isolierten QEMU/swtpm-Reproduktion. Siehe BUILDING.md.

Aufbau

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

Alles außerhalb von build_files/ und system_files/ stammt von ublue-os/image-template und ist deren Arbeit.

Was noch beantwortet werden muss

• Ob das Image überhaupt baut. Bestätigt für Commit 14e3a21 durch GitHub-Actions-Lauf 31143048491; der Build erzeugte zwei nicht fatale DNF-State-Lint-Warnungen.
• Wie ein Verifizierer den Laufzeit-Bereitstellungsanspruch des Agents aus bootc status in eine verifizierte Image-Identität überführt. Der Anspruch ist Metadaten, keine signierte Autorität; auf Systemen ohne bootc ist er ausdrücklich unavailable.
• Das von Bazzite abgeleitete QCOW2 besteht den isolierten Mechanik-Canary, aber seine negativen UKI- und Lockdown-Beobachtungen halten es von der Policy-Zulassung ab.
• Ob das separat signierte PCR-12-Policy-Add-on unter Updates, Rollback, alternativer Reihenfolge und einem Produktionsschlüssellebenszyklus reproduzierbar bleibt. Das eingefrorene Single-Policy-Harness besteht aktuell; diese Lebenszyklusfälle nicht.
• Wie Agent und Policy zu einem versiegelten Kandidaten gebaut werden, ein signierter Quote außerhalb des Gasts verifiziert und die relevanten Ereignisprotokolle wiedergegeben werden.
• Wird PCR 15 so befüllt, wie das Design es auf einer bootc-Root annimmt.
• Erzeugt MOK-Enrollment einen PCR-7-Wert, der stabil genug ist, um eine Policy darauf zu schreiben.
• Würde ein Anbieter eine MOK-eingeschriebene Schlüsselhierarchie überhaupt akzeptieren.

Die Laufzeitmessungsfragen erfordern QEMU mit OVMF und swtpm, was keine zusätzliche Hardware benötigt. Die Verdrahtung und die Roh-TPM-Protokollmechanik haben dort nun bestanden, aber das Booten des gebauten Images und die Validierung seines Ereignisprotokolls und seiner Policy bleiben separate Experimente. Die Akzeptanz des Anbieters erfordert ein Gespräch mit dem Anbieter.

Lizenz

Apache-2.0, entsprechend der Vorlage, aus der dies erstellt wurde.