Lennart Pottering zaproponował nową zweryfikowaną architekturę rozruchową Linuksa

Lennart Poettering opublikował propozycję modernizacji procesu rozruchu dla dystrybucji Linuksa, mającą na celu rozwiązanie istniejących problemów i uproszczenie organizacji w pełni zweryfikowanego rozruchu, który potwierdza niezawodność jądra i podstawowego środowiska systemowego. Zmiany wymagane do wdrożenia nowej architektury są już zawarte w bazie kodu systemd i dotyczą komponentów takich jak systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase i systemd-creds.

Proponowane zmiany sprowadzają się do stworzenia jednego uniwersalnego obrazu UKI (Unified Kernel Image), łączącego obraz jądra Linuksa, procedurę ładowania jądra z UEFI (boot stub UEFI) oraz ładowane do pamięci środowisko systemu initrd, służące do wstępna inicjalizacja na etapie przed zamontowaniem głównego FS. Zamiast initrd obrazu dysku RAM, cały system można spakować w UKI, co pozwala na utworzenie w pełni zweryfikowanych środowisk systemowych ładowanych do pamięci RAM. Obraz UKI jest sformatowany jako plik wykonywalny w formacie PE, który można załadować nie tylko za pomocą tradycyjnych programów ładujących, ale można go wywołać bezpośrednio z oprogramowania układowego UEFI.

Możliwość wywołania z UEFI pozwala na sprawdzenie integralności podpisu cyfrowego, które obejmuje nie tylko jądro, ale także zawartość pliku initrd. Jednocześnie obsługa wywoływania z tradycyjnych programów ładujących pozwala zachować takie funkcje, jak dostarczanie kilku wersji jądra i automatyczne przywracanie działającego jądra w przypadku wykrycia problemów z nowym jądrem po zainstalowaniu aktualizacji.

Obecnie w większości dystrybucji Linuksa proces inicjalizacji wykorzystuje łańcuch „oprogramowanie sprzętowe → podpisana cyfrowo warstwa podkładkowa Microsoft → moduł ładujący GRUB podpisany cyfrowo przez dystrybucję → cyfrowo podpisane jądro Linuksa → niepodpisane środowisko initrd → root FS”. Brak weryfikacji initrd w tradycyjnych dystrybucjach stwarza problemy z bezpieczeństwem, ponieważ między innymi w tym środowisku pobierane są klucze do odszyfrowania głównego systemu plików.

Weryfikacja obrazu initrd nie jest obsługiwana, ponieważ plik ten jest generowany w lokalnym systemie użytkownika i nie może być poświadczony podpisem cyfrowym pakietu dystrybucyjnego, co znacznie komplikuje organizację weryfikacji podczas korzystania z trybu SecureBoot (w celu sprawdzenia initrd, użytkownik musi wygenerować własne klucze i załadować je do oprogramowania sprzętowego UEFI). Ponadto obecna organizacja rozruchu nie pozwala na wykorzystanie informacji z rejestrów TPM PCR (rejestr konfiguracji platformy) do kontrolowania integralności komponentów przestrzeni użytkownika innych niż podkładka, grub i jądro. Wśród istniejących problemów wymienia się także złożoność aktualizacji bootloadera oraz brak możliwości ograniczenia dostępu do kluczy w TPM dla starszych wersji systemu operacyjnego, które po zainstalowaniu aktualizacji stały się nieistotne.

Główne cele wprowadzenia nowej architektury ładowania to:

  • Zapewnienie w pełni zweryfikowanego procesu rozruchu, który rozciąga się od oprogramowania sprzętowego do przestrzeni użytkownika, potwierdzając ważność i integralność uruchamianych komponentów.
  • Łączenie kontrolowanych zasobów z rejestrami PCR TPM, wydzielonymi według właściciela.
  • Możliwość wstępnego obliczenia wartości PCR na podstawie jądra, initrd, konfiguracji i lokalnego identyfikatora systemu używanego podczas rozruchu.
  • Ochrona przed atakami typu rollback związanymi z cofaniem się do poprzedniej podatnej na ataki wersji systemu.
  • Uprość i zwiększ niezawodność aktualizacji.
  • Obsługa aktualizacji systemu operacyjnego, które nie wymagają ponownego zastosowania ani lokalnego udostępniania zasobów chronionych przez moduł TPM.
  • System jest gotowy do zdalnej certyfikacji w celu potwierdzenia poprawności załadowanego systemu operacyjnego i ustawień.
  • Możliwość dołączenia wrażliwych danych do niektórych etapów rozruchu, na przykład wyodrębnienia kluczy szyfrujących dla głównego systemu plików z modułu TPM.
  • Zapewnienie bezpiecznego, automatycznego i niewymagającego użytkownika procesu odblokowywania kluczy w celu odszyfrowania dysku z partycją główną.
  • Zastosowanie układów obsługujących specyfikację TPM 2.0 z możliwością przywrócenia ustawień do systemów bez modułu TPM.

Źródło: opennet.ru

Dodaj komentarz