přejít na obsah přejít na navigaci

Linux E X P R E S, (Ne)upravujte UEFI a Secure Boot – certifikát a podepisování

(Ne)upravujte UEFI a Secure Boot – certifikát a podepisování

tux.png

Článek o manipulacích s UEFI a Secure Boot pokračuje. Podíváme se na vytvoření certifikátu, podepisování souborů a aktualizaci databází certifikátů.


reklama

Manipulace s vlastním certifikátem

Doinstalování aplikací

Po nastartování Fedory doinstalujte z adresáře rpm (oddíl dataflash) balíčky v tomto pořadí: sbsigntools, gnu-efi, efitools.

Soukromý klíč a certifikát

Otevřete terminál a následující příkazy vám vytvoří vše potřebné pro Secure Boot. Nejprve vygenerujte soukromý klíč.

openssl genrsa -out private.key 2048

Použijte soukromý klíč pro tvorbu certifikátu. V bloku "/CN=Vlk/" nahraďte Vlk za vaše iniciály nebo jinou identifikaci.

openssl req -new -x509 -subj "/CN=Vlk/" -key private.key -out PK.crt -days 3650 -sha256

Převedení certifikátu z formátu PEM (PK.crt) do formátu DER (PK.cer) vám umožní vkládat vaše certifikáty přímo v UEFI, nebo pomocí KeyTool, případně MokManagerem do MOKlistu.

openssl x509 -in PK.crt -out PK.cer -outform DER

Certifikáty *.crt se používají pro podepisování binárek pomocí sbsigntools a certifikáty *.cer jsou použitelné pro vkládání do databází (vyjma Platform Key databáze).

Převod certifikátu pro PK databázi

cert-to-efi-sig-list PK.crt PK.esl
Vznikne soubor PK.esl (esl = EFI Signature List), který s KeyTool.efi můžete používat pro zápis do KEKdb databáze, ale na to vám postačí i cer formát certifikátu.
Platform Key je však možné aktualizovat jen s pomocí auth souboru.
sign-efi-sig-list -k private.key -c PK.crt PK PK.esl PK.auth
Platform Key je vždy poslední v aktualizaci databází certifikátů. Jakmile nahrajete certifikát do této databáze, dojde k aktivaci Secure Boot (vypne se Setup Mode) a další certifikáty je poté možno přidávat pouze do MOKlistu pomocí MokManageru (spolupracuje s Shim) nebo HashTool (spolupracuje s PreLoader).
Nyní máte připraveny všechny požadované verze svého certifikátu, a proto je zálohujte do adresáře moje_cert.
cp *.key *.crt *.cer *.esl *.auth /run/media/liveuser/dataflash/moje_cert

Podpis binárních souborů

Pro podepsání binárního souboru budete potřebovat soukromý klíč a certifikát ve formátu crt. Budete-li chtít v budoucnu pomocí tohoto flash disku podepsat další binárky, postačí vám po startu Fedory doinstalovat pouze sbsigntools.
Vaší první podepsanou aplikací by měl být KeyTool.efi.
sbsign -k private.key -c PK.crt --output KeyTool.efi 
/usr/share/efitools/efi/KeyTool.efi
Výstup terminálu po zadání uvedeného příkazu vás bude varovat, ale aplikace je plně funkční.
warning: data remaining[120320 vs 130673]: gaps between PE/COFF sections?
warning: data remaining[120320 vs 130680]: gaps between PE/COFF sections?

S podobným varováním se můžete setkat i u podpisu jádra Linuxu. Zde však úspěch podpisu záleží především na verzi jádra Linuxu. Takto vypadá nezdar při podpisu jádra Debianu (jádro bylo zkopírováno do domovského adresáře Fedory).

sbsign -k private.key -c PK.crt --output vmlinuz-3.2.0-signed vmlinuz-3.2.0-4-amd64

warning: file-aligned section .text extends beyond end of file 
warning: gap in section table: 
    datadir[CERT]->headers: 0x00000180 - 0x00000200, 
    .text   : 0x00000000 - 0x002b4600, 
warning: gap in section table: 
    .text   : 0x00000000 - 0x002b4600, 
    .reloc  : 0x00000000 - 0x00000200, 
gaps in the section table may result in different checksums 
warning: checksum areas are greater than image size. Invalid section table?

Sice v domovském adresáři Fedory vznikne soubor vmlinuz-3.2.0-signed, ale jeho velikost odpovídá cca 2 kB (velikost certifikátu). Za tímto neúspěchem je pravděpodobně funkce EFI_STUB_LOADER, která dovoluje spouštět jádro jako EFI aplikaci. Tato funkce je v jádru dostupná až od verze 3.3.0.

Jiné varování se zobrazilo při podpisu jádra z Mintu 16 (jádro opět překopírováno do domovského adresáře Fedory).

sbsign -k private.key -c PK.crt --output vmlinuz-signed vmlinuz

