Lennart Pottering предложи нова Linux проверена архитектура за зареждане

Lennart Poettering публикува предложение за модернизиране на процеса на зареждане на Linux дистрибуции, насочено към решаване на съществуващи проблеми и опростяване на организацията на пълноценно проверено зареждане, потвърждаващо автентичността на ядрото и основната системна среда. Промените, необходими за внедряване на новата архитектура, вече са включени в кодовата база systemd и засягат компоненти като systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase и systemd-creds.

Предложените промени се свеждат до създаването на един универсален образ на UKI (Unified Kernel Image), който съчетава изображението на ядрото на Linux, манипулатора за зареждане на ядрото от UEFI (UEFI boot stub) и системната среда initrd, заредена в паметта, използвана за първоначална инициализация на етапа преди монтиране на root FS. Вместо initrd RAM дисково изображение, цялата система може да бъде пакетирана в UKI, което позволява създаването на напълно проверени системни среди, които се зареждат в RAM. UKI-образът е направен под формата на изпълним файл във формат PE, който може да се зарежда не само с помощта на традиционните зареждащи програми, но се извиква директно от фърмуера на UEFI.

Възможността за извикване от UEFI ви позволява да използвате проверка на целостта и валидността на цифровия подпис, която обхваща не само ядрото, но и съдържанието на initrd. В същото време поддръжката за извикване от традиционните зареждащи програми ви позволява да запазите такива функции като доставката на няколко версии на ядрото и автоматично връщане към работещо ядро, в случай че след инсталиране на актуализацията бъдат открити проблеми с новото ядро.

Понастоящем повечето дистрибуции на Linux използват веригата „фърмуер → цифрово подписан слой на Microsoft shim → дигитално подписана дистрибуция GRUB буутлоудър → дигитално подписана дистрибуция Linux ядро ​​→ неподписана initrd среда → root FS“ в процеса на инициализация. Липсата на initrd проверка в традиционните дистрибуции създава проблеми със сигурността, тъй като, наред с други неща, тази среда извлича ключове за дешифриране на основната FS.

Проверката на изображението initrd не се поддържа, тъй като този файл се генерира в локалната система на потребителя и не може да бъде сертифициран от цифровия подпис на разпространението, което значително усложнява организацията на проверката при използване на режим SecureBoot (за да провери initrd, потребителят трябва да генерира неговите ключове и да ги зареди във фърмуера на UEFI). В допълнение, съществуващата организация за зареждане не позволява използването на информация от регистрите на TPM PCR (Регистър за конфигурация на платформата) за контрол на целостта на компонентите на потребителското пространство, различни от shim, grub и ядрото. Сред съществуващите проблеми се споменава и усложнението при актуализиране на буутлоудъра и невъзможността за ограничаване на достъпа до ключове в TPM за по-стари версии на операционната система, които са станали без значение след инсталирането на актуализацията.

Основните цели на внедряването на новата архитектура за зареждане са:

  • Осигуряване на напълно проверен процес на изтегляне, обхващащ всички етапи от фърмуера до потребителското пространство и потвърждаване на валидността и целостта на изтеглените компоненти.
  • Свързване на контролирани ресурси към TPM PCR регистри с разделяне по собственици.
  • Възможност за предварително изчисляване на PCR стойности въз основа на зареждане на ядрото, initrd, конфигурация и локален системен идентификатор.
  • Защита срещу атаки за връщане, свързани с връщане към предишната уязвима версия на системата.
  • Опростете и подобрете надеждността на актуализациите.
  • Поддръжка за актуализации на ОС, които не изискват повторно прилагане или локално осигуряване на защитени с TPM ресурси.
  • Готовност на системата за дистанционно сертифициране за потвърждаване на коректността на стартиращата операционна система и настройките.
  • Възможността за прикачване на чувствителни данни към определени етапи на зареждане, например извличане на ключове за криптиране за основната FS от TPM.
  • Осигурете сигурен, автоматичен и безшумен процес за отключване на ключове за декриптиране на устройство с основен дял.
  • Използването на чипове, които поддържат спецификацията TPM 2.0, с възможност за връщане към системи без TPM.

Източник: opennet.ru

Добавяне на нов коментар