co to jest UEFI Secure Boot ?

UEFI Secure boot jest mechanizmem weryfikacji zapewniającym, że kod uruchamiany przez firmware jest zaufany.

prawidłowe, Bezpieczne użycie UEFI Secure Boot wymaga, aby każdy załadowany podczas rozruchu plik binarny był sprawdzany pod kątem znanych kluczy znajdujących się w oprogramowaniu sprzętowym, oznaczających zaufanych dostawców i źródła dla plików binarnych lub zaufanych konkretnych plików binarnych, które można zidentyfikować za pomocą kryptograficznego hashowania.

większość sprzętu x86 pochodzi z fabrycznie załadowanych kluczy Microsoft. Oznacza to, że ogólnie możemy polegać na oprogramowaniu układowym tych systemów, aby zaufać binariom podpisanym przez Microsoft, a społeczność Linuksowa w dużej mierze opiera się na tym założeniu, aby Bezpieczne uruchamianie działało. Jest to ten sam proces używany na przykład przez Red Hat i SUSE.

wiele architektur ARM i innych również obsługuje UEFI Secure Boot, ale może nie być wstępnie wczytywanych kluczy w firmware. Na tych architekturach może być konieczne ponowne podpisanie obrazów rozruchowych certyfikatem załadowanym w oprogramowaniu sprzętowym przez właściciela sprzętu.

wstępny plan wdrożenia: plan wdrożenia.

Obsługiwane architektury

• amd64: binarny shim podpisany przez Microsoft i binarny grub podpisany przez Canonical są dostępne 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. Jest badany błąd GRUB, który musi zostać rozwiązany, zanim to zadziała od końca do końca.

testowanie bezpiecznego rozruchu UEFI

Jeśli jesteś zainteresowany testowaniem bezpiecznego rozruchu w systemie, zapoznaj się z instrukcjami tutaj: UEFI / SecureBoot / Testing.

jak działa UEFI Secure Boot na Ubuntu

na Ubuntu wszystkie wstępnie zbudowane pliki binarne przeznaczone do załadowania jako część procesu rozruchowego, z wyjątkiem obrazu initrd, są podpisane przez certyfikat UEFI firmy Canonical, który sam jest dorozumiany przez osadzenie w programie ładującym shim, sam podpisany przez Microsoft.

na architekturach lub systemach, w których fabrycznie załadowane certyfikaty podpisywania firmy Microsoft nie są dostępne lub załadowane w oprogramowaniu sprzętowym, użytkownicy mogą zastąpić istniejące podpisy na podkładkach lub grub i załadować je w dowolny sposób, weryfikując je na podstawie własnych certyfikatów zaimportowanych w oprogramowaniu sprzętowym systemu.

podczas uruchamiania systemu, firmware ładuje binarną warstwę shim zgodnie ze zmiennymi Firmware BootEntry. Ubuntu instaluje własną instalację startową w czasie instalacji i może ją aktualizować w każdej chwili, gdy bootloader GRUB zostanie zaktualizowany. Ponieważ binarny shim jest podpisany przez Microsoft; jest on sprawdzany i akceptowany przez oprogramowanie sprzętowe podczas weryfikacji z certyfikatami już obecnymi w oprogramowaniu sprzętowym. Ponieważ shim Binary osadza certyfikat Canonical, a także własną bazę danych zaufania, inne elementy środowiska rozruchowego mogą, oprócz podpisywania jednym z akceptowalnych certyfikatów wstępnie załadowanych w oprogramowaniu firmowym, być podpisywane kluczem UEFI firmy Canonical.

następną rzeczą ładowaną przez shim jest obraz drugiego stopnia. Może to być jedna z dwóch rzeczy: albo GRUB, jeśli system uruchamia się normalnie; lub MokManager, jeśli wymagane jest zarządzanie kluczami, skonfigurowane przez zmienne oprogramowania układowego (Zwykle zmieniane, gdy system był wcześniej uruchomiony).

