ubuntuusers.de

Ich möchte mehrere Systeme in einer Secure Boot Umgebung installieren. Der aktuelle signed-shim von Ubuntu kann den signierten Ubuntu-Kernel und den Microsoft-Loader starten. Frage: kann er auch den aktuellen signierten Debian Buster Kernel laden?

Die Frage verfehlt den Themenbereich des Forums „Sicherheit“ zwar nicht vollständig, jedoch passt ihr Schwerpunkt doch wohl besser zu „Installation“.

Hallo MisterKnister,

Herzlich Willkommen auf Ubuntuusers.

Warum sollte er es nicht ? Schließlich sind diese Kernel signiert ..... bei ACER muss das Starten auch noch extra durch die Einstellungen im EFI signiert werden.

Gruss Lidux

Warum nicht? Zum Beispiel könnte es sein, dass der Ubuntu signed-shim nur die Public-Keys vom Microsoft Loader und den des eigenen Kernels kennt, aber nicht den vom Debian Kernel...

Danke für das Willkommen ☺

Ich habe nun eine Antwort auf meine Frage. Leider ist es so, dass meine Befürchtung zutreffend war: der Ubuntu-Signed-Shim ist nicht in der Lage einen signierten Debian-10-Kernel zu laden! Ubuntu 20.04 hat mir zwar eine Parallel-Installation zu einem Debian-10 angeboten, und danach einen zusätzlichen Grub-Bootmenu-Eintrag erstellt. Das hat meine Hoffnung geweckt. Leider wird das Starten vom Debian-10-Kernel aber mit "...has invalid signature" quittiert. Für mich ist diese Frage damit beantwortet und ich werde sie schliessen...

Noch ein Update für alle Secure-Boot-User: das gleiche gilt auch umgekehrt - ein nachträglich installiertes Debian-10 kann aus dem Grub-Menu/seinem Shim kein Ubuntu 20.04 nachladen ("invalid signature")! Ich habe hier zwei Notebooks: ein Acer und ein Medion. Das Acer hat immerhin die Möglichkeit, über UEFI-Bios-Option "Bootmedium" eine der beiden Distributionen direkt zu starten. Beim Medion geht das nicht - hier ist/wäre man komplett aufgeschmissen. Ich rate deswegen aktuell eher ab, signierte Linux-Distributionen (Ubuntu,Debian,RedHat,Suse) in einer Secure-Boot-Umgebung parallel zu installieren. Die entsprechenden Shim/Grub Konfigurationen sind nicht Linux-interoperabel (nur eine Distro und Microsoft - das geht). Wer keine gute UEFI-Bios-Firmware hat, kommt im Zweifelsfall gar nicht mehr an die vorherige Distribution ran.

Ich finde es sehr schade, dass wir hier (anscheinend) durch die Microsoft-Signierungs-Policies so eingeschränkt werden, dass die gewohnte Linux-Interoperabilität im Secure-Boot-Bereich nicht mehr gegeben ist. Es wird m.E. Zeit, dass die Hardware-Hersteller endlich die Public-Keys der gängigen Linux-Distributionen in der Firmware hinterlegen; damit diese MS-Abhängigkeit endlich aufhört.

MisterKnister schrieb:

Frage: kann er auch den aktuellen signierten Debian Buster Kernel laden?

Nein, das kann er nicht und umgekehrt auch nicht. Das ist ein typischer Fall von "it's not a BUG, it's a feature!".

Ubuntu-Shim wird ohne weiteres Zutun nur Kernel laden, die von Canonical signiert sind. Debian wird nur von Debian signierte Kernel laden usw.. Das ist im Sinne von Secure-Boot auch gut so, denn es geht ja genau darum eine vertrauenswürdige Kette vom Einschalten der Hardware bis zum Systemstart und der Installation von Treibern zu sorgen, um z.B. die Installation von Rootkits zu verhindern, die sich z.B. auf die Bootpartition installieren um dann Deine Verschlüsselungs-Passphrase auszulesen.

In diesem Sinne bürgt jeder Sicherheits-technisch nur für das, was er auch im eigenen Herrschaftsbereich verantwortet.

MisterKnister schrieb:

Ich finde es sehr schade, dass wir hier (anscheinend) durch die Microsoft-Signierungs-Policies so eingeschränkt werden, dass die gewohnte Linux-Interoperabilität im Secure-Boot-Bereich nicht mehr gegeben ist.

Das hat mit Microsoft nichts zu tun, sondern mit Secure-Boot und macht auch Sinn. Siehe auch im Debian-Wiki: What is UEFI Secure Boot NOT

Eingeschränkt wirst Du gar nicht, Du musst Dich im Zweifel aber selbst um das Signieren und Hinterlegen der Schlüssel entweder im UEFI selbst oder über den MOK-Manager kümmern und kannst halt Pech mit der Implementierung von UEFI auf Deiner spezifischen Hardware haben.

Praktische Erfahrung habe ich dazu nicht, aber grundsätzlich wäre dies möglich. Ansätze und technisches Grundwissen dazu findest Du z.B. hier:

Rod Smith zum "Cross-Distribution"-Booting mit Shim: https://www.rodsbooks.com/efi-bootloaders/secureboot.html#initial_shim

Rod Smith zur Kontrolle des Secure Boot Prozesses auf seiner eigenen Seite: https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html

Mathew Garret (Entwickler von Shim) zur detaillierten Funktionsweise von Shim: https://mjg59.dreamwidth.org/19448.html

Diskussion zur Funktionsweise von Shim auf askubuntu - insbesondere die Antwort von Rod Smith ist lehrreich: https://askubuntu.com/questions/951040/how-shim-verifies-binaries-in-secure-boot

All diese Quellen werden Dir die Lösung für Dein Problem nicht in einer Schritt-für-Schritt-Anleitung präsentieren. Du musst das angelesene Wissen dann auch sicher noch mit Ausprobieren in die Praxis umsetzen. Dazu würde ich Dir aber auf alle Fälle eine virtuelle Maschine empfehlen.

UND ES GILT: Beim Ausprobieren mit UEFI bleiben je nach Hardware gewisse Restrisiken, wenn Du an den Efivars etc. rumschraubst. Sollte bei sauberere UEFI-Implementierung eigentlich nicht der Fall sein, die Praxis sieht halt leider (manchmal?, öfter?, häufig?) anders aus.

Es wird m.E. Zeit, dass die Hardware-Hersteller endlich die Public-Keys der gängigen Linux-Distributionen in der Firmware hinterlegen; damit diese MS-Abhängigkeit endlich aufhört.

Aus Sicherheitstechnischer-Sicht finde ich es eher ein Vorteil, dass nicht massig Keys von sonst wem direkt ab Werk hinterlegt sind.

Secure-Boot ist ein Sicherheits-Feature und dementsprechend erhöht es bei richtiger Anwendung die Sicherheit auch. Wie bei Sicherheitsfunktionen üblich erhöht sich durch deren Anwendung die Komplexität des Systems bzw. Setups.

Viel Glück und Erfolg!

Gruß, newubunti