ubuntuusers.de

Ich probiere zur Zeit mit verschiedenen Mini PC rund und alle verhalten sich ein wenig anders. Interessant ist, dass "Secure Boot" im UEFI aktiviert ist, dmesg dann aber meint, dass es nicht ist. Win 11 ließ sich auch problemlos installieren. AFAIK verlangt Win 11 Secure Boot aktiviert.

Bis ich überlegt habe was der Unterschied zwischen "key" und "hash" ist, war die Eingabemöglichkeit weg:

Continue boot

Enroll MOK

Enroll key from disk 
Enroll hash from disk

Nach meinen Recherchen war ich noch immer nicht schlauer.

Dann kam folgendes beim nächsten Start:

Select Key

The selected key will be enrolled into the MOK database This means any binaries signed with it will be run without prompting Remember to make sure it is a genuine key before Enrolling it

ESP

PciRDot (0) /Pci(Ox2,0x1) /Pci(Ox0, Ox0)/Path(131,23,0x010000006....

WIN11

PciROOt (0) /Pci(0x2,0x1) /Pci(0xO, Ox0) /Path(131,23,0x010000O06....

PciRO0t (0) /PCi(0x2,0x1) /Pci(0x0,0x0) /Path(131,23,0x010000006....

Wieder war ich zu langsam und nun kommt gar nichts mehr. Ich habe erst zu spät bemrkt, dass das immer die gleichen Einträge sind, was hätte ich da denn auswählen sollen oder wäre es egal gewesen?

Bei der Installation hatte ich angegeben, dass Treiber von Drittanbietern verwendet werden sollen. AMD wäre da dabei, aber der PC ist zu neu, dass es Treiber gibt.

Siehe https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key.

Danke. Hast du eine Ahnung woran es im UEFI / Bios liegen könnte, wenn da zwar Secure Boot eingestellt ist, aber dann Ubuntu es nicht verwendet (anderer PC, gleiches Modell)? Bei einem habe ich auf "optimized defaults" eingestellt und die Keys zurückgesetzt, worauf das MOK-Menü kam. Ubuntu funktioniert und Windows funktioniert auch, da ist mir nur wichtig, dass der PC aktiv registriert ist. Also solange ohne "secure boot" alles läuft, ändere ich das erst bei der nächsten Neuinstallation.

Hallo,

weil die verlinkte Seite erstens auf englisch ist und zweitens die folgende Frage,

glaskugel schrieb:

... Bis ich überlegt habe was der Unterschied zwischen "key" und "hash" ist, war die Eingabemöglichkeit weg: ...

nur indirekt behandelt:

Bei Secure Boot gibt es zwei Möglichkeiten, wie eine Datei beim Systemstart auf Ihre Authentizität geprüft werden kann:

1. Anhand eines Keys: Dann gibt es ein Schlüsselpaar bestehend aus einem privaten Schlüssel, mit dem die beim Systemstart zu prüfende Datei signiert wird und einem öffentlichen Schlüssel - der bei Secure Boot eingebettet in ein Zertifikat - in einer dafür vorgesehenen und besonders geschützten Datenbank innerhalb des NVRAMs der Firmware hinterlegt wird. So kann die Firmware beim Systemstart dann die Signatur der betroffenen Datei anhand des hinterlegten Zertifikats prüfen.

2. Anhand eines Datei-Hash-Wertes: Bei der Methode wird ein Hashwert der beim Systemstart zu prüfenden Datei - z.B. Bootloader (shimx64.efi) oder eines Kernelmoduls erzeugt und dieser Wert wird in dem oben beschriebenen Bereich der Firmware hinterlegt.

Das Problem von Hashwerten ist, dass die Verwaltung aufwendiger ist. Ändert sich die zu überprüfende Datei, so muss der neue Hashwert jedes mal in die Datenbank im NVRAM eingetragen werden. Zusätzlich muss der alte Hashwert für die veraltete Datei gelöscht oder auf die Blacklist gesetzt werden.

Bei der ersten Methode muss dagegen die aktualisierte Datei nur mit dem vorhandenen privaten Schlüssel signiert werden. Der dazu passende öffentliche Schlüssel ist ja bereits in der Datenbank der Firmware hinterlegt.

Das was für die eigentlichen Secure Boot Keys gilt, gilt genauso für die "Machine Owner Keys" (MOKs). Auf MOKs tifft das oben gesagte gleichermaßen zu, allerdings liegen die nicht in der eigentlichen Secure Boot Datenbank der Firmware, sondern da werden innerhalb des Shim-Setups im NVRAM eigene EFI-Variablen angelegt. Die sind zwar immerhin auch durch Authentifizierung geschützt, aber nicht im gleichen Maße, wie die EFI-Variablen der eigentlichen Secure-Boot-Datenbank der Firmware.

Das was man im Rahmen der Ubuntu-Installation beim ersten Neustart in der MOK-Datenbank hinterlegen muss ist ein "Key". Das ist der Schlüssel, der automatisch während des Setups erzeugt wird, wenn man auf einem Secure-Boot-System Dritthersteller-Treiber anwählt und dort ein Passwort erstellt. Die Abfrage zum Eintragen (enrollment) des Keys kommt nach meiner Erfahrung nur ein mal und das beim Setup gewählte Passwort gilt auch nur einmalig für diesen einen Eintragsversuch beim nächsten Neustart. Verstreicht das Timeout, dann wird der Key nicht in die MOK-Datenbank eingetragen und der Dritthersteller-Treiber solle folglich auch nicht geladen werden.

Übrigens: Secure Boot lässt ich IMO auf Linux-Systemen nicht so (leicht) umsetzen, wie im Windows-Kosmos.

Der Grund: Secure Boot soll ein System vor einem Remote-Angreifer selbst dann noch schützen, wenn dieser auf dem betreffenden System Rootrechte (administrative Rechte) erlangt. Schützen soll Secure Boot dabei die Integrität des Bootprozesses und nicht etwa den Angriff im laufenden System. So soll verhindert werden, dass der Angreifer Boot- oder Rootkits in den Startprozess des Systems einschleust.

Das funktioniert im Windows-Kosmos grundsätzlich theoretisch auch, weil dort auf dem Endanwender-System keine privaten Schlüssel zum Signieren von Treibern oder Betriebssystem-Komponenten liegen. Das Signieren der Dateien erfolgt im Windows-Kosmos entweder bei Microsoft oder bei den Drittherstellern.

Im Linux-Kosmos - und so ist das im Moment auch bei Ubuntu umgesetzt - erfolgt das Signieren für alle beim Systemstart erforderlichen Komponenten, die nicht von Canonical bereitgestellt werden, auf dem System des Endanwenders. Damit hat ein Remote-Angreifer der an Rootrechte gelangt, den vollen Zugriff auf die Schlüssel und könnte seine Root- und Bootkits damit signieren.

Ein weiteres Problem für Distributionen, deren initrd nicht in das Kernel-Image integriert ist - wie auch bei Debian und Ubuntu: GRUB kann derzeit eine eigenständige initrd gar nicht gegen die Secure-Boot- oder auch MOK-Datenbank prüfen.

Lange Rede, kurzer Sinn: Secure Boot unter Ubuntu ist derzeit nicht richtig umgesetzt und bietet dementsprechend nicht mal den theoretisch möglichen Schutz, den es bieten könnte.

glaskugel schrieb:

.. Hast du eine Ahnung woran es im UEFI / Bios liegen könnte, wenn da zwar Secure Boot eingestellt ist, aber dann Ubuntu es nicht verwendet (anderer PC, gleiches Modell) ...

Wahrscheinlich handelt es sich dabei um eine grottige Impelmentierung von Secure Boot in der Firmware. Zumindest während des Setups muss das Live-System aber im UEFI-Modus gestartet sein und auch Secure Boot als aktiv erkannt haben, denn andernfalls würdest Du bei der Option von Dritthersteller-Treibern während der Installation nicht zum Anlegen eines Passwortes aufgefordert.

Was sagt denn auf dem System:

sudo mokutil --sb-state​

LG, Newubunti

Was sagt denn auf dem System:

Das ist jetz von einem anderen MiniPC:

sudo mokutil --sb-state​
mokutil: unrecognized option '--sb-state​'

Aber es kommt das bei den Optionen mit der Fehlermeldung:

--sb-state				Show SecureBoot State

ii  mokutil                                       0.6.0-2~22.04.2                              amd64        tools for manipulating machine owner keys

Danke für die ausführliche Erklärung. Ich kann das aber nicht so schnell abfragen. Dieser Mini-PC liegt nur rum, da ich zur Zeit mit seltsamen Internet-Verhalten kämpfe, dürfte béi der Fritzbox was durcheinander gekommen sein, das ist dringendst.

Was ich gelernt habe, Windows verlangt, dass die Hardware Secure Boot können muss, aber es muss dann bei der Installation nicht verwendet werden, also deaktiviere ich secure boot und habe dann hoffentlich Ruhe. Sehr sinniges Konzept bei Win 😉 Aber eigentlich zum Glück.

Das Windows ist eigentlich nur bei den MiniPCs neu installiert, um zu sehen, ob die Registrierung erkannt wird, da hat man 50%, dass es nicht passt und man muss beim Hersteller einen Key anfordern, normalerweise problemlos, dass man den mit Seriennr. kriegt, aber nervig. Wenn es passt, ist mir Win ziemlich egal.

glaskugel schrieb:

...

sudo mokutil --sb-state​
mokutil: unrecognized option '--sb-state​'

Mein Fehler! Da hatte ich das Kommando wohl von einer Seite kopiert, bei der irgend etwas mit den Leerzeichen nicht stimmt.

Bitte noch mal das hier per Copy & Paste probieren:

sudo mokutil --sb-state 

Falls das wieder zu der Fehlermeldung führen sollte, dann das Kommando bitte per Hand eingeben.

LG, Newubunti

$ sudo mokutil --sb-state 
SecureBoot disabled
Platform is in Setup Mode

An den anderen PC komme ich zur Zeit nicht ran.

glaskugel schrieb:

$ sudo mokutil --sb-state 
SecureBoot disabled
Platform is in Setup Mode

Ah ok, das System befindet sich im Setup Mode. Hast Du das so in der Firmware eingestellt? Je nach Firmware-Implementierung aktiviert man den Setup Mode durch einen eigens dafür vorgesehenen Menü-Eintrag - häufig nennt der sich sich auch irgendetwas mit "Custom" - oder es kann auch sein, dass es bei Dir einen Eintrag zum Löschen der Default-Keys gibt. Löschen aller Keys muss laut Spezifikation das System immer in den Setup Mode versetzen.

Ich würde das System nicht dauerhaft im Setup Mode betreiben, weil da die Secure-Boot-Datenbank mehr oder weniger ungeschützt ist. Ich würde es in den User-Mode versetzen, das geht im Zweifel durch Laden der Default-Keys, und dann Secure Boot "nur" deaktivieren - sofern Du deaktiviertes Secure Boot bevorzugst. Kommt aber auch darauf an, was Dir das Firmware-Setup an Optionen anbietet.

Wenn Du bei Deinem System prüfen willst, ob Secure Boot nach den Microsoft-Vorgaben sauber implementiert ist, dann lade mal die Default-Keys und schau sie Dir dann mittels mokutil an:

mokutil --pk
mokutil --kek
mokutil --db
mokutil --dbx 

1. Der PK kommt normalerweise vom Hersteller des Systems.

2. KEK sollte einer von Microsoft sein. Häufig gibt es auch einen KEK vom Hersteller.

3. DB-Keys müssen zwei von Microsoft sein. Einmal der von Microsoft für Windows und dann noch der Microsoft Third Party. Eventuell auch wieder noch ein Schlüssel vom Hersteller.

4. DBX müssten bei einem heute ausgelieferten System schon einige Einträge vorhanden sein. Allerdings kann man die Blacklist auch noch nachträglich aktualisieren.

Außerdem darf es auf keinen Fall so sein, dass Du bei aktiviertem Secure Boot gleichzeitig den Legay(BIOS)-Boot-Modus nutzen kannst. Der BIOS-Boot-Modus darf nur aktivierbar sein, wenn zuvor Secure Boot deaktiviert wurde. Wenn das der Fall wäre, dann ist die Umsetzung unbrauchbar und zwar auch dann, wenn Du Secure Boot vollständig mit eigenen Keys nur für Linux verwenden willst.

LG, Newubunti

irgendetwas mit "Custom"

Ja, gibt was in der Richtung, der andere Eintrag ist Standard. Muss ich mir genauer ansehen.

Ich würde das System nicht dauerhaft im Setup Mode betreiben,

Danke für den Hinweis

Ich möchte mir Ubuntu nicht neu konfigurieren und wenn möglich Windwos auch nicht. Was mache ich da am besten?

glaskugel schrieb:

... Ich möchte mir Ubuntu nicht neu konfigurieren und wenn möglich Windwos auch nicht. Was mache ich da am besten?

Du schaust Dir im Firmware-Setup genau an, was Du da alles für Secure Boot konfigurieren kannst.

Wenn Du es so konfigurieren kannst, wie von mir beschrieben - also User Mode statt Setup Mode, aber Secure Boot auf "disabled" - dann kannst Du das so einstellen. Da Secure Boot bei dieser Kombination nach wie vor deaktiviert bleibt, ändert sich in Deiner Betriebssystempraxis nichts.

Es wäre aber auch denkbar, dass es in Deinem Firmware-Setup keine extra Option alleine zum Deaktivieren von Secure Boot gibt. Das ist zwar eher unwahrscheinlich, aber nicht gänzlich unmöglich. Dann hängt der Secure Boot Status am Zustand bzw. Vorhandensein der Keys:

In dem Fall wäre das System nach Löschen der Default Keys im Setup-Modus. In den User-Modus könntest Du aus diesem Modus dann nur gelangen, indem Du einen eigenen Plattformkey in die Secure-Boot-Datenbank eintragen würdest. In dem Moment wechselt das System auch vom Setup- in den User-Modus. Gleichzeitig würde Secure Boot dann auch aktiviert.

Oder Du würdest die Default-Keys laden, womit Du auch einen Default-Plattformkey laden würdest und damit würde das System dann auch wieder Secure Boot aktiv schalten.

Diese Szenario ist aber eher die Ausnahme. In der Regel lässt sich Secure Boot nochmal extra aktivieren/deaktivieren und zwar auch dann, wenn das System im User-Modus ist. Jedenfalls hat die UEFI-Spezifikation zwei Variablen vorgesehen, nämlich für Setup-Mode bzw. User-Mode an oder aus und dann eine weitere für Secure Boot aktiviert/deaktiviert.

Wie das bei Dir jetzt genau umgesetzt ist, weiß ich nicht und musst Du selbst herausfinden. Danach kann man weitersehen.

LG, Newubunti

Danke dir, bevor ich da weiter mache, muss ich mein Netzwerkproblem lösen, bin jetzt schon so weit, dass die 1. Internetverbindung nur mehr 10-30 Sekunden dauert, früher dauerte es bis zu 10 Minuten oder ging gar nicht. Am PC habe ich kaum was geändert, dürfte an der Fritzbox liegen. Wird also dauern bis ich hierher zurück komme.