Jeśli uruchamia się normalnie; binarny GRUB (grub*.efi) jest ładowany i jego Walidacja jest próbowana wobec wszystkich wcześniej znanych zaufanych źródeł. Plik binarny GRUB Dla Ubuntu jest podpisany przez Canonical UEFI key, więc jest pomyślnie sprawdzany i proces rozruchu trwa.

jeśli uruchamiasz, aby kontynuować zadania zarządzania kluczami, binarny MokManager (mm*.efi) jest załadowany. Ten binarny jest wyraźnie zaufany przez shim, ponieważ jest podpisany przez efemeryczny klucz, który istnieje tylko podczas budowania binarnego shim. Oznacza to, że tylko binarny MokManager zbudowany z określonego binarnego shim będzie mógł działać i ogranicza możliwość kompromisu z użyciem skompromitowanych narzędzi. MokManager pozwala każdemu użytkownikowi obecnemu w konsoli systemowej rejestrować klucze, usuwać zaufane klucze, rejestrować skróty binarne i przełączać bezpieczną weryfikację rozruchu na poziomie podkładki, ale większość zadań wymaga wprowadzenia wcześniej ustawionego hasła, aby potwierdzić, że użytkownik w konsoli jest rzeczywiście osobą, która zażądała zmian. Takie hasła przetrwają tylko w jednym uruchomieniu shim / MokManager i są usuwane po zakończeniu lub anulowaniu procesu. Po zakończeniu zarządzania kluczami system jest ponownie uruchamiany i nie tylko kontynuuje rozruch, ponieważ zmiany w zarządzaniu kluczami mogą być wymagane, aby pomyślnie zakończyć rozruch.

gdy system kontynuuje uruchamianie GRUB; proces GRUB ładuje dowolną wymaganą konfigurację (Zwykle ładuje konfigurację z ESP (partycja systemowa EFI), wskazując na inny plik konfiguracyjny na partycji głównej lub startowej), który wskazuje go na obraz jądra do załadowania.

aplikacje EFI do tej pory mając pełny dostęp do firmware systemu, w tym dostęp do zmieniających się zaufanych zmiennych firmware, jądro do załadowania musi również zostać zweryfikowane w bazie danych zaufania. Oficjalne jądra Ubuntu są podpisywane przez kanoniczny klucz UEFI, są pomyślnie walidowane, a kontrola jest przekazywana jądrowi. Obrazy Initrd nie są walidowane.

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ć ładowane przez GRUB, gdy UEFI Secure Boot jest włączony, więc użytkownik będzie musiał kontynuować podpisywanie. Alternatywnie, użytkownicy mogą chcieć wyłączyć walidację w shim podczas uruchamiania z włączonym Bezpiecznym rozruchem na oficjalnym jądrze, używając 'sudo mokutil –disable-validation’, podając hasło po wyświetleniu monitu i restartując; lub całkowicie wyłączyć Bezpieczne uruchamianie w oprogramowaniu układowym.

do tego momentu, każde niepowodzenie w walidacji obrazu do załadowania jest spełnione z krytycznym błędem, który zatrzymuje proces rozruchu. System nie będzie kontynuował rozruchu i może automatycznie uruchomić się ponownie po pewnym czasie, biorąc pod uwagę, że inne zmienne rozruchowe mogą zawierać ścieżki rozruchowe, które są poprawne i zaufane.

Po załadowaniu, zwalidowane jądra wyłączą usługi rozruchowe oprogramowania układowego, co spowoduje utratę uprawnień i skuteczne przejście do trybu użytkownika; gdzie dostęp do zaufanych zmiennych jest ograniczony tylko do odczytu. Biorąc pod uwagę szerokie uprawnienia nadane modułom jądra, każdy moduł nie wbudowany w jądro będzie również musiał zostać zweryfikowany podczas ładowania. Moduły zbudowane i dostarczane przez Canonical z oficjalnymi jądrami są podpisane kluczem UEFI Canonical i jako takie są zaufane. Niestandardowe moduły będą wymagały od użytkownika podjęcia niezbędnych kroków w celu podpisania modułów przed ich załadowaniem, które jest 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.

