staging.inyokaproject.org

black_tencate schrieb:

Hej Newubunti,

*thumup*

Danke, für die Rückmeldung!

Btw., das

VISUAL=gedit sudoedit /etc/…

ist ja nicht meins, mir reicht ein sudoedit (das funktioniert in jedem Flavor, ansonsten müßte ich immer erst suchen, wie denn jeweils der Texteditor heißt)

Habe ich deshalb gewählt, weil da direkt die Zeilennummern eingeschaltet sind. Für nano hätte ich es noch mitgeben können, für alles andere hätte ich suchen müssen.

EDIT.: Achso, wäre das evt. etwas für grub 2 an geeigneter Stelle?

Da mache ich mir gerade noch Gedanken drüber, wo man das platziert. Hier zusätzlich wird es mir dann auch zu lang, obwohl auch nicht völlig unpassend. Der Skripte-Artikel wäre auch noch eine Möglichkeit, aber der ist auch schon lang. Vielleicht auch als eigener Unterartikel von Skripte. Da gäbe es viele Möglichkeiten.

Es sollte auch nicht zu zerklüftet sein. Dann ist es zwar leichter pfleg- aber auch schwerer lesbar.

Mal sehen. Vorschläge willkommen!

LG, Newubunti

Hej Newubunti,

OT
Newubunti schrieb:

...

Btw., das

VISUAL=gedit sudoedit /etc/…

ist ja nicht meins, mir reicht ein sudoedit (das funktioniert in jedem Flavor, ansonsten müßte ich immer erst suchen, wie denn jeweils der Texteditor heißt)

Habe ich deshalb gewählt, weil da direkt die Zeilennummern eingeschaltet sind. Für nano hätte ich es noch mitgeben können, für alles andere hätte ich suchen müssen.

nunja, sudoedit kennt ^W, damit findet man auch Strings wie menuentry '$(echo "$OS $onstr", oder ^/ Sprung zu Zeile… /OT

Gruß black tencate

Hej,

ich warte noch immer auf das Verschieben (es ist doch hier soweit fertig, oder?).

Newubunti schrieb:

... Mal sehen. Vorschläge willkommen!

ich würde dann nämlich dieses Sonderverhalten (Manipulieren der os-prober) in Mehrbootsystem mit 2x Ubuntu einbauen.

Gruß black tencate

black_tencate schrieb:

Hej,

ich warte noch immer auf das Verschieben (es ist doch hier soweit fertig, oder?).

1+

ich würde dann nämlich dieses Sonderverhalten (Manipulieren der os-prober) in Mehrbootsystem mit 2x Ubuntu einbauen.

1+

Es sieht so aus, dass durch die Manipulation von GRUB_DISTIBUTOR auch noch ein anderer Bootloader – grubx64.efi anstatt shimx64.efi – installiert wird, was ggf. zu klären wäre. Das ergibt sich aus diesem Zusammenhang (letzte 2 Sätze).

UlfZibis schrieb:

Es sieht so aus, dass [...]

wo Du bloß immer Deine Informationen hernimmst

test@test-VB:~$ sudo ls -R /boot/efi/efi
[sudo] Passwort für test: 
/boot/efi/efi:
BOOT  ubuntu

/boot/efi/efi/BOOT:
BOOTX64.EFI  fbx64.efi	mmx64.efi

/boot/efi/efi/ubuntu:
BOOTX64.CSV  grub.cfg  grubx64.efi  mmx64.efi  shimx64.efi
test@test-VB:~$ 

black_tencate schrieb:

wo Du bloß immer Deine Informationen hernimmst

Zugegeben missdeutbar formuliert. Mit "installiert" meinte ich die "Installation" im NVRAM-Eintrag. In Deinen Custom-Einträgen steht da jedenfalls jetzt grubx64.efi anstatt shimx64.efi. Und was bei Dir in /boot/efi/efi/jellyfish-secure/ und .../jellyfish-mate tatsächlich installiert wurde, hast Du ja "nicht verraten".

black_tencate schrieb:

Hej Newubunti,

*thumup*

Ist denn diese Alternative dann noch aktuell?

UlfZibis schrieb:

Ist denn diese Alternative dann noch aktuell?

Das ist immer noch aktuell und sorgt z.B. dafür, dass das GRUB-Menü in Schwarz/Hellgrau statt wie bei Debian mit blau/weiß angezeigt wird, wenn man die Variable GRUB_DISTRIBUTOR anpasst.

