24.11.2017, 00:34 UhrDeutsch | English
Hallo Gast [ Registrierung | Anmelden ]

Neues Thema eröffnen   Neue Antwort erstellen
Vorheriges Thema anzeigen Druckerfreundliche Version Einloggen, um private Nachrichten zu lesen Nächstes Thema anzeigen
Autor Nachricht
dirkmitt
15 Titel: Eine Frage wegen UEFI und Secure-Boot.  BeitragVerfasst am: 06.04.2016, 12:41 Uhr



Anmeldung: 18. Okt 2006
Beiträge: 184

Ich habe jetzt eine Frage wegen UEFI.

Auf einem Laptop der für mich Wert hat, ein moderner Hewlett-Packard, habe ich alle Partitionen von der Festplatte gelöscht, und wie es empfohlen war, die FAT32-Partition zugelegt für UEFI, die auch bei '/boot/efi' gemountet ist, plus die zusätzliche Partitionen die für Linux root und home gedacht sind.

Allerdings habe ich nicht den MBR-Sektor / GPT-Sektor überschrieben.

Es entstand ein Laptop, der im UEFI-Modus eingerichtet ist, und auch in dem Modus fein startet. Jedoch ist es so, dass so bald ich im BIOS "Secure Boot" einstelle, ich von dem BIOS eine Fehlermeldung bekomme, dass die ('GRUB') Image die ich booten will, nicht authentisiert ist. Er startet also mit UEFI, aber nicht mit Secure Boot.

Frage: Hat das so seine Richtigkeit, oder sollte ich an dem Problem noch etwas tun?

Code:
root@Klystron:/home/dirk# efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,9999,0000
Boot0000* Windows Boot Manager  HD(2,145800,82000,40065ba9-ec61-4d09-8b63-0ebd39022e3b)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...-................
Boot0003* kanotix64     HD(1,800,fa000,f5d89f9d-3421-4698-9b27-f2f91e0c9de0)File(\EFI\kanotix64\grubx64.efi)
Boot9999* USB Drive (UEFI)      ACPI(a0341d0,0)PCI(1d,0)USB(10,0)..BO
root@Klystron:/home/dirk#


Übrigens: Es ist mir nicht 100% wichtig, dass er mit Secure-Boot starten soll. Nur weiß ich außerdem nicht, ob Kanotix einen Code-Unterzeichnungsschlüssel besitzt, der dazu erforderlich wäre, damit das auch klappt.

Dirk

(Edit : ) In Tatsache, kenne ich das Thema von 'Public Key Cryptography' doch, und verstehe ich, dass es bei 'Secure Boot' um elektronische Unterzeichnungen geht, die mit 'Public Key...' verschlüsselt werden, und die theoretisch zu einer Kette von Unterzeichnungen führen können, wo der öffentliche Schlüssel jeder Unterzeichnung durch den privaten der hervorgehenden verschlüsselt wurde. Wichtig scheint zu sein, dass der letzte öffentliche Schlüssel in der Kette, auf der Whitelist des BIOS aufgelistet sein muss.

Was ich also theoretisch tun könnte, wäre mir geschäftlich einen legalen EFI-Unterzeichnungsschlüssel zu kaufen, und mit dessem privaten Schlüssel den GRUB-Bootlader selber zu unterzeichnen. Dazu bräuchte ich Linux-Werkzeuge, die es letztendlich gibt.

Weil sich aber 'Kanotix' im UEFI-Modus installiert hat, wird es wahrscheinlich der Fall sein, dass bei Ihrem System schon irgendein Werkzeugsatz mit auf der Platte ist. 'efibootmgr' wäre nur ein Beispiel davon.

Gleichzeitig wäre es aber unpraktisch, wenn man nach jedem 'update-grub' -Befehl eine komplizierte Befehlszeile ausführen musste, um so zu tun. Also könnte ich mir vorstellen dass der GRUB von Ubuntu, z.B., bereits in einem bestimmten Ordner nach so einem Schlüssel-Paar sucht, und wenn vorhanden, dass deren GRUB-Konfiguration einen solchen auch anwendet.

Meine Frage an Sie wäre, sollte ich mir privat ein Schlüssel-Paar kaufen,

1) Ob es einen einfachen Weg gibt das dem GRUB vorzulegen, für automatischen Einsatz, oder
2) Ob Sie mir etwas den Weg zeigen könnten, anderswie damit umzugehen.

