staging.inyokaproject.org

kB schrieb:

Newubunti schrieb:

[…] Also unter Ubuntu startet GRUB im Secure Boot Modus nicht einfach Starteinträge für unsignierte Kernel die zuvor von os-prober entdeckt wurden, z.B. ein solchen für ein Ubuntu das nur im UEFI-Modus ohne Secure Boot installiert wurde.

Bist Du Dir da ganz sicher? Das wäre mir nämlich neu, dass sich GRUB so verhält. Es widerspricht meiner Erfahrung; allerdings kann ich nicht ausschließen, dass dies tatsächlich inzwischen verbessert wurde und meine Erfahrung damit überholt wäre.

Ich prüfe das gerade noch mal gegen, weil ich bei meinem Secure-Boot-Test-System einen Fehler festgestellt habe. Ergänzend zu der Aussage oben, weil die vielleicht missverständlich gewesen sein könnte: Man muss schon einen Kernel selbst kompilieren und nicht signieren, weil einfach nur der Kernel so wie er von Ubuntu installiert wird - auch wenn Secure Boot im UEFI gar nicht aktiv ist - immer mit dem Canonical Secure Boot Schlüssel signiert ist.

Ich gebe da noch mal Rückmeldung, sobald das System wieder sauber steht.

Ich glaube das aber nicht, weil:

• Wenn es sich so verhielte, wie Du schreibst, gibt es ja keine Motivation mehr für eine Änderung der Voreinstellung für os-prober mehr, denn ein von os-prober angelegter Menüeintrag ohne "secure boot" würde ja bei aktiviertem "secure boot" nicht funktionieren. Es wäre also bestenfalls ein kosmetisches Problem. Davon steht aber in der Patch-Ankündigung nichts.

Wo liest Du eigentlich, dass sich der Patch nur auf Secure Boot Systeme auswirkt?

Wenn das Problem darin liegt, dass sich ein Risiko potentiell erhöht, wenn einfach ungefragt von os-prober gegebenenfalls neue Menü-Einträge erzeugt werden, so besteht dieses Problem bei Nicht-Secure-Boot-Systemen doch auch.

Für Dich mag das vielleicht banal erscheinen, aber für ein Laien bei dem eine Ubuntu Installation einfach funktioniert hat und der sich deswegen noch nie richtig Gedanken um den Boot-Mechanismus gemacht hat, der weiß ja erst mal gar nicht, dass bei jedem Kernel-Update die Gefahr besteht, dass das Boot-Menü um weitere Booteinträge erweitert werden könnte, wenn z.B. ein entsprechend externes Medium am Rechner hängt. Und dann besteht die Gefahr, dass er einen solchen Eintrag bei einem Neustart bewusst aus Neugier oder auch versehentlich startet.

Man kann sich fragen - sofern das Problem wirklich nur darin besteht, dass ungefragt Menü-Einträge erstellt werden, wodurch sich eine potentielle Gefahr vergrößert - warum man da erst 2021 drauf kommt.

Weiter unten in dem Kommentar zum Patch ist ja auch noch die Rede davon, dass os-prober Mängel habe und auch deswegen nicht zu empfehlen sei. Ob diese Mängel sicherheitsrelevant sind oder nicht, ergibt sich aus dem Text IMO nicht.

LG, Newubunti

Newubunti schrieb:

Ich gebe da noch mal Rückmeldung, sobald das System wieder sauber steht.

Ich habe das jetzt noch mal sauber getestet - damit man keine Kernel kompilieren muss, habe ich OpenSuse Leap 15.3 und dann daneben Ubuntu 22.04 installiert:

1. Secure-Boot-Testumgebung auf Basis von virt-manager eingerichtet.

2. Mittels Live-Medium überprüft, dass keine NVRAM-Einträge für irgendein OS bestehen.

3. Dann Neustart und Installation von OpenSuse Leap 15.3 im Secure Boot Modus.

4. OpenSuse gestartet und geupdatet. Prüfen von efibootmgr -v und mokutil --list-enrolled

5. Boot-Eintrag für den shim von OpenSuse ist im NVRAM vorhanden, der Secure Boot Schlüssel von OpenSuse ist in Shim hinterlegt.

