| View previous topic :: View next topic |
| Author |
Message |
pietinger
Guru
Joined: 17 Oct 2006
Posts: 319
Location: Bavaria
|
 Posted: Sat Mar 14, 2020 2:37 am Post subject: Meine Umstellung auf Secure Boot |
 |
|
Ich schreibe diesen Erfahrungsbericht um anderen zu helfen UND weil ich auch auf Feedback hoffe, was man wo besser machen könnte.
Dies ist die alte Version: Bitte lese die neue:
https://forums.gentoo.org/viewtopic-t-1112966.html
I. Mein bisheriges System:
Motherboard: Gigabyte Z270X-Gaming K5 mit Prozessor: Intel I7 Skylake
Linux: 5.5.9 (gentoo-sources) mit Intel Firmware für Prozessoer und GPU (keine extra Grafikkarte); OpenRC; GRUB2 und normalen GCC (stable).
Meine SSD ist bereits mit gpt formatiert und Grub bereits für EFI gerüstet. Ich habe also in der /etc/portage/make.conf:
| Code: | | GRUB_PLATFORMS="efi-64" |
Eine ziemliche Standard-Installation nach unserem Handbuch. Ich habe kein initramfs und kein initrd (und kein Microsoft Windows - also keine Dual-Boot-Maschine). Grub startet also direkt meinen Kernel.
In den BIOS-Einstellungen hatte ich im Menupunkt "BIOS":
"Windows 8/10 Features" "Other OS" und bei
"CSM Support" "enabled" (das muss später disabled werden).
II. Die hilfreichsten Links (habe ich numeriert, weil ich später darauf zu sprechen komme):
[1] http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
[2] https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Configuring_Secure_Boot_under_OpenRC
(Allerdings benutzt Salaki da ein selbstgeschriebenes build-script für den Kernel, welches ich nicht brauchen kann. Dafür fehlten dann die nötigen Befehle. Hier hat [1] weitergeholfen.)
[3] https://wiki.gentoo.org/wiki/Efibootmgr
[4] https://wiki.gentoo.org/wiki/EFI_stub_kernel
und der Link mit dem alles begann:
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
Ja - als erstes habe ich wirklich alles von dieser Seite umgesetzt. Insbesondere habe ich alle Module aufgespürt und fest in den Kernel rein compiliert, so dass ich dann erstmal einen monolithischen Kernel hatte. Dies sparte mir dann später auch einen ganzen Befehl: "make modules_install" 
Falls jemand denkt, das wäre doch Unsinn, so entgegne ich: 1. Wenns sicherer ist; und 2. außerdem will ich doch eh IMMER Grafikkarte, (ALSA-)Sound, Ethernet-Schnittstelle, ALLE BENÖTIGTEN Firewall-Module, USB-Unterstützung, und CD-ROM-Zugriff benutzen. Warum muss es denn modular sein ? (CD sollte man unbedingt mal einlegen um zu wissen, welche Module da nachgeladen werden; witzig war auch der USB-Stick eines Kollegen, den er unter Windows mit NTFS formatiert hat ...)
Falls ihr meint, das wird ein Riesen-Kernel ... NÖ ... grade mal 6,5 MB. Außerdem fällt dann auch dies hier
https://wiki.gentoo.org/wiki/Signed_kernel_module_support
komplett aus !
III. Vorgehensweise also:
1. Aus dem monolitischen Kernel einen Stub-Kernel machen und diesen booten
2. Einen signierten Kernel basteln
3. Die alten Keys sichern
4. Das BIOS überreden SecureBoot zu machen
5. Überprüfen und Aufräumen
1. Aus dem monolitischen Kernel einen Stub-Kernel machen und diesen booten
Dies war dank [4] sehr einfach und gemein ...
(a) Macht einfach nur das Kapitel "Kernel-Konfiguration" aber nicht das Kapitel "Installation". Bei der Installation bin ich nämlich auf die Nase gefallen, weil ich das Beispiel dort verwendet habe: Ohne Parameter -d und -p !
Außerdem habe ich vorher mal in /var/log/messsages den letzten Bootvorgang geprüft und dort war bei mir in der "command line" hinter "root=/dev/sda3" noch ein "ro" (für read-only) angegeben. Das habe ich unverändert so bei mir in den Kernel rein =>
| Code: | [*] Built-in kernel command line
(root=/dev/sda3 ro) |
(b) Erstellt ein neues Verzeichnis "Boot" in "/boot/EFI". Also "/boot/EFI/Boot" (vielleicht ist das "EFI" bei Euch klein geschrieben; dann lasst das so und passt meine Befehle an Euer kleines efi an)
(c) Compiliert Euren Kernel und kopiert ihn nach "/boot/EFI/Boot/bzImage.efi" OHNE Versions-Nr.
(d) Lest Euch [3] durch und installiert dann mit diesem Befehl:
| Code: | | ~ # efibootmgr -c -d /dev/sda -p 2 -L "SECULINUX" -l '\EFI\Boot\bzImage.efi' |
WENN Euer Boot-Verzeichnis auf sda - partition 2 - also sda2 ist. Wenn nicht, passt hinter dem Parameter -p die Partition an. Die Bezeichnung (SECULINUX) könnt ihr natürlich auch frei wählen. Alles hinter dem Parm -l muß in der richtigen Groß-/Kleinschreibung stimmen und auch die Backslashe statt unsere Linux-Forslashe müssen so sein (mieses Deutsch).
(e) Bootet jetzt mal durch und prüft, ob der Grub noch erscheint oder das BIOS gleich den Kernel startet. Falls gar nicht gebootet wird, müsst ihr ins BIOS rein und die Reihenfolge zurück ändern (auf Grub-Boot) und den Fehler suchen.
2. Einen signierten Kernel basteln
Dies war dank [1] sehr einfach, weil ich dort sein Skript rauskopiert habe und mir alle Schlüssel automatisiert erstellen habe lassen. Einzig die Gültigkeitsdauer der Schlüssel habe ich von 3650 Tagen (das sind ca. 10 Jahre) auf 9999 Tagen (das sind ca. 27 Jahre) geändert. Ich habe also dieses Skript laufen lassen. Alles was jetzt kommt habe ich als root in /root gemacht. Ach ja, ihr braucht die "efitools". Also ggf. emergen (ja mein Deutsch).
(a)
| Code: |
~ # nano mkkeys.sh
===>
#!/bin/bash
# Copyright (c) 2015 by Roderick W. Smith
# Licensed under the terms of the GPL v3
echo -n "Enter a Common Name to embed in the keys: "
read NAME
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME PK/" -keyout PK.key \
-out PK.crt -days 9999 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME KEK/" -keyout KEK.key \
-out KEK.crt -days 9999 -nodes -sha256
openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME DB/" -keyout DB.key \
-out DB.crt -days 9999 -nodes -sha256
openssl x509 -in PK.crt -out PK.cer -outform DER
openssl x509 -in KEK.crt -out KEK.cer -outform DER
openssl x509 -in DB.crt -out DB.cer -outform DER
GUID=`python -c 'import uuid; print(str(uuid.uuid1()))'`
echo $GUID > myGUID.txt
cert-to-efi-sig-list -g $GUID PK.crt PK.esl
cert-to-efi-sig-list -g $GUID KEK.crt KEK.esl
cert-to-efi-sig-list -g $GUID DB.crt DB.esl
rm -f noPK.esl
touch noPK.esl
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
-k PK.key -c PK.crt PK PK.esl PK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
-k PK.key -c PK.crt PK noPK.esl noPK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
-k PK.key -c PK.crt KEK KEK.esl KEK.auth
sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \
-k KEK.key -c KEK.crt db DB.esl DB.auth
chmod 0600 *.key
echo ""
echo ""
echo "For use with KeyTool, copy the *.auth and *.esl files to a FAT USB"
echo "flash drive or to your EFI System Partition (ESP)."
echo "For use with most UEFIs' built-in key managers, copy the *.cer files."
echo "" |
und danach natürlich noch ausführbar gemacht und ausgeführt:
| Code: | ~ # chmod +x mkkeys.sh
~ # ./mkkeys.sh |
Ich habe bei mir als Common Name "MY SECURE BOOT KEYS" eingegeben. Aber jeder andere Unsinn geht genauso (sollte vielleicht nicht zu lang werden - who knows).
(b) Jetzt den Stub-Kernel von /boot/EFI/Boot/ signieren mit diesem Befehl:
| Code: | | ~ # sbsign --key DB.key --cert DB.crt --output bzImage.efi /boot/EFI/Boot/bzImage.efi |
und zurück nach /boot/EFI/Boot kopieren (also den unsignierten damit überschreiben).
| Code: | | ~ # cp bzImage.efi /boot/EFI/Boot/. |
3. Die alten Keys sichern
Hier hat [2] geholfen. Ich habe von dort kopiert. Ihr könnt von hier kopieren:
| Code: | ~ # mkdir oldefikeys
~ # cd oldefikeys/
~/oldefikeys # efi-readvar -v PK -o old_PK.esl
Variable PK, length 862
~/oldefikeys # efi-readvar -v KEK -o old_KEK.esl
Variable KEK, length 1560
~/oldefikeys # efi-readvar -v db -o old_db.esl
Variable db, length 3143
~/oldefikeys # efi-readvar -v dbx -o old_dbx.esl
Variable dbx, length 3724 |
4. Das BIOS überreden SecureBoot zu machen
(a)Erstmal die neuen Schlüssel kopieren:
| Code: | ~/oldefikeys # cd ..
~ # cp -v *.{auth,cer,crt,esl} /boot/EFI/.
'DB.auth' -> '/boot/EFI/./DB.auth'
'KEK.auth' -> '/boot/EFI/./KEK.auth'
'noPK.auth' -> '/boot/EFI/./noPK.auth'
'PK.auth' -> '/boot/EFI/./PK.auth'
'DB.cer' -> '/boot/EFI/./DB.cer'
'KEK.cer' -> '/boot/EFI/./KEK.cer'
'PK.cer' -> '/boot/EFI/./PK.cer'
'DB.crt' -> '/boot/EFI/./DB.crt'
'KEK.crt' -> '/boot/EFI/./KEK.crt'
'PK.crt' -> '/boot/EFI/./PK.crt'
'DB.esl' -> '/boot/EFI/./DB.esl'
'KEK.esl' -> '/boot/EFI/./KEK.esl'
'noPK.esl' -> '/boot/EFI/./noPK.esl'
'PK.esl' -> '/boot/EFI/./PK.esl' |
(b) Macht einen Reboot und geht in Euer BIOS. Bei mir geht das mit "ENTF" oder "F12". Jetzt kommt wirklich die große BIOS-Suche. Wo und wie lösche ich die alten Keys und aktiviere die neuen. Bei meinem Gigabyte hatte ich erstmal nirgends eine Auswahl für Secure-Boot. Der erscheint erst, wenn man "CSM Support" auf "disable" stellt. Danach erscheint darunter ein neuer Menu-Punkt "Secure Boot". Dort habe ich die alten Keys gelöscht und die neuen Schlüssel von "boot/EFI/" geladen. Die Reihenfolge ist "PK", "KEK" und dann "db". "dbx" habe ich ausgelassen, da ich ja keine Zertifikate habe, die ich zurückrufen will. Lest Euch vorher unbedingt mal [1] und [2] durch (wenigstens überfliegen). Danach alles im BIOS sichern und verlassen. Der Augenblick der Wahrheit ...
5. Überprüfen und Aufräumen
Mein Startbildschirm (BIOS Boot-Logo) zeigte mir erstmalig unter dem Logo eine zusätzliche Zeile an:
"EFI Stub: UEFI Secure Boot is enabled"
Sofort in /var/log/messages reingeschaut und siehe da:
| Code: | | Mar 14 00:57:07 big kernel: [ 0.003681] Secure boot enabled |
Eine andere Abfrage zeigt auch die 1 für Secure Boot an:
| Code: | ~ # od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
6 0 0 0 1
|
Und zuletzt noch
| Code: | ~ # efi-readvar
Variable PK, length 851
PK: List 0, type X509
Signature 0, size 823, owner 79a99678-6581-11ea-b4d3-1c1b0d93463e
Subject:
CN=MY SECURE BOOT KEYS PK
Issuer:
CN=MY SECURE BOOT KEYS PK
Variable KEK, length 853
KEK: List 0, type X509
Signature 0, size 825, owner 79a99678-6581-11ea-b4d3-1c1b0d93463e
Subject:
CN=MY SECURE BOOT KEYS KEK
Issuer:
CN=MY SECURE BOOT KEYS KEK
Variable db, length 851
db: List 0, type X509
Signature 0, size 823, owner 79a99678-6581-11ea-b4d3-1c1b0d93463e
Subject:
CN=MY SECURE BOOT KEYS DB
Issuer:
CN=MY SECURE BOOT KEYS DB
Variable dbx has no entries
Variable MokList has no entries
|
Also jetzt noch SICHERN und Aufräumen:
Alle Schlüssel die in /root liegen auf einen Stick kopieren und in den Tresor damit. Löschen tue ich sie aber nicht aus /root um gleich den nächsten neuen Kernel signieren zu können. Dafür lösche ich die in /boot/EFI/.
| Code: | ~ # mount /boot/
~ # cd /boot/EFI/
/boot/EFI # lal
insgesamt 68
drwxr-xr-x 4 root root 4096 14. Mär 00:39 .
drwxr-xr-x 4 root root 4096 1. Jan 1970 ..
drwxr-xr-x 2 root root 4096 13. Mär 20:58 Boot
-rwxr-xr-x 1 root root 2102 14. Mär 00:39 DB.auth
-rwxr-xr-x 1 root root 807 14. Mär 00:39 DB.cer
-rwxr-xr-x 1 root root 1147 14. Mär 00:39 DB.crt
-rwxr-xr-x 1 root root 851 14. Mär 00:39 DB.esl
drwxr-xr-x 2 root root 4096 11. Feb 2017 gentoo
-rwxr-xr-x 1 root root 2101 14. Mär 00:39 KEK.auth
-rwxr-xr-x 1 root root 809 14. Mär 00:39 KEK.cer
-rwxr-xr-x 1 root root 1151 14. Mär 00:39 KEK.crt
-rwxr-xr-x 1 root root 853 14. Mär 00:39 KEK.esl
-rwxr-xr-x 1 root root 1248 14. Mär 00:39 noPK.auth
-rwxr-xr-x 1 root root 0 14. Mär 00:39 noPK.esl
-rwxr-xr-x 1 root root 2099 14. Mär 00:39 PK.auth
-rwxr-xr-x 1 root root 807 14. Mär 00:39 PK.cer
-rwxr-xr-x 1 root root 1147 14. Mär 00:39 PK.crt
-rwxr-xr-x 1 root root 851 14. Mär 00:39 PK.esl
/boot/EFI # rm *
rm: das Entfernen von 'Boot' ist nicht möglich: Ist ein Verzeichnis
rm: das Entfernen von 'gentoo' ist nicht möglich: Ist ein Verzeichnis
|
Zuletzt habe ich noch meinen "Spickzettel" erweitert:
| Code: | kernel-new
----------
mount /boot
cd /usr/src/linux-x-y-z
cp /usr/src/linux/.config .
make oldconfig
make -j 8
sbsign --key /root/DB.key --cert /root/DB.crt --output /boot/EFI/Boot/bzImage.efi /usr/src/linux/arch/x86/boot/bzImage
eselect kernel
umount /boot
|
6. Natürlich schützt Euch das überhaupt nicht, wenn ihr das BIOS nicht per Passwort schützt ... (aber das brauch ich wohl nicht zu sagen).
Have Fun,
Peter
Last edited by pietinger on Tue May 12, 2020 10:27 am; edited 6 times in total |
|
| Back to top |
|
 |