(Edit : ) Wegen diesem Thema habe ich mal etwas weiter gelesen, und ein Artikel gefunden das mich alarmiert hat:

Externer Link

Was dieser Artikel behauptet, ist dass die FAT32-Partition, die auch als die 'ESP' bekannt sei, die EFI System Partition, durchaus EFI-Schlüssel anbieten kann, was in sich nicht stört. Aber es wird so dargestellt, dass die öffentliche Schlüssel für diese Schlüssel-Paare selber nicht unterzeichnet werden brauchen, von dem Meister-Privat-Schlüssel. Das spricht an sich dagegen, was ich von öffentlicher Verschlüsselung gedacht hatte zu verstehen. Es darf also jedermann eine Whitelist herstellen?

1) Wie trifft sich das denn damit, dass man auch Kanotix auf einer blanken Festplatte installieren darf, ohne dass die als Dual-Boot mit Windows vor-geteilt war?

2) Wer sollte denn zuständig sein, dass auch die Images die von den Paketmanagern heruntergeladen wurden, mit irgendeiner Sammlung von EFI-Schlüsseln unterzeichnet wurden?

(Edit : ) Es erscheint dass die Welt doch nicht so komisch ist. Wenn man den Artikel weiter durchliest, sieht man dass der einzige Zweck war, diese Schlüssel in '/boot/efi' zu kopieren, sicher zu stellen dass sie das BIOS lesen kann, bevor das Betriebssystem gestartet ist. Ein bekanntes Thema. Aber danach müsste man immer noch erst in die BIOS Einstellungen gehen, um von dort aus die (vorhergehende) Schlüssel zu löschen, und um danach von dort aus die neue Schlüssel zu Setzen.

Dazu soll es auch das komplierbare Werkzeug geben.

Aber so ergibt meine Weltanschauung wieder Sinn. Die Schlüssel müssen also im Firmware gespeichert ,sein, wo sie danach auch die Standard-Schlüssel ersetzt haben würden.

Dirk

Das größte Besorgnis dass ich an der Aufgabe sähe, wäre dass das Werkzeug 'sbsign', anstatt 'vmlinuz...' zu unterzeichnen, diese ausführbare Datei einfach gestört hat. Alles andere ließe sich ja wieder rückgängig machen, indem man Secure-Boot wieder deaktiviert, und der Kernel selber hat ja nicht eine Beendigung im Dateiname, von .EFI . Der Autor von diesem Artikel gibt Uns einfach sein Wort, die Fehlermeldungen wären "normal so". Dagegen muss aber dieser Kernel in einem Format gespeichert sein, den das Firmware direkt ausführen kann, ohne dass dazu auch das Betriebssystem gestartet sein muss. Und das Werkzeug 'sbsign' kam bei mir nun mal direkt vom Paketmanager, und war nicht selbst-kompiliert, wie es bei mir dagegen 'efitools' war. Mit temporären Dateien, gab mir die selbe Aufgabe - zu unterzeichnen - bei '...grubx64.efi' dagegen keine Fehlermeldungen...

Ein weiteres Besorgnis wäre, dass er mir alle meine Hardware-ROM-Bilder platt fährt - insbesondere meines Grafik-Chipsatz - weil ich ihm global andere Schlüssel gegeben hätte, obwohl die Signaturen der ROMs bisher noch alle gestimmt hätten. Und wenn die Hardware einmal verbotene ROMs hätte, würde das dazu führen, dass sie den geladenen Kernel nach seinen Linux-Firmware-Modulen als Ersatz fragt? Auch wenn das alles logisch stimmen sollte, müsste es einen Unterschied im echten Verhalten erzeugen...


Zuletzt bearbeitet von dirkmitt am 07.04.2016, 20:05 Uhr, insgesamt 2 Male bearbeitet
 
 Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen  
Antworten mit Zitat Nach oben
dirkmitt
Titel:   BeitragVerfasst am: 07.04.2016, 12:48 Uhr



Anmeldung: 18. Okt 2006
Beiträge: 184

Als ich gestern Abend die Mut gewann das ganze einzusetzen, bin ich zu dem Resultat gekommen, dass ich eine Fehlermeldung bekam dass EFI nicht erlaubt, das Modul

/boot/grub/x86_64-efi/normal.mod

