Ubuntu Wiki

Co to jest UEFI Secure Boot?

UEFI Secure boot jest mechanizmem weryfikacji dla zapewnienia, że kod uruchamiany przez firmware jest zaufany.

Prawidłowe, bezpieczne korzystanie z UEFI Secure Boot wymaga, aby każdy plik binarny załadowany podczas uruchamiania był sprawdzany pod kątem znanych kluczy, umieszczonych w oprogramowaniu układowym, które oznaczają zaufanych dostawców i źródła plików binarnych lub zaufanych konkretnych plików binarnych, które można zidentyfikować za pomocą kryptograficznego haszowania.

Większość sprzętu x86 pochodzi z fabryki wstępnie załadowana kluczami Microsoftu. Oznacza to, że możemy ogólnie polegać na firmware w tych systemach, aby zaufać binarkom, które są podpisane przez Microsoft, a społeczność Linuksa w dużej mierze polega na tym założeniu, aby Secure Boot działał. Jest to ten sam proces wykorzystywany przez Red Hat i SUSE, na przykład.

Wiele architektur ARM i innych również obsługuje UEFI Secure Boot, ale może nie ładować wstępnie kluczy w firmware. Na tych architekturach może być konieczne ponowne podpisanie obrazów startowych certyfikatem, który jest załadowany do firmware’u przez właściciela sprzętu.

Pierwotny plan wdrożenia: Plan wdrożenia.

Obsługiwane architektury

• amd64: Binarium shim podpisane przez Microsoft i binarium grub podpisane przez Canonical są dostarczane w głównym archiwum Ubuntu jako shim-signed lub grub-efi-amd64-signed.

• arm64: Od 20.04 (’focal’), binarny shim podpisany przez Microsoft i binarny grub podpisany przez Canonical są dostarczane w głównym archiwum Ubuntu jako shim-signed lub grub-efi-arm64-signed. Istnieje błąd GRUB w trakcie badania, który musi być rozwiązany przed tym działa koniec do końca.

Testowanie UEFI Secure Boot

Jeśli jesteś zainteresowany testowaniem Secure Boot w swoim systemie, skonsultuj how-to tutaj: UEFI/SecureBoot/Testowanie.

How UEFI Secure Boot works on Ubuntu

On Ubuntu, all pre-built binaries intended to be loaded as part of the boot process, with the exception of the initrd image, are signed by Canonical’s UEFI certificate, which itself is implicitly trusted by being embedded in the shim loader, itself signed by Microsoft.

Na architekturach lub systemach, gdzie wstępnie załadowane certyfikaty podpisywania od Microsoftu nie są dostępne lub załadowane w firmware, użytkownicy mogą zastąpić istniejące podpisy na shim lub grub i załadować je jak chcą, weryfikując je z własnymi certyfikatami zaimportowanymi w firmware systemu.

Jak system się uruchamia, firmware ładuje binarne shim, jak określono w zmiennych BootEntry firmware. Ubuntu instaluje swój własny BootEntry w czasie instalacji i może go aktualizować za każdym razem, gdy bootloader GRUB jest aktualizowany. Ponieważ plik binarny shim jest podpisany przez Microsoft, jest on sprawdzany i akceptowany przez firmware podczas weryfikacji certyfikatów już obecnych w firmware. Ponieważ shim binarny zawiera certyfikat Canonical, jak również własną bazę danych zaufania, dalsze elementy środowiska uruchomieniowego mogą, oprócz tego, że są podpisane przez jeden z akceptowalnych certyfikatów wstępnie załadowanych w firmware, być podpisane przez klucz UEFI Canonical.

Kolejną rzeczą ładowaną przez shim jest obraz drugiego stopnia. Może to być jedna z dwóch rzeczy: albo GRUB, jeśli system startuje normalnie; albo MokManager, jeśli wymagane jest zarządzanie kluczami, skonfigurowane przez zmienne firmware (zwykle zmienione, gdy system był wcześniej uruchomiony).

Jeśli bootowanie przebiega normalnie; ładowana jest binarka GRUB (grub*.efi) i podejmowana jest próba jej walidacji względem wszystkich znanych wcześniej zaufanych źródeł. Binarny GRUB dla Ubuntu jest podpisany przez klucz UEFI Canonical, więc jest pomyślnie sprawdzony i proces bootowania jest kontynuowany.