warning: file-aligned section .text extends beyond end of file 
warning: checksum areas are greater than image size. Invalid section table?

Takové jádro (vmlinuz-signed) je však plně funkční.

Nyní příkazem su povyšte svá práva na superuživatele a zkopírujte podepsaný KeyTool.efi na první oddíl flash disku (po restartu se vám ukáže v menu rEFIndu).

cp KeyTool.efi /run/initramfs/live/

Máte-li podepsané jádro Linuxu, překopírujte jej příkazem cp do výchozího adresáře a ponechejte mu odlišný název (-signed). Takové jádro jste nyní schopni spouštět pomocí Grub2 nainstalovaného distribucí podporující Secure Boot (po úpravě záznamu v grub.cfg).

Selže-li podpis jádra, je podepsání zavaděče (Grub2) instalované dotyčnou distribucí a instalování rEFIndu tou nejjednodušší cestou, jak provozovat Secure Boot i s Windows. Aplikace rEFInd oproti vámi podepsanému Grubu nebude mít problém se spouštěním Windows.

Problémem však může být podpis samotného jádra Grub2 zavaděče, protože tak zaniká celý koncept Secure Boot. Aplikace rEFInd spustí podepsaný Grub2 (což je v pořádku), ale již dále nekontroluje podpis aplikací (jader) spouštěných pomocí Grub2 (zde je zranitelnost). Také se celý start prodlouží o načítání/výběr voleb v Grub2 menu.

Podobný koncept startu máte na vytvořeném flash disku, kde je však podpis Fedory kontrolován pomocí Shim aplikace (BOOTX64.efi), která spouští podepsaný Grub2 (grubx64.efi) a poté kontroluje podpis Grubem spouštěného operačního systému (Fedory). Byť vám při bootování z flash disku nabídne rEFInd obě možnosti startu Fedory (BOOTX64.efi i grubx64.efi), bude po zapnutí Secure Boot funkční pouze start pomocí BOOTX64.efi.

Instalace rEFInd a podepsání Grub2

Následující příkazy vykonávejte jako superuživatel.

EFI System Partition není automaticky v Live Fedoře připojován. Nejprve zjistěte pomocí příkazu blkid na jakém oddílu se ESP nachází (ESP nemusí být nutně jako první oddíl na hdd, tam může být například Recovery atd.).

V mém případě je určení ESP jednoznačné:

blkid

/dev/sdb1: LABEL="uefiflash" UUID="F367-4CB1" TYPE="vfat"
/dev/sda1: UUID="C1AE-1930" TYPE="vfat"
/dev/sda2: UUID="384043BF4043831C" TYPE="ntfs"

Připojte nalezený ESP do /mnt (za sda1 dosaďte vámi nalezený ESP):

mount /dev/sda1 /mnt

Vytvořte adresář pro refind:

mkdir /mnt/EFI/refind-077

Zkopírujte potřebné soubory do ESP:

cp /run/media/liveuser/dataflash/refind-bin-0.7.7/refind/refind_x64.efi 
/mnt/EFI/refind-077

cp /run/media/liveuser/dataflash/refind-bin-0.7.7/refind/refind.conf-sample 
/mnt/EFI/refind-077/refind.conf

cp -r /run/media/liveuser/dataflash/refind-bin-0.7.7/refind/drivers_x64 
/mnt/EFI/refind-077

cp -r /run/media/liveuser/dataflash/refind-bin-0.7.7/refind/icons 
/mnt/EFI/refind-077

Nyní máte v ESP vše potřebné pro bootování pomocí rEFIndu (certifikát pro refind naleznete v /refind-bin-0.7.7/keys ). Ještě chybí bootovací záznam v UEFI, který vytvoříte s efibootmgr.

Zobrazení všech bootovacích záznamů v UEFI (část záznamu z mého UEFI):

efibootmgr -v

Boot000E* Grub2-vl 				HD(1,800,100000,cdcb3d62-aa40-40d8-b429-
4293bf9dc5ac)File(\EFI\grub2\grubx64.efi) 
Boot0010* opensuse-secureboot 	HD(1,800,100000,cdcb3d62-aa40-40d8-b429-
4293bf9dc5ac)File(\EFI\opensuse\shim.efi) 
Boot0012* opensuse 				HD(1,800,100000,cdcb3d62-aa40-40d8-b429-
4293bf9dc5ac)File(\EFI\opensuse\grubx64.efi)

Příklad smazání bootovacího záznamu v UEFI (v mém případě je pod položkou Boot000E zaregistrován již nepoužívaný Grub2). S touto funkcí zacházejte obezřetně a v žádném případě nemažte položky nesouvisející s instalovanými operačními systémy (ATA, USB atd.).

efibootmgr -b 000E -B

Vytvoření záznamu pro rEFInd:

efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\refind-077\\refind_x64.efi -L rEFInd

