guten Abend,
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?
[1] https://github.com/siemens/efibootguard/blob/master/docs/USAGE.md
[2] https://wiki.debian.org/SecureBoot
# apt purge $(dpkg -l|awk '/grub-/ { print $2 }')
... 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.
Daniel A. schrieb:> 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.
[1] https://wiki.debian.org/EFIStub
Εrnst B. schrieb:> 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 ;)
Bauform B. schrieb:>> 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...
Bauform B. schrieb:> 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? Glaubst du etwa das der
dafür verantwortlich ist das du ein Update bekommst?
Schau mal unter /etc/apt/apt.conf.d/ ob da die Datei 10periodic liegt.
In der Zeile: APT::Periodic::Update-Package-Lists "1";
Einfach "0" anstelle 1 eintragen.
Damit prüft das System nicht mehr auf Updates und du hast deine Ruhe.
Kilo S. schrieb:> Bauform B. schrieb:>> 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.
Bauform B. schrieb:> Ein tragisches Missverständnis :( Bei z.B. einem Kernel-Update wird> automatisch update-grub gestartet. Das meinte ich mit automatisch.
Das klingt gleich logischer.
Bauform B. schrieb:> 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.
Benny schrieb:> Ü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.
Noch ein Grund, grub nicht zu mögen...
Bauform B. schrieb:> 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.
Bauform B. schrieb:> Benny schrieb:>> Ü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.
Benny schrieb:> 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,
Das Thema ist sehr interessant, aber jetzt fange ich nicht auch noch
damit an. Trotzdem vielen Dank für deine Beiträge.
Thread beobachten
Seitenaufteilung abschalten