Jeśli rozruch ma być kontynuowany z zadaniami zarządzania kluczami, ładowana jest binarka MokManagera (mm*.efi). Ta binarka jest w sposób jawny zaufana przez shim, ponieważ jest podpisana kluczem efemerycznym, który istnieje tylko podczas budowania binarki shim. Oznacza to, że tylko binaria MokManagera zbudowane z konkretną binarką shim będą mogły być uruchamiane i ogranicza możliwość kompromitacji przez użycie skompromitowanych narzędzi. MokManager pozwala każdemu użytkownikowi obecnemu na konsoli systemowej na zapisywanie kluczy, usuwanie zaufanych kluczy, zapisywanie binarnych hashy i przełączanie walidacji Secure Boot na poziomie shimów, ale większość zadań wymaga podania wcześniej ustawionego hasła w celu potwierdzenia, że użytkownik na konsoli jest rzeczywiście osobą, która zażądała zmian. Takie hasła działają tylko podczas jednego uruchomienia shim / MokManager; i są kasowane jak tylko proces zostanie zakończony lub anulowany. Po zakończeniu zarządzania kluczami, system jest restartowany i nie kontynuuje po prostu bootowania, ponieważ zmiany w zarządzaniu kluczami mogą być wymagane do pomyślnego zakończenia bootowania.

Kiedy system kontynuuje bootowanie do GRUB; proces GRUB ładuje każdą wymaganą konfigurację (zwykle ładuje konfigurację z ESP (EFI System Partition), wskazując na inny plik konfiguracyjny na partycji głównej lub startowej), która wskaże mu obraz jądra do załadowania.

EFI aplikacje do tego momentu mają pełny dostęp do firmware systemu, w tym dostęp do zmiany zaufanych zmiennych firmware, jądro do załadowania musi być również zweryfikowane względem bazy danych zaufania. Oficjalne jądra Ubuntu są podpisane przez klucz Canonical UEFI, są one pomyślnie zweryfikowane, a kontrola jest przekazywana do jądra. Obrazy Initrd nie są sprawdzane.

W przypadku nieoficjalnych jąder, lub jąder zbudowanych przez użytkowników, należy podjąć dodatkowe kroki, jeśli użytkownicy chcą załadować takie jądra zachowując pełne możliwości UEFI Secure Boot. Wszystkie jądra muszą być podpisane, aby mogły być załadowane przez GRUB, gdy włączone jest UEFI Secure Boot, więc użytkownik będzie musiał wykonać własne podpisanie. Alternatywnie, użytkownicy mogą chcieć wyłączyć walidację w shimie podczas uruchamiania z włączonym Secure Boot na oficjalnym jądrze, używając 'sudo mokutil –disable-validation’, podając hasło, gdy zostaniesz o to poproszony, i restartując komputer; lub całkowicie wyłączyć Secure Boot w firmware.

Do tego momentu, każde niepowodzenie w sprawdzeniu poprawności obrazu do załadowania spotyka się z krytycznym błędem, który zatrzymuje proces bootowania. System nie będzie kontynuował rozruchu i może automatycznie uruchomić się ponownie po pewnym czasie, biorąc pod uwagę, że inne zmienne BootEntry mogą zawierać ścieżki rozruchu, które są ważne i zaufane.

Po załadowaniu, zweryfikowane jądra wyłączą usługi Boot Services firmware’u, tym samym pozbawiając się uprawnień i efektywnie przełączając się w tryb użytkownika; gdzie dostęp do zaufanych zmiennych jest ograniczony tylko do odczytu. Biorąc pod uwagę szerokie uprawnienia przyznane modułom jądra, każdy moduł nie wbudowany w jądro również będzie musiał zostać zweryfikowany przy ładowaniu. Moduły zbudowane i dostarczone przez Canonical z oficjalnymi jądrami są podpisane przez klucz UEFI Canonical i jako takie są zaufane. Moduły zbudowane na zamówienie będą wymagały od użytkownika podjęcia niezbędnych kroków w celu podpisania modułów, zanim ich załadowanie będzie dozwolone przez jądro. Można to osiągnąć za pomocą polecenia 'kmodsign’.

Niepodpisane moduły są po prostu odrzucane przez jądro. Każda próba wstawienia ich za pomocą insmod lub modprobe zakończy się niepowodzeniem z komunikatem o błędzie.

Zważywszy, że wielu użytkowników wymaga modułów firm trzecich, aby ich systemy działały poprawnie lub aby niektóre urządzenia działały; i że te moduły firm trzecich wymagają budowania lokalnie w systemie, aby być dopasowane do działającego jądra, Ubuntu zapewnia narzędzia do automatyzacji i uproszczenia procesu podpisywania.

