die Frage ist nicht, wie bootet man ohne grub. Dank UEFI geht es ganz ohne Bootloader, oder mit systemd-boot oder efibootguard¹ oder... Die Frage ist, wie wird man grub los? Selbst ein ziemlich aktueller Tipp² funktioniert nicht
1
A user wanting to switch from GRUB to systemd-boot should do so by
2
removing the GRUB packages and installing systemd-boot at the same time:
3
4
# apt install systemd-boot grub-efi-amd64-signed-
5
E: Removing essential system-critical packages is not permitted.
6
This might break the system.
Das kommt mir vor wie "I'm sorry, Dave. I'm afraid I can't do that." Warum ist grub immer noch essential, wenn gleichzeitig ein Ersatz installiert wird? Ahnt apt etwa, dass ich systemd-boot garnicht haben will sondern efibootguard? Aber der funktioniert schon. Zum Booten wird grub also nicht gebraucht, wofür denn sonst?
... und alle Warunngen ignorieren. Oder mit "equivs" einen gurb-dummy bauen. Du solltest dir aber schon sicher sein, dass dein System ohne GRUB noch bootet :)
0 upgraded, 4 newly installed, 14 to remove and 0 not upgraded.
16
Need to get 1923 kB of archives.
17
After this operation, 955 MB disk space will be freed.
18
Do you want to continue? [Y/n] ^C
Das ist interessant, denn die meisten Pakete werden da direkt unverendert von Debian übernommen.
Bei z.B. libc-bin bekomme ich so eine Meldung aber. Ich hab mal in der manpage nachgeschaut, mit der Option "--allow-remove-essential" kann man apt sagen, dass es das erlauben soll.
Ein Vorteil von UEFI ist, dass du mehrere Bootloader parallel installieren kannst, und dann über das UEFI-Bootmenu auswählen kannst, welcher starten soll.
Also: einfach sd-boot parallel installieren, ohne grub-Deinstallation.
Ausprobieren. Wenn alles tut, im UEFI-Setup den default auf sd-boot ändern.
Dann (optional) grub deinstallieren.
EFI-Loader können sich auch ("Chainloading") gegenseitig starten, könntest also auch im Grub einen systemd-boot-Eintrag einbauen und umgekehrt.
Auf meinem selbst gebootstrappten Devuan Daedalus kann ich das nicht
reproduzieren:
Das "selbst gebootstrappt" dürfte der Unterschied sein. Die grub-Pakete selbst sind nicht essential. Anscheinend wird irgendwann bei der "offiziellen" Installation ein essential-Flag gesetzt. So weit so gut und vernünftig. Aber man sollte nachträglich eine Alternative installieren können.
Der Installer kennt ja z.Zt. keinen anderen Bootloader, aber es gibt offizielle Pakete als Alternative und der originale Debian-Kernel kommt mit dem EFI-Stub. Wer das nutzen möchte, braucht auch kein grub -- dachte ich bis eben. Aber die Anleitung¹ zum EFI-Stub im Debian-Wiki geht davon aus, dass man grub selbstverständlich behält; die funktioniert ohne grub garnicht. Faszinierend!
Ich hab mal in der manpage nachgeschaut,
mit der Option "--allow-remove-essential" kann man
apt sagen, dass es das erlauben soll.
Danke, so extreme Optionen kenne ich natürlich nicht ;) Trotzdem, eine gewaltfreie Lösung wäre mir lieber. Wer weiß, vielleicht verlässt sich irgendein update-Script darauf, dass es grub gibt. Ich will nämlich grub deshalb loswerden, weil ich den ständigen automatischen Updates nicht traue.
Ein Vorteil von UEFI ist, dass du mehrere Bootloader parallel
installieren kannst, und dann über das UEFI-Bootmenu auswählen kannst,
welcher starten soll.
Also: einfach sd-boot parallel installieren, ohne grub-Deinstallation.
Ausprobieren. Wenn alles tut, im UEFI-Setup den default auf sd-boot
ändern.
Bis hier ist alles trivial und funktioniert. Noch einfacher geht's mit efibootguard statt sd-boot (oder noch bunter mit refind).
Dann (optional) grub deinstallieren.
Aber wie?
EFI-Loader können sich auch ("Chainloading") gegenseitig starten,
könntest also auch im Grub einen systemd-boot-Eintrag einbauen und
umgekehrt.
Das konnte schon syslinux, es geht bestimmt /noch/ komplizierter, gib dir ein bisschen Mühe ;)
EFI-Loader können sich auch ("Chainloading") gegenseitig starten,
könntest also auch im Grub einen systemd-boot-Eintrag einbauen und
umgekehrt.
Das konnte schon syslinux, es geht bestimmt noch komplizierter, gib
dir ein bisschen Mühe ;)
Auf meinen Linux Phones und meinem Rock 5B habe ich U-Boot installiert, weil da keine Firmware drauf ist (sind alles ARM64 Geräte). Damit könnte ich direkt den Kernel laden, flash-kernel kann das alles übernehmen, aber stattdessen habe ich im selbst gebauten U-Boot EFI aktiviert, und starte mit U-Boot das normale Grub aus den Repos, womit ich wiederum den selbst kompilierten Kernel starte.
Die Idee war, dass das wie jede andere EFI Installation wäre, und ich irgend wann mal einfach den Installer statt selbst gebootstrapte Images nehmen kann. Aber es ist immer noch nicht ganz alles im Mainline Kernel (z.B. Display Zeugs), im Debian Kernel natürlich auch nicht, und im U-Boot sind die Display Panels auch nicht implementiert (und ich habe keinen EFI Framebuffer).
Beim Rock 5B mit EDK Firmware geht der Installer und EFI Framebuffer immerhin, wenn auch ein paar andere Sachen nicht.
Naja, irgendwann wird das schon noch kommen, der Tag, an dem man beim Smartphone einfach den Installer nehmen kann...
Ich will nämlich grub deshalb loswerden, weil ich den ständigen
automatischen Updates nicht traue.
Und was genau hat der Bootloader damit zu tun?
Ein tragisches Missverständnis :( Bei z.B. einem Kernel-Update wird automatisch update-grub gestartet. Das meinte ich mit automatisch.
Von wegen 'grub loswerden': anscheinend ist das wirklich nicht vorgesehen bzw. ungetestet: apt müsste mit Gewalt überredet werden, aber aptitude macht es einfach. Man darf dabei nur kein purge verlangen, dann gibt es eine fette Warnung und man müsste "Yes, I am aware this is a very bad idea" eintippen. Das aber auch nur bei einem der grub-Pakete, das meiste verschwindet ohne Warnung, man hat dann also ein halbes grub.
Mangels purge hätte ich erwartet, dass dpkg -l das Paket dann als rc listet (o.ä.), aber nein, es ist weg. Es bleiben allerdings ca. 10MB in über 300 Dateien unter /boot/grub/ übrig.
Der Installer bietet an, ganz ohne Bootloader zu installieren. Das sieht gut aus, grub wird nicht installiert und das System läuft. Allerdings war der systemd beim ersten Start total verwirrt und es gab nur noch die emergency console (heißt die so?).
Früher hatte ich mal grub auf der EFI-Partition manuell gelöscht. Der Rechner hätte also nicht mehr (mit grub) gebootet, aber update-grub hat das weder gemerkt noch repariert.
Ich glaube, man merkt, dass mir grub viel zu komplex ist.
Ein tragisches Missverständnis :( Bei z.B. einem Kernel-Update wird
automatisch update-grub gestartet. Das meinte ich mit automatisch.
Ja natürlich, du willst den neuen Kernel ja auch booten. update-grub aktualisiert nicht grub, sondern dessen Konfigurationsdatei in /boot damit er auch weis das da ein neuer Kernel liegt.
Debian-Bullseye-Nutzer hier! Ich habe kein grub installiert und kann mich auch nicht erinnern, dass ich Probleme hätte es nach der Systeminstallation zu entfernen ("apt list --installed 2>/dev/null | grep grub" ist tatsächlich leer).
Ich habe zu meiner Windows-Installation, die ich komplett unangetastet lassen wollte, da diese mithilfe des TPMs auch Bitlocker-verschlüsselt ist, im freien SSD-Speicher einfach eine weitere FAT- und Ext4-Partition erstellt. Über objcopy erstelle ich mir mit dem Efi-Stub, dem Kernel und dem Initramfs ein Unified Kernel Image.
Dieses Kernel-Image signiere ich dann noch mit selbst erstellten, Passwort-geschützen Keys und habe sie mit dem mokutil in die Efi Variablen geladen. Damit kann Shim dann das Kernel Image verifizieren. Wenn ich das System aktualisiere, führe ich diese Schritte dann immer manuell durch.
Das mit Shim war aber nicht so einfach. Es gibt an der Stelle ein gewisses Protokoll zwischen dem ursprünglichen Shim und Grub. Das hatte der EFI-Stub von sd-boot nicht implementiert. Hier weiß ich nicht, ob das mittlerweile funktioniert. Aus diesem Grund musste ich Shim 1.40.7 von Ubuntu nutzen. Nicht schön, aber funktioniert.
Da ich Secure Boot erhalten wollte, wird Shim zuerst geladen. Shim wird im UEFI mit dem Tool efibootmgr registriert. Ich benutze hauptsächlich Linux. Das startet automatisch. Wenn ich Windows starten will, rufe ich beim Booten per F9 das Uefi-Bootmenü auf und wähle dort den Windows-Boot-Eintrag.
Da sind keine weiteren Bootloader notwendig. Shim lädt dann standardmäßig grubx64.efi im selben Verzeichnis. Also wird mein Kernel Image jetzt genau dorthin als grubx64.efi kopiert.
Das startet ohne Probleme und mit meinem TPM wird dann noch die Luks-verschlüsselte Partition, die zwei LVM Volumes (Root-Dateisystem und Swap) enthält, entschlüsselt.
Über objcopy erstelle ich mir mit dem Efi-Stub, dem Kernel und
dem Initramfs ein Unified Kernel Image.
Dieses Kernel-Image signiere ich dann noch mit selbst erstellten,
Passwort-geschützen Keys und habe sie mit dem mokutil in die Efi
Variablen geladen. Damit kann Shim dann das Kernel Image verifizieren.
Braucht man Shim dann überhaupt noch? Benutzt Shim wenigstens automatisch den machine owner key und ignoriert alle anderen? Ich dachte, die einzige Möglichkeit Secure Boot sinnvoll zu nutzen, wäre genau diese eine selbstsignierte Datei (inkl. initrd und allem) direkt per UEFI zu booten?
Ja, ich bin neugierig und eigentlich geht mich das garnichts an. Ich glaube, wenn der Angreifer seinen eigenen USB-Stick einstecken kann, nützt das alles nichts.
Das mit Shim war aber nicht so einfach. Es gibt an der Stelle ein
gewisses Protokoll zwischen dem ursprünglichen Shim und Grub.
Von wegen 'grub loswerden': anscheinend ist das wirklich
nicht vorgesehen bzw. ungetestet
Also, grub bleibt drauf. Diese kleinen Ungereimtheiten sind mir doch noch suspekter als grub selbst.
Der Installer bietet an, ganz ohne Bootloader zu installieren. Das sieht
gut aus, grub wird nicht installiert und das System läuft. Allerdings
war der systemd beim ersten Start total verwirrt
Das lag nicht an grub, das passiert auf dem Rechner auch mit einer ganz normalen Installation inkl. grub. Anscheinend kennt systemd den Partitions-Typ "Linux server data", kann aber damit nicht umgehen und deshalb(?) funktioniert system-timesyncd nicht. Warum muss der auch so neugierig sein, die Partition gehört nicht zu dem System, die geht ihn garnichts an.
Über objcopy erstelle ich mir mit dem Efi-Stub, dem Kernel und
dem Initramfs ein Unified Kernel Image.
Dieses Kernel-Image signiere ich dann noch mit selbst erstellten,
Passwort-geschützen Keys und habe sie mit dem mokutil in die Efi
Variablen geladen. Damit kann Shim dann das Kernel Image verifizieren.
Braucht man Shim dann überhaupt noch? Benutzt Shim wenigstens
automatisch den machine owner key und ignoriert alle anderen? Ich
dachte, die einzige Möglichkeit Secure Boot sinnvoll zu nutzen, wäre
genau diese eine selbstsignierte Datei (inkl. initrd und allem) direkt
per UEFI zu booten?
Shim brauche ich nur, da ich meine Keys nicht direkt im Uefi hinterlegt habe, sondern über den MOK verifiziere. Und soweit ich weiß prüft er nur gegen den MOK und direkt einkompilierte Keys. Aus diesem Grund ist es aus Sicherheitsgründen schwierig zu betrachten, dass ich so eine ältere Version von Shim einsetze.
Auf Server-Systemen (wo kein Windows drauf ist) habe ich das genau so umgesetzt, dass ich alle Keys im Uefi gelöscht, meine eigenen Keys installiert habe, und das Unified Kernel Image direkt vom Uefi geladen wird.
Ja, ich bin neugierig und eigentlich geht mich das garnichts an. Ich
glaube, wenn der Angreifer seinen eigenen USB-Stick einstecken kann,
nützt das alles nichts.
Nunja, Secure Boot sollte meines Erachtens auch nie vor Evil-Maid-Angriffe schützen. Abhilfe wäre hier das Booten von USB im Bios zu deaktivieren und das Bios mit Passwort zu schützen. Das wäre die einfachste Maßnahme.
Noch ein Hinweis, falls du noch weiteres Interesse an dem Thema haben solltest: Wenn man das Root verschlüsselt und die Keys im TPM sichert, kann man konfigurieren, unter welchen Bedingungen das TPM die Keys freigibt. Das kann man so rigide einstellen, dass das TPM hier Modifikationen an der Firmware (dem Uefi), an den Einstellungen, an den Keys und an der Boot-Chain erkennt (siehe PCR-Register) und die Keys ggf. nicht freigibt. So ist es durchaus möglich, dass bei jeglicher Modifikation deine Daten nicht automatisch entschlüsselt werden. Wenn du beim Booten dann nach deinem Passwort zum Entschlüsseln gefragt wirst, wäre was faul. Das handhabt Windows genauso, es fragt dich nach deinem Bitlocker-Wiederherstellungsschlüssel, wenn man nach der Aktivierung von Bitlocker, Grub in die Boot-Chain einbaut.
Dann gibt es noch weitere Angriffsvektoren, aber das würde jetzt hier zu weit führen. Ein perfekt sicheres System gibt es nicht und bei den Sicherungsmaßnahmen sollte immer Aufwand mit Nutzen abgewogen werden.
