ubuntuusers.de

noisefloor schrieb:

[…] da immer noch "auf DVD brennen" referenziert wird: welche *buntu Images passen denn wirklich noch auf eine DVD? Ubuntu 22.04 und neuer jedenfalls nicht.

Hinweis DVD-Rohling ergänzt.

noisefloor schrieb:

Unter welchen Umständen muss man den SecureBoot deaktivieren?
Das ist im Artikel ziemlich unspezifisch.

Ist doch verlinkt und hier EFI Grundlagen (Abschnitt „Secure-Boot“) beschrieben bzw spezifiziert.

... Ubuntu hat doch auch einen signierten Kernel.

darum steht da ja auch "gegebenenfalls".

Das Einschraenkungen-bei-Verwendung-von-Secure-Boot hat mich bewogen, es noch , wie geschrieben mit "gegebenenfalls", im Wiki zu belassen.

Nach meiner Erfahrung / ...

Mit Erfahrung kann ich leider nicht dienen, ich besitze nur zwei PC. 😢

Berlin_1946 schrieb:

noisefloor schrieb:

Unter welchen Umständen muss man den SecureBoot deaktivieren?

Man muss nach meiner Meinung und praktischen Erfahrung Secure Boot zur Nutzung des Live-Mediums nicht deaktivieren, solange es keinen diesbezüglichen Hinweis gibt. Ein solcher könnte in Form einer von Secure Boot angezeigten Fehlermeldung vorkommen, wenn mal der Fall eintritt, dass Signaturen von Canonical für Shim aufgrund von Sicherheitslücken in Shim oder GRUB auf die Secure Boot Blacklist gelangen und man ein Live-Medium mit noch nicht aktualisierten Signaturen verwendet.

D.h. da müssen erst mal einige Dinge zusammen kommen, wie z.B. bei BootHole 🇬🇧 und dann besteht ein solches Problem nur temporär.

Ist doch verlinkt und hier EFI Grundlagen (Abschnitt „Secure-Boot“) beschrieben bzw spezifiziert.

Die Information dort ist in der Form einfach nur falsch und vor allem auch nicht mehr zeitgemäß.

Das Einschraenkungen-bei-Verwendung-von-Secure-Boot hat mich bewogen, es noch , wie geschrieben mit "gegebenenfalls", im Wiki zu belassen.

Diese Einschränkung wird ja überhaupt erst interessant, falls man mehrere *buntus nebeneinander installiert und dann noch zusätzlich darauf besteht, dass jedes Ubuntu einen eigenen GRUB verwendet bzw. wenn man sich daran stört, dass der verwendete GRUB unter Umständen wechselt.

Das ist aber für die Verwendung des Live-Mediums völlig irrelevant.

LG, Newubunti

Hallo Newubunti ,

wenn ich dich richtig verstehe, kann der Teil
Bei UEFI-Computern, auf welchen SecureBoot aktiviert ist, muss dieses gegebenenfalls kurzzeitig deaktiviert werden.

ersatzlos entfernt werden.

• ein Link: einfach nur falsch # da bist zu ja noch am bearbeiten (Geplante Fertigstellung: 31.3.2024) 😎

• der Andere: falls man mehrere *buntus nebeneinander installiert

Der vorgenannte gesonderte Fall wird hier nicht beschrieben.

Berlin_1946 schrieb:

... wenn ich dich richtig verstehe, kann der Teil
Bei UEFI-Computern, auf welchen SecureBoot aktiviert ist, muss dieses gegebenenfalls kurzzeitig deaktiviert werden.

ersatzlos entfernt werden.

Ja, genau. Ich würde das ersatzlos aus diesem Artikel streichen.

LG, Newubunti

noisefloor schrieb:

[…] Unter welchen Umständen muss man den SecureBoot deaktivieren? Das ist im Artikel ziemlich unspezifisch. Nach meiner Erfahrung / IMHO muss man das nicht, Ubuntu hat doch auch einen signierten Kernel.

SecureBoot soll den Start eines fremden Betriebssystems verhindern. Was als „fremd“ gilt ist individuell für den einzelnen Rechner und dementsprechend muss SecureBoot auch individuell konfiguriert werden, wenn man es für den vorgesehenen Zweck einsetzen möchte. Wer es freizügiger verwenden möchte, verfehlt den Zweck und kann SecureBoot besser ganz abschalten.

