Bringt es überhaupt einen Sicherheitsgewinn arch bzw. eos unter Secure Boot zu booten?
Nach dem Grub-Disaster und v.a. dem Microsoft(MS)-Update (KB5012170), das die UEFI-Bootsignaturen für grub entfernt hat,weil MS sagt, grub könne ein Einfallstor für Rootkits sein. Dies hat zur Folge, das Linuxdistributionen und Livesysteme, welche grub als Bootmanager verwenden, nicht mehr unter UEFI-Secure Boot-Bedingungen booten können.
Bisher habe ich keinen Weg gefunden, eos unter UEFI-Secure Boot-Bedingungen booten zu können.
Noch nicht versucht habe ich den Bootmanager zu wechseln z.Bsp. von grub auf refind! Weiß jemand, ob refind unter UEFI-Secure Boot-Bedingungen bootet? Ich wüßte es gern, eh ich eine Umstellung versuche.
I’m sorry I haven’t read German in nearly 10yrs but I can respond about Secure Boot in English.
The best way to use Secure Boot in EOS is with systemd-boot, sbctl, and using a unified (kernel,initramfs,etc packaged together) and signed efi image and a fully luks2 encrypted system.
This is 100% supported on EOS and sbctl is actually by one of the Arch maintainers. It takes some setup but once done its automatic after that.
This is possibly the most complete secure boot setup you can get on Linux without a fully verified system which isn’t easy.
echoa beschreibt einige Bedingungen wie:
"systemd-boot, sbctl, and using a unified (kernel,initramfs,etc packaged together) and signed efi image and a fully luks2 encrypted system.
Diese Bedingungen müsste ich in meinem System aber wohl nachinstallieren.
Mein Ausgangspunkt heute morgen, war ein c`t-Artikel “Ausgebootet-MIcrosoft schaltet Linux-Bootloader ab”, wo ein Weg beschrieben steht, wie man LInuxsysteme wieder unter Secure Boot-Bedingungen bootbar macht.
Demnach soll man das MS-UPdate (KB5012170) über den Updateverlauf deinstallieren neu booten und dann im Setup die DBX_Liste bearbeiten,wo es eine Revocation List mit 184 Einträgen geben soll, die auf das Update zurückgeht,und welche zu löschen sei. Leider komme ich über mein Setup nicht an die DBX heran, habe aber gesehen, unter dem Link von dalto: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
dass das auch aus eos heraus möglich sein könnte,nur wie(Befehl)?
Aber der in der c`t beschriebene Turnaround hat ohnehin einen Haken, denn wenn ich (KB5012170) deinstalliere, wird MS_Update stets versuchen es nachzuinstallieren und folglich müsste ich auch immer wieder erneut die DBX bearbeiten! Irgendwie nicht zu Ende gedacht!
Wenn ich mir den Link von dalto ansehe, und die ellenlange Seite,tue ich mir schon schwer das für mich richtige zu extrahieren. Gut ich muss noch einiges lernen, aber da bin ich überfordert.
Würde mich über eine Begleitung hin zu einem unter Secure Boot bootbaren System freuen.
Ja, aber die Frage ist halt IMO, ob du diese zusätzliche Sicherheit benötigst. Secure Boot schützt theoretisch gegen Malware/Angriffe, die deinen Bootloader verändern. Bei “normalem” Gebrauch von Linux ist es IMO äusserst unwahrscheinlich, sich solche Malware einzufangen bzw. so einem Angriff ausgesetzt zu sein. Daher würde ich sagen, dass Secure Boot für die meisten Nutzer unnötig ist.
Wenn du hingegen damit rechnest, dass es tatsächlich jemand auf deine Daten abgesehen hat (Industriespionage z.B.) dann macht Secure Boot durchaus Sinn, zumindest bis zu einem gewissen Grad. Auch Secure Boot ist nämlich, wie jede Soft-Hardware, nicht 100%ig sicher. Es gab in der Vergangenheit schon mehrere Lücken/Exploits und es ist davon auszugehen, dass es solche auch derzeit gibt und weiterhin geben wird. Wenn du also z.B. ins Visier des BND gerätst, wird dir vermutlich auch Secure Boot nicht helfen.
nein, meine Daten sind eher unwichtig. Diesbezzüglich mache ich mir keine Sorgen. Was mich jedoch anficht, ist der Umstand, das uns Linuxern etwas (Secure Boot) vorenthalten werden soll bzw. MIcrosoft, als Herr über die UEFI-Signaturen, so sein Desktop-Monopol verteidigt und Windoof fördert, das selbst das größte Einfallstor für Schadsoftware ist.
Wenn schon Secure Boot dann auch für uns!
Notfalls per EU-Verordnung. Bis dahin aber müssen wir uns selbst behelfen. Dazu will ich hier anstoßen und hoffe wir können gemeinsam einen Weg finden. Ich wechsle auch gern zu refind, wenn das den Weg einfacher macht!
Unabhängig davon ob nun bad boy microsoft oder nicht
Es wird nötig sein einen Weg zu finden Linux zusätzlich zu Windows zu installieren, das ist ein weit verbreitetes Szenario, wenn nicht das am meisten verbreiteste.
Und wenn Windows auf einem PC vorinstalliert mit secure boot eingeschaltet kommt ist es nötig das nutzen zu können.
Und wie dalto schon erwähnte es geht schon irgendwie… das Selbe zählt für viele Sachen die wir heute ohne großen Aufwand mit einfachen Befehlen erledigen können
volle Zustimmung.
Auch ist es so, das wer sein Windows verschlüsselt und wegen seines Linux aber Secure Boot deaktivieren muss, dem droht ggf. Datenverlust, wenn er das Windows mit deaktiviertem Secure Boot startet!
Also ein weiterer Grund, weshalb sich Linux unter Secure Boot starten lassen sollte!
Recht überlegt, sollte man Microsoft eigentlich einstampfen. Da blieb uns viel Ärger erspart. So aber bleibt es eine Herausforderung, die zu bewältigen auch ihren Vorteil hat. Schließlich wird Linux so immer noch besser!
Aber wie geht es jetzt weiter? Soll ich einfach mal der Dinge harren, die da kommen?
Bislang haben wir ja noch keine Lösung eos unter aktiviertem Secure Boot(SB) zu starten.Also hab ich weiter recherchiert und bin auf"shim" gestossen. Die Integration des Preloader in eos, könnte eine Möglichkeit sein, das Problem zu lösen (s.a.Ubuntu,Suse und Fedora).
shim böte auch die Möglichkeit bestehende Installationen nachträglich unter SB bootfähig zu machen, s.a. Ubuntu-Wiki: https://wiki.ubuntuusers.de/EFI_Nachbearbeitung/
und die Integration in die Live-Isos, macht auch diese unter SB bootfähig.
Ein Problem sehe ich noch,wenn ich es richtig verstanden habe, zwar verfügt shim über eine gültige UEFI-Signatur, bootet dann aber mit grub. Solange aber die Sicherheitslücken von grub, weswegen Microsoft(MS) grub die UEFI-Signatur entzogen hat, nicht behoben sind, läuft auch shim Gefahr seine UEFI_Signatur zu verlieren, weil es das ausführen unsicherer Bootloader ermöglicht! Eine Grub-Reparatur ist unumgänglich!
amd besten wäre ohne grub zu arbeiten… systemd-boot oder auch refind sollten das ermöglichen.
Aber grub ist eben der einzige der alles out of the box kann…
Ich werde so bald wie möglich mal einen ersten Versuch starten (ist dann der 5. soweit ich mich erinnere) hat sich einiges verbessert an Information und Optionen…