biorąc pod uwagę, że wielu użytkowników wymaga modułów innych firm, aby ich systemy działały poprawnie lub aby niektóre urządzenia działały; i że te moduły innych firm wymagają budowania lokalnie w systemie, który ma być dopasowany do działającego jądra, Ubuntu zapewnia narzędzia do automatyzacji i uproszczenia procesu podpisywania.

Jak mogę zrobić 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 pracować z DKMS. W takich przypadkach ludzie powinni skorzystać z narzędzi zawartych w pakiecie podpisanym przez shim: skrypt update-secureboot-policy jest dostępny do generowania nowego MOK (jeśli żadne Moduły zbudowane przez DKMS nie uruchomiły już takiego generowania).

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

sudo update-secureboot-policy --enroll-key

Jeśli MOK nie istnieje, skrypt zakończy działanie z Komunikatem o tym. Jeśli klucz jest już zarejestrowany, skrypt zakończy działanie, nic nie robiąc. Jeśli klucz istnieje, ale nie został zarejestrowany, użytkownik zostanie poproszony o podanie hasła do użycia po ponownym uruchomieniu, aby Klucz mógł zostać zarejestrowany.

można wygenerować nowy MOK za pomocą następującego polecenia:

sudo update-secureboot-policy --new-key

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

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

implikacje bezpieczeństwa w zarządzaniu kluczami właściciela maszyny

MOK generowany podczas instalacji lub aktualizacji jest specyficzny dla Maszyny i tylko przez jądro lub shim może podpisywać moduły jądra, przy użyciu określonego identyfikatora OID KeyUsage (1.3.6.1.4.1.2312.16.1.2) oznaczającego ograniczenia MOK.

najnowsze wersje shim zawierają logikę podążania za ograniczeniami kluczy tylko do podpisywania modułów. Klucze te będą mogły być zarejestrowane w firmware w bazie danych zaufania shim, ale będą ignorowane podczas sprawdzania poprawności obrazów shim lub GRUB do załadowania w firmware. Funkcja verify () Shima pomyślnie waliduje tylko obrazy podpisane przez klucze, które nie zawierają” tylko podpisywanie modułów ” (1.3.6.1.4.1.2312.16.1.2) KEYUSAGE OID. Jądra Ubuntu używają globalnej bazy danych zaufania (która zawiera zarówno shim, jak i firmware) i będą akceptować każdy z dołączonych kluczy jako klucze podpisywania podczas ładowania modułów jądra.

biorąc pod uwagę 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, aby wprowadzić hasło wymagane podczas rejestracji kluczy, mają już wysoki poziom dostępu do systemu; wygenerowany klucz MOK jest przechowywany w systemie plików jako zwykłe pliki należące do roota z uprawnieniami tylko do odczytu. Uważa się to za wystarczające, aby ograniczyć dostęp do MOK do podpisywania przez złośliwych użytkowników lub skrypty, zwłaszcza biorąc pod uwagę, że w systemie nie istnieje MOK, chyba że wymaga to sterowników innych firm. Ogranicza to możliwość kompromisu od niewłaściwego użycia wygenerowanego klucza MOK do podpisania złośliwego modułu jądra. Jest to równoznaczne z kompromitacją aplikacji userland, która byłaby już możliwa przy dostępie superużytkownika do systemu, a zabezpieczenie tego jest poza zakresem UEFI Secure Boot.

poprzednie systemy mogły mieć wyłączoną weryfikację bezpiecznego rozruchu w shim. W ramach procesu aktualizacji systemy te zostaną przeniesione do ponownego włączenia weryfikacji bezpiecznego rozruchu w shim i zarejestrowania nowego klucza MOK, jeśli ma to zastosowanie.

proces generowania i podpisywania MOK

proces generowania i podpisywania kluczy różni się nieco w zależności od tego, czy mamy do czynienia z zupełnie nową instalacją, czy aktualizacją systemu wcześniej działającego Ubuntu; te dwa przypadki są wyraźnie zaznaczone poniżej.