-c = create (vytvoř záznam)
-d = disk (na sda se nachází ESP)
-p = oddíl na disku (1 oddíl na sda)
-l = absolutní cesta k zavaděči (dvě zpětná lomítka jsou potřebná, nejedná se o chybu)
-L = název bootovacího záznamu

Každý nový bootovací záznam se zapíše na první pozici v UEFI (tzn. pokud jste měli flash disk na prvním místě, bude nyní na druhém za rEFInd).

Nastal čas na podepsání Grub2 z distribuce nepodporující podepsání jádra (v mém případě Debian).

Upravte podle skutečnosti.

sbsign -k private.key -c PK.crt --output grubx64.efi /mnt/EFI/debian/grubx64.efi

A následné zkopírování do ESP (s přepsáním původního souboru):

cp grubx64.efi /mnt/EFI/debian

To nejhorší máte již za sebou. Zbývá jen restartování počítače a aktualizace certifikátů. Než se k tomuto kroku odhodláte, připomenu několik bodů:

  • Secure Boot je nutné mít v Setup Mode (případně Custom Mode) pro vkládání certifikátů. Ujistěte se (manuál k výrobku nebo internet), že váš hardware má nějaký mechanismus pro uvedení do bezpečného (továrního) stavu, nebo dovoluje vypnout Secure Boot. Není nic horšího než špatnými certifikáty uzamčený hardware.
  • rEFInd je výborná náhrada za Grub2 s pokračujícím vývojem. Automaticky vyhledává EFI aplikace na ESP a s ovladači souborových systémů (ext2, ext4 atd.) prohledá i další oddíly na hdd, ze kterých vám nabídne seznam nalezených Linuxových jader pro přímé spuštění. Jeho konfigurace sestává z jednoho velmi dobře okomentovaného souboru (refind.conf) a je poměrně jednoduchá.
  • Secure Boot ochrání start operačního systému (hlavně Windows) před malwarem a další nehezkou havětí, ale neochrání již běžící systém.
  • Zde uvedený návod se možná zdá být dosti obtížný, ale jedná se komplexní (byť velmi zjednodušený) popis celého procesu (tvorba certifikátu, podpis binárek, řešení možných problémů). V žádném případě se nejedná o jedinou variantu, jak upravovat UEFI se Secure Boot, ale jde spíše o “zlatý střed”.

Aktualizace databází certifikátů

  1. Po restartování vyhledejte v rEFIndu položku KeyTool.efi na uefiflash.
  2. Je vhodné po startu KeyTool uložit jednotlivé certifikáty (jako esl soubory) z databází db, dbxKEK na druhý oddíl flash disku. Později je můžete přesunout do adresáře orig_cert.
  3. Přidejte vlastní certifikát do KEK databáze
  4. Edit Keys > KEK > Add New Key – vyhledejte certifikát (dataflash/moje_cert). Nezáleží na formátu a můžete použít jakýkoliv (cer, esl, auth).
  5. Stejným způsobem přidejte vlastní certifikát do db databáze. Do této databáze přidejte také certifikát autora rEFIndu (dataflash/refind-bin-0.7.7/keys/refind.cer), pokud jej chcete používat.
  6. Jako poslední aktualizujte databázi PK pomocí auth souboru. Tímto krokem se aktivuje Secure Boot a nezbývá nic jiného než restartování počítače.

Závěr

Snad se mi podařilo objasnit vám alespoň základy fungování Linuxu se Secure Boot. Přeji vám co nejméně problémů s touto bezpečnostní funkcí.## block banner=articlebanner ###

Nahoru

Odkazy

(Jako ve škole)
Průměr: 1,50 | Hodnotilo: 4
 

Top články z OpenOffice.cz

Příspěvky

Mario Radev (Ne)upravujte UEFI a Secure Boot – certifikát a podepisování
vxmery 7. 04. 2014, 11:11:29
Odpovědět  Odkaz 
Výborný a aktuálny článok, za mňa autorovi veľká pochvala. Mňa našťastie pri kúpe nového ntb problém UEFI a secure boot obišiel (predinštalovaný Linups)ale na fórach je bojujúcich nešťastníkov veľa. Verím, že im tieto informácie pomôžu.

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Vladislav Konopík


  • Distribuce: Debian / Mint-debian based
  • Grafické prostředí: GNOME
  • Hodnocení autora: *



Public Relations

QNAP uvedl novou modelovou řadu NAS TVS-x82T

Společnost QNAP uvedla na trh novou modelovou řadu NAS TVS-x82T, kterou tvoří tři různé modely (TVS-1282T, TVS-882T a TVS-682T). Nová řada je založena na vícejádrových procesorech Intel Core aktuální generace se 14nm výrobním procesem. Díky nim mohou nové NASy nabídnout dostatek výkonu i pro aplikace náročné na CPU.

Pokračování ...


CIO Agenda 2016