6. Neustart und start von Ubuntu 22.04 Desktop iso und Ubuntu 22.04 im Secure-Boot-Modus neben OpenSuse installieren lassen. (Insofern auch Bestätigung dessen, was black_tencate weiter oben gepostet hatte).

7. Neustart nach Neuinstallation und alle Updates für Ubuntu gezogen. (Im Grub Menü von Ubuntu Grub wird OpenSuse erwartungsgemäß gelistet, aber lasse ich erst mal links liegen)

8. Überprüfen von efibootmgr -v und mokutil --list-enrolled.

9. NVRAM-Eintrag für Ubuntu Shim wurde erstellt und ist nun aktueller default. mokutil listed den Secure Boot Schlüssel von Canonical. Soweit so gut.

10. Neustart und nun im Ubuntu-Grub-Menü den Eintrag für OpenSuse Leap gewählt.

11. Ergebnis: Fehlermeldung: Fehler: Falsche Shim-Signatur. Fehler: Sie müssen zuerst den Kernel laden

12. Zurücksetzen der VM und Aufruf des UEFI-Bootmanagers.

13. Auswahl des OpenSuse NVRAM-Eintrags.

14. Ergebnis: OpenSuse wird gestartet, ist also grundsätzlich weiter startbar, allerdings nicht so ohne weiteres dem GRUB von Ubuntu unter zujubeln.

Es hätte mich auch gewundert, wenn gar keine Prüfung stattfinden würde - und so hatte ich es auch nicht in Erinnerung (für Ubuntu 20.04) - denn sonst würde das folgende Blog-Post irgendwie keinen Sinn ergeben:

https://ubuntu.com/blog/how-to-sign-things-for-secure-boot

Allerdings könnte es durchaus sein, dass die Prüfung der Signatur noch irgendwie von Shim und nicht Grub vorgenommen wird, so könnte man IMO auch den Teil im Grub-Handbuch deuten:

https://www.gnu.org/software/grub/manual/grub/grub.html#UEFI-secure-boot-and-shim

LG, Newubunti

Newubunti schrieb:

[…] Wo liest Du eigentlich, dass sich der Patch nur auf Secure Boot Systeme auswirkt?

Das steht nirgendwo und so stimmt es ja auch nicht. Der "Security Patch" »[SECURITY PATCH 116/117] templates: Disable the os-prober by default« wirkt sich auf jede GRUB-Konfiguration aus, indem er den Komfort verringert. Aber durch eigenes Nachdenken kommt man darauf, dass nur im Kontext von "secure boot" damit überhaupt ein Gewinn an Sicherheit verbunden sein könnte, weil sich ja ohne Einsatz dieses Konzepts nichts an den Möglichkeiten ändert (bis auf eventuell weniger Komfort bei der Bedienung). Und auch im Kontext von "secure boot" ist kein konkreter Gewinn erkennbar, sondern alles bleibt im Abstrakten mit „könnte möglicherweise in abnormen Situationen“.

Wenn das Problem darin liegt, dass sich ein Risiko potentiell erhöht, wenn einfach ungefragt von os-prober gegebenenfalls neue Menü-Einträge erzeugt werden, so besteht dieses Problem bei Nicht-Secure-Boot-Systemen doch auch.

Nochmal:

1. os-prober ist ein harmloses Skript, welches auf dem lokalen Rechner aus einem laufenden Betriebssystem heraus mittels Heuristiken nach anderen Betriebssystemen sucht und diese lediglich meldet. (Soweit ich mich erinnere, benötigt es für einige seiner Heuristiken Root-Rechte, ab da mag ich mich täuschen.) Diese Skript wird niemals vom Bootmanager GRUB während des Startvorgangs benutzt. Selbst wenn dieses Skript manchmal mangelhaft arbeiten sollte (was ich nicht ausschließe, obwohl mir kein konkreter Fall bekannt ist), dann entsteht dadurch kein Sicherheitsrisiko.

2. Die Ergebnisse von os-prober benutzt ein Skript im Ordner /etc/grub.d/ des Wartungssystems von GRUB zur Erzeugung von Menüeinträgen im GRUB-Skript grub.cfg, aber niemals automatisch, sondern nur, wenn root den Befehl update-grub benutzt oder einen neuen Kernel installieren lässt und jedenfalls das durch Eingabe eines Passwortes autorisiert hat. Es passiert weder ungefragt und ein Eintrag im GRUB-Menü ist auch noch kein Sicherheitsrisiko.