Jak mogę wykonać niezautomatyzowane podpisywanie sterowników?

Niektóre projekty mogą wymagać użycia niestandardowych sterowników jądra, które nie są skonfigurowane w taki sposób, aby działały z DKMS. W takich przypadkach, ludzie powinni korzystać z narzędzi zawartych w pakiecie shim-signed: skrypt update-secureboot-policy jest dostępny do generowania nowego MOK (jeśli żaden z modułów zbudowanych przez DKMS nie uruchomił już generowania jednego).

Użyj następującego polecenia, aby zapisać istniejący klucz do shim:

sudo update-secureboot-policy --enroll-key

Jeśli żaden MOK nie istnieje, skrypt zakończy pracę z komunikatem o tym fakcie. Jeśli klucz jest już zarejestrowany, skrypt zakończy pracę, nie robiąc nic. Jeśli klucz istnieje, ale nie widać, że jest zapisany, użytkownik zostanie poproszony o hasło do użycia po ponownym uruchomieniu, aby klucz mógł zostać zapisany.

Można wygenerować nowy MOK używając następującego polecenia:

sudo update-secureboot-policy --new-key

A następnie zapisać nowo wygenerowany klucz do shim za pomocą wcześniej wspomnianego polecenia do tego zadania.

Moduły jądra mogą być następnie podpisane poleceniem kmodsign (zobacz UEFI/SecureBoot/Signing) jako część ich procesu budowania.

Implikacje bezpieczeństwa w zarządzaniu kluczem właściciela maszyny

MOK generowany w czasie instalacji lub przy aktualizacji jest specyficzny dla maszyny, i tylko dozwolony przez jądro lub podkładkę do podpisywania modułów jądra, przez użycie specyficznego KeyUsage OID (1.3.6.1.4.1.2312.16.1.2) określającego ograniczenia MOK.

Późniejsze wersje podkładek zawierają logikę pozwalającą na śledzenie ograniczeń kluczy tylko do podpisywania modułów. Te klucze będą mogły być zapisane w firmware w bazie danych zaufania shim, ale będą ignorowane podczas sprawdzania poprawności obrazów do załadowania w firmware przez shim lub GRUB. Funkcja verify() shim’a będzie tylko pomyślnie walidować obrazy podpisane kluczami, które nie zawierają OID „Module-signing only” (1.3.6.1.4.1.2312.16.1.2) KeyUsage. Jądra Ubuntu używają globalnej bazy danych zaufania (która zawiera zarówno shim’s jak i firmware’s) i zaakceptują każdy z zawartych kluczy jako klucze podpisujące podczas ładowania modułów jądra.

Zważywszy na ograniczenia nałożone na automatycznie generowany MOK oraz fakt, że użytkownicy z dostępem superużytkownika do systemu i dostępem do konsoli systemowej w celu wprowadzenia hasła wymaganego przy zapisywaniu kluczy mają już wysokopoziomowy dostęp do systemu; wygenerowany klucz MOK jest przechowywany w systemie plików jako zwykłe pliki, których właścicielem jest root z uprawnieniami tylko do odczytu. Uznaje się to za wystarczające do ograniczenia dostępu do MOK do podpisywania przez złośliwych użytkowników lub skrypty, szczególnie biorąc pod uwagę, że żaden MOK nie istnieje w systemie, chyba że wymaga sterowników firm trzecich. Ogranicza to możliwość kompromitacji z powodu niewłaściwego użycia wygenerowanego klucza MOK do podpisania złośliwego modułu jądra. Jest to równoważne z kompromitacją aplikacji userland, która byłaby już możliwa z dostępem superużytkownika do systemu, a zabezpieczenie tego jest poza zakresem UEFI Secure Boot.

Poprzednie systemy mogły mieć wyłączoną walidację Secure Boot w shim. W ramach procesu aktualizacji, systemy te zostaną zmigrowane do ponownego włączenia sprawdzania poprawności Secure Boot w shim i zapisania nowego klucza MOK, jeśli dotyczy.

Proces generowania i podpisywania MOK

Proces generowania i podpisywania klucza jest nieco inny w zależności od tego, czy mamy do czynienia z zupełnie nową instalacją lub aktualizacją systemu poprzednio działającego Ubuntu; te dwa przypadki są wyraźnie zaznaczone poniżej.

We wszystkich przypadkach, jeśli system nie jest bootowanie w trybie UEFI, nie specjalne kroki podpisywania modułu jądra lub generowania klucza nastąpi.