Der Start eines Betriebssystems von einem transportablen Medium erfüllt aber in jedem Fall das Kriterium des fremden Betriebssystems. Ein korrekt konfiguriertes SecureBoot muss so etwas verhindern oder ist selbst sinnlos.

Folglich:

• Wer den Rechner per Desktop-Live-Medium starten möchte, muss vorher ein korrekt konfiguriertes SecureBoot immer deaktivieren.

• Wenn ein Rechner per Desktop-Live-System starten kann, obwohl SecureBoot noch eingeschaltet ist, dann hat der Administrator des Rechner dessen SecureBoot nicht nicht korrekt konfiguriert.

Der Satz

Bei UEFI-Computern, auf welchen SecureBoot aktiviert ist, muss dieses gegebenenfalls kurzzeitig deaktiviert werden.

ist also goldrichtig.

kB schrieb:

Der Satz Bei UEFI-Computern, auf welchen SecureBoot aktiviert ist, muss dieses gegebenenfalls kurzzeitig deaktiviert werden.

ist also goldrichtig.

Ist wieder eingebaut.

Ich meine: er schadet ja nicht. Vllt kann Newubunti die beiden Wiki aktualisieren bzw. berichtigen.

kB schrieb:

SecureBoot soll den Start eines fremden Betriebssystems verhindern. Was als „fremd“ gilt ist individuell für den einzelnen Rechner und dementsprechend muss SecureBoot auch individuell konfiguriert werden, wenn man es für den vorgesehenen Zweck einsetzen möchte. Wer es freizügiger verwenden möchte, verfehlt den Zweck und kann SecureBoot besser ganz abschalten.

Der Start eines Betriebssystems von einem transportablen Medium erfüllt aber in jedem Fall das Kriterium des fremden Betriebssystems. Ein korrekt konfiguriertes SecureBoot muss so etwas verhindern oder ist selbst sinnlos.

Ähm,

Hallo in die Runde.

Newubunti schrieb:

den Satz verstehe ich vllt falsch:

... in der Regel in der Secure Datenbank des Rechners hinterlegt

Wie ist es bei EFI-Rechner, die vor den 8 Jahren gebaut wurden und der dortigen Datenbank?
Sind es die, die Secure-Boot abschalten müssen?

Hilft das?

mate@mate-HP-ProDesk:~$ sudo mokutil --sb-state 
[sudo] Passwort für mate: 
SecureBoot disabled
mate@mate-HP-ProDesk:~$ 

Oder macht es dieses Wiki damit zu kompliziert?

Berlin_1946 schrieb:

Oder macht es dieses Wiki damit zu kompliziert?

Ich meine man sollte sich für den Artikel Desktop-Live-Medium eher darauf konzentrieren, wie man es startet. Da dürfte für Otto-Normal-Anwender die größere Hürde liegen als bei Secure Boot, weil bei EFI-Systemen in aller Regel beim Start immer wieder das installierte Betriebssystem startet und die Zeit zum Drücken einer Taste für das Firmware-Bootmenü verschwindend gering ist. Dafür habe ich ja Howto/Aufruf des Startmenüs und Firmware-Setups angelegt.

Rechner die für ab Windows 8 für Windows zertifiziert und mit Windows vorinstalliert wurden, haben das Microsoft Corporation Third Party Marketplace Zertifikat vorinstalliert. Für Ubuntu ist nur entscheidend, ab welcher Ubuntu-Version Shim eben mit diesem Zertifikat signiert ausgeliefert wurde. Und das ist jetzt schon eine kleine Ewigkeit so.

Alte Rechner die kein Secure Boot können sind ja kein Problem.

Für den Betrieb des Live-Mediums schaltet man Secure Boot dann ab,

1. wenn man bei der Auswahl oder beim Start von dem Medium eine Fehlermeldung erhält, der auf Secure Boot zurückzuführen ist - das dürft praktisch eher weniger oft vorkommen.

2. wenn man weiß und verstanden hat, warum man es abschaltet - dann ist man über den Horizont dieses Artikels aber mit hoher Wahrscheinlichkeit hinaus

Ich würde das zunächst mal gar nicht in das Wiki aufnehmen, solange es aktuell nicht eine ausreichende Anzahl von Fällen gibt, bei denen der Betrieb des Live-Mediums am aktiven Secure Boot scheitert.