3. Die Arbeitsweise dieses Skripts unter /etc/grub.d wird gesteuert durch die Variable in der Datei /etc/default/grub, deren Voreinstellung nun invertiert wurde und weiterer Variablen.

4. Am Verhalten von GRUB selbst beim Start ändert sich durch diesen Patch gar nichts. Wenn der Bediener ihm einen Kernel angibt durch Auswahl aus dem Menü oder per Kommandozeile, dann versucht GRUB diesen zu starten. Wenn nun GRUB tatsächlich es nicht schafft, diesen Kernel zu starten, weil er vielleicht nicht signiert ist und dieser konkrete GRUB nur signierte Kernel starten soll, dann war das vor diesem Patch auch schon so.

Wenn man die erschwerte Bedienung als Sicherheitsgewinn werten möchte, dann ist es bestenfalls "security through obscurity".

Aus Sicht der Grub-Entwickler mag dieser Patch sinnvoll sein, und wenn ich zu diesem Team gehören würde, hätte ich ihn auch (!) durchgeführt. Aber ich hätte ihn nicht als "security patch" bezeichnet.

Newubunti schrieb:

[…] Ergebnis: Fehlermeldung: Fehler: Falsche Shim-Signatur. Fehler: Sie müssen zuerst den Kernel laden

• Ist das eine Fehlermeldung von GRUB oder stammt das aus der initrd.img?

• Was meint „Shim-Signatur“? Ist das ein ungeschickt formulierter Text, der aber die beim Konzept "secure boot" verwendete EFI-Signatur meint, welche auf X509-Zertifikaten beruht? Oder ist hier ein anderes, vielleicht GRUB-spezifisches Signaturverfahren gemeint?

[…] Grub-Handbuch

Dem Grub-Handbuch für die Version 2.06 kann man immerhin entnehmen, dass GRUB verschiedene Varianten von "secure boot" unterstützt, diese (wie?) konfiguriert werden müssen und die teilweise auf PGP/GPG-Signaturen beruhen. Da bleibt für mich viel unklar, auch ob und wie vollständig das vom UEFI-Konsortium definierte "EFI secure boot" in GRUB 2.06 implementiert ist.

kB schrieb:

Selbst wenn dieses Skript manchmal mangelhaft arbeiten sollte (was ich nicht ausschließe, obwohl mir kein konkreter Fall bekannt ist)

Dem kann nachgeholfen werden. Diesen Fehler hatte ich 2016 gemeldet. Er führt dazu, dass die grub.cfg bei mehreren Ubuntu-Installationen nach ausführen von update-grub rekursiv immer länger wird und man hat dann unzählige GRUB-Menü-Einträge wie:

Ubuntu 16.04.1 LTS (16.04) (auf /dev/sda8) (auf /dev/sda5) (auf /dev/sda8)

kB schrieb:

Ja. In keinem Fall (weder vor nach nach dieser Änderung noch nach Rücknahme der neuen Voreinstellung und auch nicht, wenn Weihnachten auf den 30. Februar fällt) wird durch os-prober unautorisiert ein wie auch immer gearteter Menüeintrag dem GRUB-Menü hinzugefügt. Immer muss dazu ein Lauf von

sudo update-grub 

(oder Äquivalent) durchgeführt werden, und der Systemadministrator root sollte wissen, was er/sie will und tut.

Genau das meinte ich doch. Wenn der Benutzer dies ausführt, wird das System vom angesteckten USB-Medium in das GRUB-Bootmenü aufgenommen und kann beim nächsten Neustart gestartet werden. Ist der OS-Prober deaktiviert, kann das nicht passieren.

Und wenn man die Aktualisierungsverwaltung auf "automatisch" eingestellt hat, kann das auch unautorisiert passieren, denn jedes mal, wenn ein neuer Kernel installiert wird, wird auch die grub.cfg automatisch aktualisiert.

Eigentlich müsste man jetzt auch noch den Dualboot-Artikel und viele verwandte aktualisieren, denn so wie dort beschrieben wird das mit Windows nun nicht mehr funktionieren.

kB schrieb:

Bist Du Dir da ganz sicher? Das wäre mir nämlich neu, dass sich GRUB so verhält. Es widerspricht meiner Erfahrung; allerdings kann ich nicht ausschließen, dass dies tatsächlich inzwischen verbessert wurde und meine Erfahrung damit überholt wäre.

Ich glaube das aber nicht, weil:

• Wenn es sich so verhielte, wie Du schreibst, gibt es ja keine Motivation mehr für eine Änderung der Voreinstellung für os-prober mehr, denn ein von os-prober angelegter Menüeintrag ohne "secure boot" würde ja bei aktiviertem "secure boot" nicht funktionieren. Es wäre also bestenfalls ein kosmetisches Problem. Davon steht aber in der Patch-Ankündigung nichts.

Genau damit beschreibst Du doch genau die Sicherheitslücke (die mit der neuen Konfiguration verhindert werden soll). Diese wird hier so erklärt:

Das ermöglicht den gesicherten Anfang einer unterbrechungsfreien „Vertrauens-Kette“ von der Hardware-Firmware bis zur Benutzeranwendung. Es verhindert jedoch nicht, dass jedes Kettenglied auch „nicht-vertrauenswürdige“ Software laden kann. Beispielsweise existiert mit Shim ein von Microsoft signierter Bootloader, der einen nicht zertifizierten GRUB und über diesen beliebige andere Binaries nachladen kann.

UlfZibis schrieb: […]

Ich werde auf dieses Gestrüpp von Missverständnissen, Halbwahrheiten, unzulässigen Kombinationen nicht zusammen gehörender Sachverhalte und dergl. nicht weiter eingehen.

UlfZibis schrieb:

...Wenn der Benutzer dies ausführt, wird das System vom angesteckten USB-Medium in das GRUB-Bootmenü aufgenommen und kann beim nächsten Neustart gestartet werden. Ist der OS-Prober deaktiviert, kann das nicht passieren.