Jeśli Secure Boot jest wyłączony, generowanie i zapisywanie MOK nadal ma miejsce, ponieważ użytkownik może później włączyć Secure Boot. System powinien działać poprawnie, jeśli tak się stanie.

Użytkownik instaluje Ubuntu na nowym systemie

Użytkownik przechodzi przez instalator. Na początku, podczas przygotowania do instalacji i tylko wtedy, gdy system wymaga modułów stron trzecich do pracy, użytkownik jest proszony o hasło systemowe, które jest wyraźnie oznaczone jako wymagane po zakończeniu instalacji, a podczas instalacji systemu, nowy MOK jest generowany automatycznie bez dalszej interakcji użytkownika.

Strony trzecie sterowniki lub moduły jądra wymagane przez system będą automatycznie budowane, gdy pakiet jest zainstalowany, a proces budowania zawiera krok podpisywania. Krok podpisywania automatycznie używa MOK wygenerowanego wcześniej do podpisania modułu, tak że może on być natychmiast załadowany po ponownym uruchomieniu systemu, a MOK jest zawarty w bazie danych zaufania systemu.

Po zakończeniu instalacji i ponownym uruchomieniu systemu, przy pierwszym starcie użytkownik jest prezentowany z programem MokManager (część zainstalowanego shim loadera), jako zestaw paneli w trybie tekstowym, które pozwalają użytkownikowi na zapisanie wygenerowanego MOK. Użytkownik wybiera „Enroll MOK”, pokazuje odcisk palca certyfikatu do zapisania i jest proszony o potwierdzenie zapisania. Po potwierdzeniu, nowy MOK zostanie wprowadzony do firmware, a użytkownik zostanie poproszony o ponowne uruchomienie systemu.

Po ponownym uruchomieniu systemu zostaną w razie potrzeby załadowane sterowniki innych firm podpisane przez właśnie zarejestrowany MOK.

Użytkownik aktualizuje system Ubuntu z obsługą UEFI do nowego wydania, gdzie system wymaga sterowników firm trzecich

Na aktualizacji, shim i shim-podpisane pakiety są aktualizowane. Zadania poinstalacyjne pakietu shim-signed kontynuują generowanie nowego MOK, i prosi użytkownika o hasło, które jest wyraźnie wymienione jako wymagane po zakończeniu procesu aktualizacji i ponownym uruchomieniu systemu.

Podczas uaktualnienia, pakiety jądra i moduły stron trzecich są uaktualniane. Moduły stron trzecich są przebudowywane dla nowych jąder i ich proces post-build kontynuuje automatyczne podpisywanie ich z MOK.

Po aktualizacji zaleca się użytkownikowi ponowne uruchomienie systemu.

Przy ponownym uruchomieniu, użytkownik jest prezentowany z programem MokManager (część zainstalowanego shim loadera), jako zestaw paneli w trybie tekstowym, które pozwalają użytkownikowi zapisać wygenerowany MOK. Użytkownik wybiera „Enroll MOK”, pokazuje mu się odcisk palca certyfikatu do zapisania i jest proszony o potwierdzenie zapisania. Użytkownik otrzymuje również monit o ponowne włączenie walidacji Secure Boot (w przypadku, gdy była ona wyłączona); MokManager ponownie wymaga potwierdzenia od użytkownika. Gdy wszystkie kroki zostaną potwierdzone, walidacja podkładek zostanie ponownie włączona, nowy MOK zostanie wprowadzony do firmware, a użytkownik zostanie poproszony o ponowne uruchomienie systemu.

Po ponownym uruchomieniu systemu, sterowniki innych firm podpisane przez właśnie wpisany MOK zostaną załadowane w razie potrzeby.

We wszystkich przypadkach, gdy system jest uruchomiony z włączonym UEFI Secure Boot i ostatnią wersją shim; instalacja jakiegokolwiek nowego modułu DKMS (sterownika innej firmy) przejdzie do podpisania zbudowanego modułu z MOK. Odbędzie się to bez interakcji użytkownika, jeśli ważny klucz MOK istnieje w systemie i wydaje się być już zarejestrowany.

Jeśli żaden MOK nie istnieje lub istniejący MOK nie jest zapisany, nowy klucz zostanie automatycznie utworzony tuż przed podpisaniem, a użytkownik zostanie poproszony o zapisanie klucza przez podanie hasła, które będzie wymagane przy ponownym uruchomieniu.