UlfZibis schrieb:

Zugegeben missdeutbar formuliert. Mit "installiert" meinte ich die "Installation" im NVRAM-Eintrag. In Deinen Custom-Einträgen steht da jedenfalls jetzt grubx64.efi anstatt shimx64.efi. Und was bei Dir in /boot/efi/efi/jellyfish-secure/ und .../jellyfish-mate tatsächlich installiert wurde, hast Du ja "nicht verraten".

Es steht doch im Artikel ausdrücklich drin, dass man kontrollieren soll, dass sich der NVRAM-Eintrag von shimx64.efi auf grubx64.efi ändert. Man könnte noch reinschreiben, die shimx64.efi in einem solchen Fall zu löschen und eben auch den alten NVRAM-Eintrag, der auf diese zeigt.

LG, Newubunti

Newubunti schrieb:

Es steht doch im Artikel ausdrücklich drin, dass man kontrollieren soll, dass sich der NVRAM-Eintrag von shimx64.efi auf grubx64.efi ändert. Man könnte noch reinschreiben, die shimx64.efi in einem solchen Fall zu löschen und eben auch den alten NVRAM-Eintrag, der auf diese zeigt.

Och Mist, ich muss zugeben, in dem Fall nicht genau recherchiert zu haben. Ändert sich das denn schon aufgrund der GRUB_DISTRIBUTOR-Manipulation, oder erst, nach dem Wechsel vom signierten zum unsignierten GRUB?
In der Achtung-Box steht ja, dass shim-signed für die Verwendung von Secure-Boot essentiell sei, aber black_tencate verwendet für sein jellyfish-secure grub-efi-amd64. Meiner Erfahrung nach reicht für Secure-Boot grub-efi-amd64-signed völlig aus und Shim kann immer weg, ist genau genommen sogar ein Sicherheitsrisiko ⇒

Beispielsweise existiert mit Shim ein von Microsoft signierter Bootloader, der einen nicht zertifizierten GRUB und über diesen beliebige andere Binaries nachladen kann.

UlfZibis schrieb:

... Ändert sich das denn schon aufgrund der GRUB_DISTRIBUTOR-Manipulation, oder erst, nach dem Wechsel vom signierten zum unsignierten GRUB?

Der NVRAM-Eintrag ändert sich erst von shimx64.efi auf grubx64.efi nach dem das Paket shim-signed deinstalliert wurde.

In der Achtung-Box steht ja, dass shim-signed für die Verwendung von Secure-Boot essentiell sei,

... Meiner Erfahrung nach reicht für Secure-Boot grub-efi-amd64-signed völlig aus und Shim kann immer weg, ist genau genommen sogar ein Sicherheitsrisiko ⇒

Beispielsweise existiert mit Shim ein von Microsoft signierter Bootloader, der einen nicht zertifizierten GRUB und über diesen beliebige andere Binaries nachladen kann.

Also sofern bei Dir,

1. Secure Boot auf dem System aktiviert ist

2. Du keine eigenen Zertifikate im Speicher des NVRAM abgelegt hast und dort nur die von Microsoft und gegebenenfalls die Deines Systemherstellers abgelegt sind

- was auf die allermeisten Systeme so erst mal zutrifft - startet Dein System nicht ohne Shim.

• Das Paket grub-efi-amd64-signed enthält die grubx64.efi.signed, diese ist von Canonical signiert.

• Das Paket shim-signed enthält die shimx64.signed und diese ist von Microsoft signiert.

Hast Du das öffentliche Zertifikat von Canoncial im NVRAM hinterlegt, was Du selbst gemacht haben müsstest und nicht die Regel ist, nur dann würde Dir das Paket grub-efi-amd64-signed ausreichen.

Über shim-signed wird dir Brücke zwischen dem Microsoft-Third-Party-Zeritfikat und dem Canonical-Zeritifikat mit dem der eigentliche GRUB signiert ist geschlagen. Shim enthält das öffentliche Canonical-Zertifikat, dass Deinem NVRAM standardmäßig fehlt und prüft die grubx64.efi vor deren Ausführung gegen das Canonical-Zertifikat.

Dass Shim ein Sicherheitsrisiko ist, sehe ich so wie von Dir beschrieben nicht. Das Sicherheitsrisiko ist hier eher GRUB 2, der z.B. die unter Debian-basierten Distributionen die intrd nicht gegen Secure Boot prüft. GRUB bietet hier nur den Weg, die intrd über PGP-Signaturen zu prüfen, was Du aber auch selbst einrichten und warten müsstest.

