it-swarm.com.de

Wie funktioniert Secure Boot eigentlich?

Ich spiele mit GRUB2, SecureBoot und Kernel Signing und ich denke, ich habe einen möglichen Fehler in meinem Secure Boot gefunden, aber ich möchte zuerst mein Verständnis dieser Prozesse überprüfen.

Ich weiß, dass bei aktiviertem Secure Boot nur Binärdateien gestartet werden können, die mit einem in der Firmware geladenen Schlüssel signiert sind, sodass alle Bootloader signiert sein müssen. In einem typischen Fall sind Shim und GRUB.

Shim sollte den MoakManager zu Mittag essen, wenn der Start fehlschlägt oder Sie einige Schlüssel importieren oder löschen müssen. Wenn alles in Ordnung ist, sollte GRUB gestartet werden, das der eigentliche Bootloader ist.

Das Problem ist, dass ich gerade eine benutzerdefinierte Version von GRUB mit grub-mkstandalone generiert habe, die ich mit einem neuen mit OpenSSl erstellten Schlüssel signiert habe. Ein Schlüssel, den ich noch nicht in die Firmware importiert habe, und Shim konnte ihn ohne Berichte von Secure Boot starten.

Ich habe die Schlüssel mit mokutil --list-enrolled überprüft und es wurde nur das kanonische Zertifikat gemeldet.


Um es noch einmal zusammenzufassen:

In meiner EFI-Partition habe ich:

  • shimx64.efi signiert von Canonical, generiert mit grub-install
  • meine benutzerdefinierte GRUB, generiert mit grub-mkstandalone, signiert mit meinem eigenen Schlüssel, den ich noch nicht importiert habe, mit dem Namen grubx64.efi.

Beim Booten konnte SHIM GRUB und GRUB erfolgreich Ubuntu booten.

Wenn einige Secure Boot-Programme nur das Vorzeichen des ersten Bootloaders überprüfen und die anderen Loader dafür verantwortlich sind, sich selbst und die Module, die sie vorab laden und die Benutzer letztendlich laden, zu überprüfen, sind die Sicherheitsbedenken hier sehr hoch.

Ich werde noch ein paar Tests machen, aber vielleicht sollte ich ein Fehlerticket öffnen.


Irgendwelche Ideen?

6
JumpAlways

Ich glaube, Ihr Verständnis ist richtig , außer , dass shimx64.efi in binärer Form über ein Paket geliefert wird . nicht lokal über grub-install generiert. (grub-install wird wahrscheinlich shimx64.efi auf dem ESP installieren.) Oh, und es ist MokManager, nicht MoakManager.

Bevor Sie einen Fehlerbericht einreichen, sollten Sie Ihre Schritte nachvollziehen und 100% sicher sein, dass Sie über Ihren lokal kompilierten GRUB booten. Es ist leicht, versehentlich eine Binärdatei an die falsche Stelle zu setzen oder es zu versäumen, efibootmgr auszuführen, um beispielsweise die Startreihenfolge anzupassen. (Sie haben nicht beschrieben, wie Sie Ihren benutzerdefinierten grubx64.efi installieren - überschreiben Sie die Ubuntu-Standardbinärdatei oder platzieren Sie Ihre neue an einer anderen Stelle und registrieren Sie sie [und eine Kopie von Shim] über efibootmgr? ) Möglicherweise möchten Sie Sudo efibootmgr -v ausführen, um die Startdetails anzuzeigen. Achten Sie auf die Zeilen BootOrder und BootCurrent. In der ersten Zeile wird die Reihenfolge angegeben, in der die Startoptionen ausgeführt werden. In der zweiten Zeile wird die Option angezeigt, die zum Starten des Computers verwendet wurde. Sie müssen die Nummern mit den verschiedenen Boot#### -Zeilen verweisen, die die einzelnen Startoptionen beschreiben. Wenn Sie Ihr eigenes GRUB getrennt von Ubuntus GRUB installiert haben, ist es denkbar, dass die Firmware es aufgrund eines Secure Boot-Fehlers unbemerkt umgangen hat und dann auf Ubuntu Shim/GRUB zurückgegriffen hat Sehen.

Eine andere Möglichkeit ist, dass Secure Boot auf Ihrem Computer nicht aktiviert ist. Sie können diese Möglichkeit wie folgt überprüfen:

$ hexdump /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c 
0000000 0016 0000 0001              
0000005

In diesem Beispiel endet die erste Ausgabezeile (0000000 0016 0000 0001) mit einem 1. Dies zeigt an, dass Secure Boot aktiv ist. Wenn es mit einem 0 endet, ist Secure Boot auf Ihrem Computer deaktiviert.

Eine andere Möglichkeit ist, dass Sie Ihren lokalen Schlüssel in der eigenen Datenbankliste der Firmware installiert haben. Dies ist jedoch eine schwierige Aufgabe, daher ist es unwahrscheinlich, dass Sie sie versehentlich und ohne es zu merken ausgeführt haben. (Siehe meine Seite zum Thema für Einzelheiten zur Einrichtung.) Ich erwähne diese Möglichkeit hauptsächlich der Vollständigkeit halber; Es scheint mir überhaupt nicht sehr wahrscheinlich zu sein, es sei denn, Sie erwähnen nicht einen früheren Versuch, Secure Boot auf diese Weise zu meistern.

Wenn Sie einen Fehler sehen, kann dies entweder an Shim oder an Ihrer Firmware liegen.

Eine weitere Einschränkung ist, dass ich mit GRUB-spezifischen Tools wie grub-mkstandalone nur vorübergehend vertraut bin. Da ich rEFInd verwende, bevorzuge ich die Verwendung, sodass mein Wissen über GRUB Tools nicht so tief greifend ist, wie es sein könnte. Daher fehlen mir möglicherweise wichtige Details, da sie GRUB-spezifisch sind.

3
Rod Smith