zu laden, weil dies nicht unterzeichnet ist. Das sagt mir schon mal, dass die Selbst-Unterzeichnung von dem GRUB Kern, und von dem Kernel, angenommen wurden. Aber es gibt mir auch den Hinweis, dass ich auf diesem Kurs, zunächst sämtliche Kernelmodule auch unterzeichnen müsste, wozu ich nicht bereit bin. Was ich also gestern Abend zunächst tat, war Secure Boot wieder zu deaktivieren, damit der Laptop normal startet.

Das sagt mir auch, dass der Befehl 'sbsign' die Images nicht gestört hat.

Jetzt hätte ich nur noch die Frage, ob mir der eventuelle Schritt die Aufgabe erleichtern würde, wenn ich im '/etc/default/grub' die Option setzen würde:

GRUB_CMDLINE_LINUX_DEFAULT="quiet noefi rw gfx=auto"

Und dann wieder 'update-grub', und den neuen GRUB-Kern wieder unterzeichnen...

Aber da bin ich pessimistisch. Also habe ich zunächst mal wieder mein Projekt, ohne Secure Boot, gestoppt.

Dirk
 
 Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen  
Antworten mit Zitat Nach oben
Kano
Titel:   BeitragVerfasst am: 07.04.2016, 14:09 Uhr



Anmeldung: 17. Dez 2003
Beiträge: 16583

Lass es doch einfach aus, kein Mensch braucht Secure Boot, Evil Maid Angriffe kann es nicht wirklich verhindern, weil es nen Linux Foundation Loader gibt. Wenn du den testen willst frag mich im IRC. Debian hat GRUB2 mit den selben Patches wie Ubuntu gepacht obwohl es nicht nötig wäre, Upstream macht keinerlei Einschränkungen im Falle von Secure Boot. Man muss deswegen GRUB2 so installieren, dass alle benötigten Teile direkt im EFI binary hat. Man kann es auch selbst signieren und braucht nix kaufen. Aber überlege mal kurz was der Aufwand soll, solange GRUB2 edit mode freigeschaltet ist die restlichen Partitionen ned verschlüsselt. Ich krieg so immer root wenn ich die Kiste booten kann. Da nimmt man doch eher ein HD password als sich mit UEFI auseinanderzusetzen wo du auch im dümmsten Falle nur dir HD ausbauen müsstest. Secure Boot soll davor schützen, dass der EFI Loader getauscht werden kann ohne dass man des mitkriegt. Das ist als einer der letzten Dinge wo man absichern kann vielleicht sinnvoll aber als alleinige Maßnahme total überflüssig. Bei Windows ergibt es demnach auch am ehesten Sinn, wenn BitLocker aktiv ist und ein Hardware TPM vorhanden ist. Doch Windows wird von sovielen Trojanern angegriffen, da bringt das auch nix mehr Winken
 
 Benutzer-Profile anzeigen Private Nachricht senden  
Antworten mit Zitat Nach oben
dirkmitt
Titel:   BeitragVerfasst am: 07.04.2016, 19:34 Uhr



Anmeldung: 18. Okt 2006
Beiträge: 184

Na ja danke für den Rat, Kano. Sie haben ja eigentlich Recht. Jetzt gibt es mir aber doch zwei Gedanken dazu:

1) Sie schrieben, Secure Boot soll nur verhindern, dass ein gefälschter EFI Bootloader eingesetzt wird. Auf meinem Laptop könnte Secure Boot aber gegen etwas anderes schützen, wenn ich selbst-signiert bin.

Dieser Laptop hat es als Eigenschaft, dass man das Booten von USB-Stäben, einfach in den BIOS-Einstellungen, nicht ausschalten kann. Das hört sich vielleicht komisch an, aber so ist er. Also, so lange ich Secure Boot nicht habe, und so lange der Platform-Schlüssel beim Microsoft-Standard bleibt, wäre es so, dass theoretisch jemand bei mir herum-schleichen könnte, und seinen eigenen Kanotix-USB-Stab einstecken könnte, ohne das BIOS-Kennwort eintippen zu brauchen. Das sollte ich eigentlich gar niemanden erklären, bleibt aber ein Riesen-Sicherheitsloch bei mir.

Und das stört eventuell bei einem Laptop, auch wenn es bei einem stationären Server nicht gestört hat.

Außerdem habe ich den schwachen Verdacht, das könnte bei anderen Laptops heutzutage genauso sein, nur ohne dass es bei denen so offiziell angegeben wird. D.h., wenn es um echte Bedrohungen gehen soll, haben die Angreifer eben den selben Secure Boot Schlüssel, und können die das. Wo ich jetzt also sehe, ich könnte selbst-signiert sein, spitzt das meine Interesse - mitten im Posting.