Shim lädt nicht einfach beliebige Binaries. In der Regel lädt der genau den Distributions-spezifischen und vom Distributor signierten Boot-Loader und sonst gar nichts.

LG, Newubunti

Etliche Typos beseitigt, bin aber wegen der Länge des Textes damit noch nicht fertig.

Unschön empfinde ich die Überschriften 4. Ordnung. Vielleicht könnte man aus Abschnitt 2.5 besser 3 machen?

Die Besonderheiten zu GRUB_DISTRIBUTOR könnte man – auch wegen deren Bedeutung für andere Artikel – in einen eigenen Artikel auslagern.

kB schrieb:

Vielleicht könnte man aus Abschnitt 2.5 besser 3 machen?

Ja, das hatte ich auch schon überlegt und ist ja im Prinzip problemlos möglich.

Die Besonderheiten zu GRUB_DISTRIBUTOR könnte man – auch wegen deren Bedeutung für andere Artikel – in einen eigenen Artikel auslagern.

Da bin ich noch am überlegen, ob es dafür einen eigenständigen Artikel braucht, das wäre dann wohl auch eher ein HowTo.

LG, Newubunti

Herzlichen Dank für Deine detaillierten Aufführungen. Macht Freude zu lesen!

Newubunti schrieb:

Hast Du das öffentliche Zertifikat von Canoncial im NVRAM hinterlegt, was Du selbst gemacht haben müsstest und nicht die Regel ist, nur dann würde Dir das Paket grub-efi-amd64-signed ausreichen.

Ich kann da nur auf die Erfahrung mit meinem ASUS Netbook zurückgreifen. Ich hatte da nichts manuell signiert, aber vielleicht war da von ASUS ja schon was vorinstalliert. Gut zu wissen, dass das auch anders sein kann.

Wird da bei erstmaliger Installation mit Shim evtl. das nötige Zertifikat nebenbei installiert, sodass man später Shim eigentlich nicht mehr braucht? So könnte ich es mir jedenfalls erklären.

Dass Shim ein Sicherheitsrisiko ist, sehe ich so wie von Dir beschrieben nicht. ...

Ich selbst habe davon nicht genug Ahnung, insofern habe ich nur die Aussage in Wikipedia für zutreffend gehalten. Wenn das anders ist, umso beruhigender.

UlfZibis schrieb:

Wird da bei erstmaliger Installation mit Shim evtl. das nötige Zertifikat nebenbei installiert, sodass man später Shim eigentlich nicht mehr braucht?

Nein, das läuft anders, hat aber mit dem Artikel hier nicht mehr viel zu tun. Shim, Secure Boot wäre noch mal ein eingenständiges Thema.

Shim nutzt - AFAIK - im NVRAM einen eigenen Bereich, in dem Zertifikate abgelegt werden können. Dazu dient mokmgr bzw. mokutil. Dieses Vorgehen hat den Vorteil, dass der Endanwender über diesen Weg - also mit Shim zwischengeschaltet - auf jeden Fall auch eigene Zertifikate oder sonst benötigte Dritt-Zertifikate (z.B. Virtualbox) im NVRAM hinterlegen kann, auch wenn er eigentlich keinen Zugriff auf die Secure Boot Datenbank seines Systems hat bzw. nicht weiß, wie er diesen Zugriff auf seinem System erlangt.

Nachteil ist, dass dieser NVRAM-Bereich nicht in gleicher Weise geschützt ist, wie die eigentlichen Secure Boot Datenbanken.

Wenn Du Zertifikate über Shim ausrollst, dann musst Du auch Shim nutzen.

Aber wie gesagt, das wird hier OT und hat mit GRUB-Konfiguration nicht wirklich viel zu tun.

Dass Shim ein Sicherheitsrisiko ist, sehe ich so wie von Dir beschrieben nicht. ...

Ich selbst habe davon nicht genug Ahnung, insofern habe ich nur die Aussage in Wikipedia für zutreffend gehalten.

1. Steht das da im Wikipediaartikel nicht wirklich so, wie Du es interpretiert hast.

2. Ist der Wikipediaartikel extrem verkürzend, was - wie man an Deiner Interpretation bemerkt - dann leicht zu Fehlinterpretationen führt.

LG, Newubunti