finde ich ziemlich "hergeholt", was soll es für einen Sinn machen, kurz vor einem update einen USB Stick mit installiertem Ubuntu - welches ja doch sinnvollerweise seinen eigenen Bootloader auf dem Stick mitbringt - anzustecken? (selbst wenn auf diese Weise ein Menüeintrag im internen Bootmanager erzeugt wird, ist der dann auch nur bei Anweseheit genau dieses Sticks nutzbar.

Eigentlich müsste man jetzt auch noch den Dualboot-Artikel und viele verwandte aktualisieren, denn so wie dort beschrieben wird das mit Windows nun nicht mehr funktionieren.

hä, diesen post 9313172 einschließlich enthaltenem Link hast Du aber schon gelesen?

kB schrieb:

Newubunti schrieb:

[…] Ergebnis: Fehlermeldung: Fehler: Falsche Shim-Signatur. Fehler: Sie müssen zuerst den Kernel laden

• Ist das eine Fehlermeldung von GRUB oder stammt das aus der initrd.img?

Da ich jetzt für diesen Test keine GRUB-Debug-Logs bemüht habe, kann ich es nicht zu 100% genau sagen. Grundsätzlich erscheinen beide Meldungen untereinander auf einem schwarzen Bildschirm. Darunter steht dann noch "Weiter mit beliebiger Taste". Was zurück in das Grub-Menü führt, welches aber auch nach Ablauf von einigen Sekunden selbständig wieder erscheint.

Ich würde behaupten, dass die erste Meldung "Falsche Shim-Signatur" GRUB/Shim zuzuordnen ist. Die zweite Meldung kommt IMO auch von der GRUB-Umgebung und erscheint z.B. auch, wenn man Starteinträge zu starten versucht, die auf ein Laufwerk verweisen, das für die GRUB-Umgebung zur Laufzeit nicht zugreifbar ist.

Aber wie gesagt, beides keine 100%-Aussagen, aber schon sehr wahrscheinlich.

• Was meint „Shim-Signatur“? Ist das ein ungeschickt formulierter Text, der aber die beim Konzept "secure boot" verwendete EFI-Signatur meint, welche auf X509-Zertifikaten beruht? Oder ist hier ein anderes, vielleicht GRUB-spezifisches Signaturverfahren gemeint?

"Shim-Signatur" meint hier eine EFI-Signatur auf Basis von X509-Zertifikaten. "Ungeschickt" formuliert ist das IMO aber nicht, weil es IMO eindeutig macht, dass Shim in Verbindung mit GRUB bzw. GRUB in Verbindung mit Shim hier gegen die "in Shim" ausgerollten Schlüssel mittels moktuil prüft.

Diese "Shim-Schlüssel" befinden sich ja nicht in der eigentlichen Schlüssel-Datenbank des UEFI. Daher finde ich die Unterscheidung hier zur Klarstellung schon sinnvoll.

Dem Grub-Handbuch für die Version 2.06 kann man immerhin entnehmen, dass GRUB verschiedene Varianten von "secure boot" unterstützt, diese (wie?) konfiguriert werden müssen und die teilweise auf PGP/GPG-Signaturen beruhen. Da bleibt für mich viel unklar, auch ob und wie vollständig das vom UEFI-Konsortium definierte "EFI secure boot" in GRUB 2.06 implementiert ist.

Also die Validierung von PGP-Signaturen bietet GRUB unabhängig von Secure Boot. Man kann aber beides kombinieren und wenn man es in Deinem Sinne von weiter oben vollständig unter eigenen Kontrolle bringen will, dann muss man AFAIK sogar beides kombinieren, z.B. braucht man die PGP-Signatur für initrd. Siehe im Grundsatz z.B.:

https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd

LG, Newubunti

EDIT:

Anhang hinzugefügt.

EDIT: Anhang hochladen gescheitert. 😬

EDIT: Ah, dann doch - merkwürdig.

Newubunti schrieb:

[…] Darunter steht dann noch "Weiter mit beliebiger Taste". Was zurück in das Grub-Menü führt, welches aber auch nach Ablauf von einigen Sekunden selbständig wieder erscheint.

Wenn man ohne Reboot zu GRUB zurück kommt, dann stammen die Fehlermeldungen von GRUB und/oder shim. Was ich dann erst einmal als Punkt für GRUB bewerte.

[…]

• Was meint „Shim-Signatur“? Ist das ein ungeschickt formulierter Text, der aber die beim Konzept "secure boot" verwendete EFI-Signatur meint, welche auf X509-Zertifikaten beruht? Oder ist hier ein anderes, vielleicht GRUB-spezifisches Signaturverfahren gemeint?

"Shim-Signatur" meint hier eine EFI-Signatur auf Basis von X509-Zertifikaten. "Ungeschickt" formuliert ist das IMO aber nicht, weil es IMO eindeutig macht, dass Shim in Verbindung mit GRUB bzw. GRUB in Verbindung mit Shim hier gegen die "in Shim" ausgerollten Schlüssel mittels moktuil prüft.

Diese "Shim-Schlüssel" befinden sich ja nicht in der eigentlichen Schlüssel-Datenbank des UEFI. Daher finde ich die Unterscheidung hier zur Klarstellung schon sinnvoll.

Mit andern Worten: GRUB/shim machen hier nicht genau das, was UEFI-secure-boot meint. Vielleicht etwas gleich gutes, vielleicht etwas kompatibles, auf jeden Fall etwas anderes. Was nicht unbedingt gegen GRUB sprechen muss, aber momentan unklar ist.

[…] Also die Validierung von PGP-Signaturen bietet GRUB unabhängig von Secure Boot. Man kann aber beides kombinieren und wenn man es in Deinem Sinne von weiter oben vollständig unter eigenen Kontrolle bringen will, dann muss man AFAIK sogar beides kombinieren, z.B. braucht man die PGP-Signatur für initrd

Was dann doch wieder meine Befürchtung nährt, es könnte noch viel schlimmer als in meinen Alpträumen sein!

kB schrieb:

1. Die Ergebnisse von os-prober benutzt ein Skript im Ordner /etc/grub.d/ des Wartungssystems von GRUB zur Erzeugung von Menüeinträgen im GRUB-Skript grub.cfg, aber niemals automatisch, sondern nur, wenn root den Befehl update-grub benutzt oder einen neuen Kernel installieren lässt und jedenfalls das durch Eingabe eines Passwortes autorisiert hat. Es passiert weder ungefragt und ein Eintrag im GRUB-Menü ist auch noch kein Sicherheitsrisiko.

1. Es passiert im Rahmen eines Kernel-Update bei Nutzung sehr wohl ungefragt in dem Sinne, dass der Nutzer - und Nutzer schließt hier auch Laien ein - nicht ausdrücklich darüber informiert und auch nicht gefragt wird, dass im Rahmen von Kernel-Updates os-prober nach Betriebssystemen auf allen mountbaren Partition suchen und diese dann gegebenenfalls - ebenfalls ohne weiteres Nachfragen - dem Grub-Menü einfach hinzufügen wird. Gefragt wird nur allgemein zur Autorisierung von Sicherheitsupdates. Hinzu kommt, dass

   • sich nicht automatisch für jeden Nutzer aus sich selbst heraus erklärt, dass bei Sicherheitsaktualliesierung und insbesondere Kernelupdates gegebenenfalls neue Grub-Menü-Einträge erstellt werden

   • es eben auch eigentlich keine zwingende technische Notwendigkeit gibt, im Rahmen von Kernel-Updates stets nach Betriebssystemen zu suchen.

2. Es behauptet überhaupt niemand hier im Thread und vor allem auch nicht das Team von Grub, dass bereits der Hinzufüge-Vorgang an sich direkt unmittelbar das Sicherheitsproblem auslöst, sondern es heißt: " what may lead to potentially dangerous use cases and borderline opening attack vectors." d.h. IMO, dass Angriffsvektoren begünstigt werden. Und das stimmt IMO vor allem auch deswegen, weil ein Angreifer ohne Root-Rechte so unter Umständen einen Grub-Menü-Eintrag verursachen kann, indem er einfach auf einer mit Nutzer-Rechten beschreibbaren Partition sein vorbereitetes System ablegt. Aufgrund des stupiden Ablaufs von os-prober bei jedem Kenrel-Update, wird nämlich für sein Schadsystem früher oder später ein Starteintrag im Grub-Menü erzeugt werden, der dann bewusst oder versehentlich angewählt werden kann. Kommt nun eine Sicherheitslücke hinzu, die das eigentliche Prüfen der Kernelsignatur aushebelt, dann ist damit ein Angriffsvektor geschaffen - ohne dass der Angreifer über Root-Rechte verfügen muss, was normalerweise zum Erzeugen eines Menü-Eintrags notwendig wäre, wenn os-prober nicht automatisch bei jedem Kerenl-Update laufen würde. Ich würde dem schon eine Erhöhung des Sicherheitsrisikos beimessen und dies auch als Sicherheits-relevant bezeichnen.

Wenn man die erschwerte Bedienung als Sicherheitsgewinn werten möchte, dann ist es bestenfalls "security through obscurity".

1. Geht es IMO bei Sicherheit immer um das Schaffen von "erschwerten Bedingungen", andernfalls würde man Sicherheit absolut herstellen können (müssen), was wohl in den aller wenigsten Fällen der Fall sein dürfte.

2. Wird hier nun ein Verhalten abgestellt, dass IMO in erster Linie so - also in seinem jetzigen Umfang - technisch gar nicht zwingend notwendig ist. Wie ich oben schrieb, ist es nicht notwendig, dass bei jedem Kernel-Update auch nach Betriebssystemen gesucht wird. Es wäre stattdessen ausreichend, wenn einfach die vorhanden Einträge im Grub-Menü ein Update erfahren ohne dass gegebenenfalls neue Einträge erzeugt werden. Neu Einträge sollten IMO nur auf ausdrücklichen Anweisung des Nutzers erstellt werden. Dadurch würde sich kein großer Komfortverlust ergeben. Und alles was einerseits nicht technisch zwingend erforderlich und auf der anderen Seite eine Erhöhung eines Sicherheitsrisikos darstellt - wenn vielleicht auch nur eine mittelbare - sollte IMO im Sinne eine sicheren System-Designs vermieden werden. Und das Vermeiden von unnötigen Sicherheitsrisiken ist IMO nicht "security through obscurity" sondern die Umsetzung einer vernünftigen Sicherheitsstruktur.

Deine Auffassung, dass sich durch das automatische Hinzufügen eines Menü-Eintrages zum Grub-Menü (meint hier jetzt nicht den Vorgang an sich, sondern das dadurch hervorgerufene Resultat) keinerlei Erhöhung des Sicherheits-Risikos ergeben soll, ist für mich daher nicht nachvollziehbar.

Richtig ist - und das hat soweit bis jetzt auch niemand bestritten - dass sich daraus kein absolutes Sicherheitsrisiko mit "fester Gradzahl" ergibt, sondern eine unbestimmte Risikoerhöhung in Abhängigkeit von sonstigen Umständen.

Das ist aber nicht in jedem Fall das gleiche, wie "kein Sicherheitsrisiko".

LG, Newubunti

Newubunti schrieb: […]

Ich bin sehr erstaunt, wie man sich über diesen (aus meiner Sicht völlig harmlosen) os-prober so ereifern kann!

Wer einen Rechner mit mehreren Betriebssystemen haben möchte, was nicht selten der Fall ist, der hat bereits das grundsätzliche Sicherheitsrisiko akzeptiert, welches automatisch durch die Anwesenheit von mehr als einem Betriebssystem entsteht: Jedes Betriebssystem kann ja auf die Datenbestände des anderen an diesem anderen vorbei zugreifen und diese ändern oder sogar eines der andern Betriebssysteme beschädigen. Das nimmt man aber in Kauf oder es ist – z.B. für Reparaturen – sogar erwünscht.

In dieser Situation mehrerer möglicher Betriebssysteme benötigt man beim Hochlauf eine Auswahlmöglichkeit. Diese realisiert GRUB mit seinem Menü und zur automatischen Erstellung der Menüeinträge wurde bei einem früheren Gebrauch des Rechners os-prober verwendet. Ohne solche Menüeinträge wäre der Rechner nicht sicherer, denn man kann die Betriebssysteme genau so gut, lediglich weniger komfortabel, auch händisch starten. Die Menüeinträge sind reiner Komfort und ändern nichts am Sicherheitsniveau des Systems.

Wenn man nun doch glaubt, dass man durch Verzicht auf die Menüeinträge das System sicherer machen könnte, steht man vor der Frage, wozu man eigentlich GRUB benötigt. Der Daseinszweck von GRUB besteht alleine in der Präsentation dieses Menüs, denn ein Betriebssystem starten kann man ja auch ohne GRUB. Wer also GRUB durch Verzicht auf das mit Hilfe von os-prober erstellte Menü sicherer machen möchte, kann einen wesentlich größeren Gewinn an Sicherheit durch den kompletten Verzicht auf GRUB verwirklichen. (Was ich persönlich in der Tat auch so bevorzugt mache.)

Für die große Masse der von Laien benutzten Desktop-Systemen ist das Konzept "secure boot" nicht erforderlich, und bei diesen vereinfacht GRUB mit seinem Menü die Bedienung bei Multi-Boot-Systemen und die von os-prober automatisch erzeugten Menüeinträge verschlechtern in keiner Weise deren Sicherheit.

os-prober: Ja oder Nein? Diese Frage mag jeder für sich so oder anders beantworten. Wer aber glaubt, die Antwort hätte irgend etwas mit Sicherheit zu tun, der irrt. Wer ein System mit "secure boot" haben will, lässt GRUB am besten weg und hat dann weniger Probleme. Ohne GRUB ist aber die Frage nach os-prober völlig sinnlos.

kB schrieb:

Ich bin sehr erstaunt, wie man sich über diesen (aus meiner Sicht völlig harmlosen) os-prober so ereifern kann!

In der Tat! Die Diskutanten hegen das hehre Ziel, die Leser des Wiki-Artikels nicht nur mit richtigen, sondern auch im Einzelfall entscheidungsrelevanten Informationen zu erfreuen. Hierfür ist wohl ein tieferes Verständnis der grundlegenden Funktion vonnöten, welches hier gerade gemeinsam erarbeitet wird.

Auf der Basis, dass man Ubuntu auch ohne GRUB starten kann, kann ich Deinen weiteren Ausführungen voll und ganz folgen. Kannst Du denn mal grob skizzieren, wie das geht? Was steht dann im EFI-NVRAM als Starteintrag?

UlfZibis schrieb:

[…] Ubuntu auch ohne GRUB starten […] Kannst Du denn mal grob skizzieren, wie das geht?

Kann ich zwar, werde ich aber hier nicht tun, weil eine solche sachfremde Thematik nicht in diesen Thread gehört. Dies ist die Diskussion zum Wiki-Artikel „wie man technisch GRUB über dessen Wartungssystem konfiguriert“. Bereits die Frage, ob bestimmte Werte für eine Konfigurationsvariable für die Sicherheit des Systems relevant sein könnten, steht bestenfalls grenzwertig zum Thema des Artikels.

kB schrieb:

Newubunti schrieb: […]

Ich bin sehr erstaunt, wie man sich über diesen (aus meiner Sicht völlig harmlosen) os-prober so ereifern kann!

Ich ereifere mich nicht über os-prober, ich habe mir erlaubt darauf hinzuweisen, dass die Grub-Entwickler den Patch, der os-prober aktuelle deaktiviert, als Sicherheitsrelevant einstufen:

https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00120.html

https://lists.gnu.org/archive/html/grub-devel/2021-03/msg00007.html

Und dabei hatte ich eigentlich nach tatsächlichen oder möglichen Angriffsvektoren gefragt.

D.h. die Frage ob sicherheitsrelevant oder nicht, steht für mich hier gar nicht zur Debatte, sondern nur die Frage, wie man das vernünftig darstellt ohne den Leser zu verunsichern.

Wenn man nun doch glaubt, dass man durch Verzicht auf die Menüeinträge das System sicherer machen könnte, steht man vor der Frage, wozu man eigentlich GRUB benötigt.

Du diskutierst an meinem Argument vorbei. Ich oder die Grubentwickler behaupten nicht, dass das System sicherer wird, wenn es gar keine Grub-Menü-Einträge gäbe, sondern ich habe argumentiert, dass Art und Weise von os-prober dazu führen können, dass unter Umständen auch Menü-Einträge erstellt werden, die ich als Nutzer eigentlich gar nicht haben will.

Der Daseinszweck von GRUB besteht alleine in der Präsentation dieses Menüs, denn ein Betriebssystem starten kann man ja auch ohne GRUB.

Der Laie ist also nach Deiner Auffassung in der Lage, aus Versehen ein System über die GRUB-Shell zu starten, von dessen Existenz er gar nichts weiß? Umgekehrt soll gar kein erhöhtes Risiko bestehen, dass der Laie einen Eintrag für ein Schadsystem aus Versehen auswählt, der im Grub-Menü existent ist, weil os-prober ihn im Rahmen eines Kernel-Updates dort automatisch hin befördert hat?

Das ist und bleibt für mich nicht nachvollziehbar.

Wer also GRUB durch Verzicht auf das mit Hilfe von os-prober erstellte Menü sicherer machen möchte, kann einen wesentlich größeren Gewinn an Sicherheit durch den kompletten Verzicht auf GRUB verwirklichen. (Was ich persönlich in der Tat auch so bevorzugt mache.)

Hier sind wir uns wiederum grundsätzlich einig. In der Tat halte ich auf ordentlich funktionierenden UEFI-Systemen einen ausgewachsenen Boot-Manger wie Grub eigentlich für oversized und damit potentiell das System gefährdend.

Allerdings: Wir sind hier im Ubuntu-Wiki und bei Ubuntu ist Grub nun mal derzeit der standardmäßige Bootmanager. Und der Austausch des Bootmanagers ist auch nichts, was ich als für den Laien trivial bezeichnen würde.

UlfZibis schrieb:

kB schrieb:

Ich bin sehr erstaunt, wie man sich über diesen (aus meiner Sicht völlig harmlosen) os-prober so ereifern kann!

In der Tat! Die Diskutanten hegen das hehre Ziel, die Leser des Wiki-Artikels nicht nur mit richtigen, sondern auch im Einzelfall entscheidungsrelevanten Informationen zu erfreuen.

Wo habe ich das behauptet? Die Diskussion hier ist das eine, was in den Artikel kommt, kann dann etwas ganz anderes sein.

Wie ich schon einmal schrieb:

Newubunti schrieb:

UlfZibis schrieb:

Dies im Wikiartikel ausführlich nachvollziehbar zu erklären, halte ich allerdings für überzogen.

Die Frage diente auch erst mal nur meinem eigenen Verständnis, um dann abschätzen zu können ob und wie weit das im Wiki erwähnt werden sollte.

Und ich hätte bei meiner ursprünglichen Anmerkung im übrigen auch nicht erwartet, dass man die Sicherheitsrelevanz des Patches vollständig in Frage stellt.

LG, Newubunti