Was ich aber sehe, ist dass ich zunächst einfach annehmen müsste, dass die 'noefi' GRUB-Option als Wirkung hat, der Kernel tut nicht das was er normalerweise tun würde, und testet nicht mehr alle Kernelmodule wegen EFI-Signatur, wenn er erkennt er sei im EFI-Modus gestartet worden.

Manchmal haben diese GRUB-Optionen auch einfach nicht die Wirkung, die ich mir von denen wünsche. Und so verstumpft auch wieder meine Interesse, die gerade angesptizt war.

2) Sie schrieben, der GRUB hat standardmäßig einen Edit-Modus, also der EFI-Bootloader den ich mit eigenen Schlüsseln bis jetzt signiert habe.

Vielleicht mögen Sie diese Frage nicht direkt beantworten. Aber wie könnte man denn diesen Edit-Modus, theoretisch, deaktivieren?

Ich meine, bei mir schleicht aber wirklich niemand herum. Diese ganze Übung von mir bestand aus akademischer Interesse. Und eine interessante Lehre daraus die ich behalten habe, ist dass ich auch nicht den 'Linux Foundation Loader' verwenden brauch, nur weil der in dem Artikel genannt wurde, weil ich ja das Programm 'KeyTool-signed.efi' selbst kompiliert habe, als Teil von 'efitools'.

Mein BIOS erlaubt es mir, eine signierte .EFI-Datei auszuführen, und diese funktioniert. Meine eigene Schlüssel konnte ich also auch mit dem Standard-Bootloader -geblieben, sicher in das BIOS laden. Ich würde niemals den Vorschlag ernst nehmen, mir einen Bootloader anderer Partei zu nehmen.

Dirk
 
 Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen  
Antworten mit Zitat Nach oben
Kano
Titel:   BeitragVerfasst am: 07.04.2016, 19:50 Uhr



Anmeldung: 17. Dez 2003
Beiträge: 16583

Ich könnte selbstverständlich Kanotix mit aktivem Secure Boot live starten, wenn der MS Schlüssel benützt wird. Dazu nimmt man einfach den signierten shim + grub.efi von Ubuntu - man kann das ja einfach auf nen FAT32 Stick kopieren und anpassen. Alternativ könnte man den LinuxFoundation Loader nehmen, der geht noch etwas besser mit gummiboot (hat keinerlei Secure Boot Einschränkungen, deswegen kannst alles darüber starten), aber ist ja belanglos. Per default ist bei Kanotix kein Secure Boot supported, aber jedes Ubuntu, OpenSuSE, Fedora usw. geht. Da du ja deinen Bootloader selbst signieren willst, machst es halt so:
Code:
grub-install --modules="all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gfxmenu gfxterm gzio halt hfsplus iso9660 jpeg keystatus loadenv linux linuxefi memdisk minicmd normal part_apple part_msdos part_gpt password_pbkdf2 png reboot search search_fs_uuid search_fs_file search_label sleep test video lvm mdraid09 mdraid1x tar test regexp"

Das sollte gehen ohne dass es was nachladen muss. Die "noefi" Option ist nur für CSM gebootete Systeme, keine Ahnung, was du damit willst.
 
 Benutzer-Profile anzeigen Private Nachricht senden  
Antworten mit Zitat Nach oben
dirkmitt
Titel:   BeitragVerfasst am: 07.04.2016, 20:05 Uhr



Anmeldung: 18. Okt 2006
Beiträge: 184

Ich freue mich ganz massiv, dass Sie mir damit geholfen haben! Sehr glücklich

Es kann ja sein dass ich das nicht sofort anwende. Es gibt mir aber Zufriedenheit, eine autoritative Antwort auf meine Frage zu bekommen.

Ja, ich scheine mich echt zu erinnern, dass die Fehlermeldung wegen dem Modul von vorher, schon beim GRUB kam, und nicht erst beim Kernel-Start.

Und zu meiner anderen Frage habe ich gelesen, dass man den Edit-Modus nur los wird, indem man ein GRUB-Kennwort setzt. Schade.

Etwas was ich viel praktischer tun würde, wäre meinen Llaptop einfach an jemanden zu verleihen, und der anderen Person ein Benützer-Konto zuzuweisen, das beschränkte Privilegien hat. Und in dem Kontext gibt es schon eher Sinn, dass man dann auch nicht will, die andere Person steckt in ihrer Ruhe USB-Schlüssel ein, mit einem anderen Sinn als halt nur Videos zu übertragen.