we wszystkich przypadkach, jeśli system nie uruchamia się w trybie UEFI, nie będą wykonywane żadne specjalne kroki podpisywania modułów jądra ani generowania kluczy.

Jeśli Secure Boot jest wyłączony, generowanie i rejestracja MOK nadal się dzieje, ponieważ użytkownik może później włączyć Bezpieczne uruchamianie. System powinien działać prawidłowo, jeśli tak jest.

użytkownik instaluje Ubuntu na nowym systemie

użytkownik przechodzi przez instalator. Na początku, przygotowując się do instalacji i tylko wtedy, gdy system wymaga modułów innych firm 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 z użytkownikiem.

sterowniki lub moduły jądra innych firm wymagane przez system zostaną automatycznie zbudowane po zainstalowaniu pakietu, a proces budowania obejmuje krok podpisywania. Krok podpisywania automatycznie wykorzystuje Mok wygenerowany wcześniej do podpisania modułu, tak że może on zostać natychmiast załadowany po ponownym uruchomieniu systemu, a MOK zostanie włączony do bazy zaufania systemu.

Po zakończeniu instalacji i ponownym uruchomieniu systemu, przy pierwszym uruchomieniu użytkownik jest prezentowany z programem MokManager (częścią zainstalowanego programu shim loader), jako zestaw paneli tekstowych, które wszyscy użytkownicy zapisują wygenerowany MOK. Użytkownik wybiera „Zapisz MOK”, wyświetla się odcisk palca certyfikatu, aby się zapisać, i jest monit o potwierdzenie rejestracji. Po potwierdzeniu, nowy MOK zostanie wprowadzony w firmware, a użytkownik zostanie poproszony o ponowne uruchomienie systemu.

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

użytkownik aktualizuje system Ubuntu z obsługą UEFI do nowej wersji, w której system wymaga sterowników innych firm

Po aktualizacji Pakiety Shim i Shim podpisane są uaktualniane. Zadania po instalacji pakietu podpisanego przez shim generują nowy MOK i monitują użytkownika o hasło, które jest wyraźnie wymienione jako wymagane po zakończeniu procesu aktualizacji i ponownym uruchomieniu systemu.

podczas aktualizacji Pakiety jądra i moduły innych firm są uaktualniane. Moduły innych firm są przebudowywane dla nowych jąder, a ich proces post-build przechodzi do automatycznego podpisywania ich za pomocą MOK.

Po aktualizacji zaleca się ponowne uruchomienie systemu.

Po ponownym uruchomieniu, użytkownik jest prezentowany z programem MokManager (część zainstalowanego shim loadera), jako zestaw paneli trybu tekstowego, które wszyscy użytkownicy zapisują wygenerowany MOK. Użytkownik wybiera „Zapisz MOK”, wyświetla się odcisk palca certyfikatu, aby się zapisać, i jest monit o potwierdzenie rejestracji. Użytkownik jest również wyświetlany z monitem o ponowne włączenie weryfikacji bezpiecznego rozruchu (w przypadku, gdy stwierdzono, że jest wyłączony); i MokManager ponownie wymaga potwierdzenia od użytkownika. Po potwierdzeniu wszystkich kroków Walidacja shim jest ponownie włączona, nowy MOK zostanie wprowadzony w firmware, a użytkownik zostanie poproszony o ponowne uruchomienie systemu.

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

we wszystkich przypadkach, gdy system jest uruchomiony z włączonym UEFI Secure Boot i najnowszą wersją shim; instalacja dowolnego nowego modułu DKMS (sterownik innej firmy) przystąpi do podpisania zbudowanego modułu z MOK. Stanie się to bez interakcji z użytkownikiem, jeśli w systemie istnieje ważny klucz MOK i wydaje się być już zarejestrowany.

Jeśli MOK nie istnieje lub istniejący MOK nie jest zarejestrowany, nowy klucz zostanie automatycznie utworzony tuż przed podpisaniem, a użytkownik zostanie poproszony o zarejestrowanie klucza, podając hasło, które będzie wymagane po ponownym uruchomieniu.