LG, Newubunti

Hallo,

SecureBoot soll den Start eines fremden Betriebssystems verhindern.

Der Satz ist per se doch Unfug. Wenn der Computer neu vom Band läuft ist _jedes_ Betriebssystem fremd, inkl. Windows. Bei SecureBoot wird "nur" der Bootloader verifiziert, siehe Ausführungen von Newubunti. Microsoft ist halt #ausründen die zentrale Schlüsselstelle. Die meisten (AFAIK alle?) Mainstream Linux Distros verwenden den genannten Shim, damit nicht jede Distro einzeln signiert werden muss. AFAIK wird der Shim von RedHat verwaltet / entwickelt und Ubuntu, Debian, Suse etc. nutzen den mit.

Wie ist es bei EFI-Rechner, die vor den 8 Jahren gebaut wurden und der dortigen Datenbank? Sind es die, die Secure-Boot abschalten müssen?

Probier's aus. Es ist ja nicht so, dass das nicht updatebar wäre.

Gruß, noisefloor

noisefloor schrieb:

Probier's aus. Es ist ja nicht so, dass das nicht updatebar wäre.

Sry. Hilf jetzt nicht so wirklich beim Bearbeiten des Wiki: 😇

Bei UEFI-Computern, auf welchen SecureBoot aktiviert ist, muss dieses gegebenenfalls kurzzeitig deaktiviert werden.

Stand der Diskusion (wie ich es auslege)

• kB lassen

• Newubunti raus

• noisefloor raus

• Berlin_1946 lassen

mein Argument: gegebenenfalls kurzzeitig deaktiviert

Will sagen: wenn's gut durchläuft ... wenn nicht - mal versuchen.

Berlin_1946 schrieb:

mein Argument: gegebenenfalls kurzzeitig deaktiviert

Wie oft im Monat/Jahr kommt es denn im Supportforum vor, dass der Start des Live-Mediums explizit am aktiven Secure Boot eines Rechner scheitert?

LG, Newubunti

Hallo,

der Mythos de "Secure Boot muss man deaktivieren" stimmt IMO noch aus der Anfangszeit des SecureBoot, wo die ganzen Linux Distro halt noch keine signierten Bootloader hatten bzw. noch selber signieren lassen haben, weil die Technologie mit dem Shim noch nicht da war.

Ich würde sagen: es gibt nur einen Grund, Secure Boot zu deaktivieren: nämlich wenn der Rechner den Boot des Ubuntu USB-Sticks verweigert, weil das BIOS den signierten Bootloader nicht akzeptiert. Und dann würde ich mich aber vorher fragen: warum? Ist mein Image kaputt oder hat das warum auch immer einen falsch signierten Bootloader?

Gruß, noisefloor

noisefloor schrieb:

[…]

SecureBoot soll den Start eines fremden Betriebssystems verhindern.

Der Satz ist per se doch Unfug.

Ich schrieb über den Sinn (Intention) einer Technik, nicht über deren Implementierung. Abgesehen von marktschreierischen Protestrufen ohne Begründungen habe ich noch kein Argument von Euch gelesen, warum denn meine Ansicht über den Sinn von SecureBoot nicht richtig sein soll und auch nichts darüber, was denn sonst der Sinn dieser Maßnahme sein könnte.

Die Ausführungen von Newubunti sind zwar inhaltlich zutreffend, gehen aber nicht auf den Sinn ein und sind daher hier irrelevant.

Ich bleibe bei meiner Darstellung. In den meisten in freier Wildbahn aufzufindenden Rechnern wurde allerdings SecureBoot nicht dessen Intention entsprechend konfiguriert bzw. es wurde gar nicht konfiguriert, sondern läuft mit einer Voreinstellung. Da es in dieser leider gar nicht seiner Intention entsprechend betrieben wird, muss man es in der Praxis auch nicht ausschalten. Das liegt aber an mangelnder Intension der Administratoren, die womöglich die Intention von SecureBoot gar nicht kennen.

Es reicht eben nicht aus, zu wissen, wie etwas funktioniert. Man muss auch wissen, was es leisten soll. Ohne Kenntnis des Ziels kann man es nicht richtig konfigurieren.