pietinger
Guru
Joined: 17 Oct 2006
Posts: 319
Location: Bavaria
|
| Posted: Sat Mar 14, 2020 3:49 am Post subject: |
|
|
| PS: Ich habe natürlich Grub und den alten Kernel in /boot belassen, damit ich ein Fallback habe, falls mal ein neuer Kernel nicht bootet (müsste ich vielleicht auch nicht erwähnen, aber sicherheitshalber ...). |
|
| Back to top |
|
|
firefly
Advocate
Joined: 31 Oct 2002
Posts: 4572
|
| Posted: Sat Mar 14, 2020 8:05 am Post subject: |
|
|
Durch das aktive secure boot wird das uefi dein grub nicht laden da die grub binary nicht signiert ist.
Entweder secure boot deaktivieren wenn du über grub booten möchtest oder das grub binary auch signieren.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
pietinger
Guru
Joined: 17 Oct 2006
Posts: 319
Location: Bavaria
|
| Posted: Sat Mar 14, 2020 8:18 am Post subject: |
|
|
| firefly wrote: | Durch das aktive secure boot wird das uefi dein grub nicht laden da die grub binary nicht signiert ist.
Entweder secure boot deaktivieren wenn du über grub booten möchtest oder das grub binary auch signieren. |
Ja - Stimmt. Das Deaktivieren von Secure Boot ist genauso auch dann notwendig, wenn man von USB oder CDROM booten möchte. Hätte ich vielleicht auch dazu schreiben sollen. Danke Dir. |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 2357
Location: Frankfurt, Germany
|
| Posted: Sat Mar 14, 2020 3:36 pm Post subject: |
|
|
| @pietinger: vielen Dank für die schöne Anleitung!!! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