Nochmals, Danke
Dirk

(Edit 08.04.2016 : ) Ich habe diese Lösung gestern sofort angewendet, und sie hat tadellos geklappt. Und seitdem ist von dem Paketmanager ein Kernel-Update durchgeführt worden, so dass ich jetzt zwei Kernel besitze:

vmlinuz-4.4.0-17-generic
vmlinuz-4.4.0-18-generic

Der zweite davon ist von mir nicht signiert. Was mir dazu wichtig erschien, war dass der Neustart nach dem Paket-geführten Update auch einwandfrei lief, in den neuen Kernel hinein, ohne dass ich noch mal etwas signieren brauchte. Das tat er auch. Sogar 'update-grub' scheint die Datei

/boot/efi/EFI/kanotix64/grubx64.efi

Nicht zu berühren. Was ich mich dazu nur frage, wo Ubuntu angeblich Secure-Boot unterstützt, ist ob den Ubuntu-Benützern der 'install-grub' Befehl verboten bleibt, der ja diese Datei neu kompiliert...

Der Kano versteht das mit Sicherheit, aber ich schreibe das nochmal, für den Vorteil von anderen, möglichen Lesern.

Code:
dirk@Klystron:~$ dmesg | grep fglrx
[   11.782755] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel.
[   11.795876] fglrx: module verification failed: signature and/or required key missing - tainting kernel
[   11.815699] <6>[fglrx] Maximum main memory to use for locked dma buffers: 10912 MBytes.
[   11.815849] <6>[fglrx]   vendor: 1002 device: 990f revision: 0 count: 1
[   11.816467] <6>[fglrx] ioport: bar 1, base 0xf000, size: 0x100
[   11.816949] <6>[fglrx] Kernel PAT support is enabled
[   11.816972] <6>[fglrx] module loaded - fglrx 15.30.3 [Dec 17 2015] with 1 minors
[   24.359061] <6>[fglrx] Firegl kernel thread PID: 1003
[   24.359263] <6>[fglrx] Firegl kernel thread PID: 1004
[   24.359392] <6>[fglrx] IRQ 38 Enabled
[   24.364296] <6>[fglrx] Reserved FB block: Shared offset:0, size:1000000
[   24.364299] <6>[fglrx] Reserved FB block: Unshared offset:fab4000, size:4000
[   24.364301] <6>[fglrx] Reserved FB block: Unshared offset:fab8000, size:548000
[   24.364303] <6>[fglrx] Reserved FB block: Unshared offset:2ffed000, size:13000
[   24.456657] <6>[fglrx] ATIF platform detected with notification ID: 0x81
dirk@Klystron:~$


glxinfo:

direct rendering: Yes
(...)
OpenGL core profile version string: 4.4.13416 Core Profile Context 15.302
 
 Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen  
Antworten mit Zitat Nach oben
Kano
Titel:   BeitragVerfasst am: 11.04.2016, 20:34 Uhr



Anmeldung: 17. Dez 2003
Beiträge: 16583

update-grub schreibt die /boot/grub/grub.cfg aber NICHT den Bootloader selbst, für den ist grub-install nötig. Bei MBR (BIOS) mit Angabe von nem Laufwerk (z. B. /dev/sda), bei UEFI ohne Option - zumindest, wenn man nicht vorhat dies zu signieren, weil dann darf es ned so modular sein. Kernel musst denk ich nicht signieren mit der Methode, ausser du willst die OHNE GRUB booten.
 
 Benutzer-Profile anzeigen Private Nachricht senden  
Antworten mit Zitat Nach oben
Beiträge vom vorherigen Thema anzeigen:     
Gehe zu:  
Alle Zeiten sind GMT + 1 Stunde
Neues Thema eröffnen   Neue Antwort erstellen
Vorheriges Thema anzeigen Druckerfreundliche Version Einloggen, um private Nachrichten zu lesen Nächstes Thema anzeigen
PNphpBB2 © 2003-2007 
 
Deutsch | English
Logos and trademarks are the property of their respective owners, comments are property of their posters, the rest is © 2004 - 2006 by Jörg Schirottke (Kano).
Consult Impressum and Legal Terms for details. Kanotix is Free Software released under the GNU/GPL license.
This CMS is powered by PostNuke, all themes used at this site are released under the GNU/GPL license. designed and hosted by w3you. Our web server is running on Kanotix64-2006.