Леннарт Поттерінг запропонував нову архітектуру верифікованого завантаження 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, що завантажується в пам'ять, застосовується для початкової ініціалізації на стадії домонтування. Замість образу RAM-диска initrd в UKI може бути упакована і вся система, що дозволяє створювати повністю верифіковані системні оточення, які завантажуються в оперативну пам'ять. UKI-образ оформляється у вигляді файлу у форматі PE, який може бути завантажений не тільки за допомогою традиційних завантажувачів, і безпосередньо викликаний з прошивки UEFI.

Можливість виклику з UEFI дозволяє використовувати перевірку цілісності та достовірності цифрового підпису, що охоплює не тільки ядро, але й вміст initrd. Підтримка виклику з традиційних завантажувачів дозволяє зберегти такі можливості, як постачання кількох версій ядра та автоматичний відкат на робоче ядро ​​у разі виявлення проблем із новим ядром після встановлення оновлення.

В даний час у більшості дистрибутивів Linux в процесі ініціалізації використовується ланцюжок «прошивка → завірений цифровим підписом Microsoft shim-прошарок → завірений цифровим підписом дистрибутива завантажувач GRUB → завірене цифровим підписом дистрибутива ядро ​​Linux → не завірене оточення initrd → коренева ФС». Відсутність верифікації initrd у традиційних дистрибутивах створює проблеми з безпекою, оскільки серед іншого у цьому оточенні здійснюється вилучення ключів для розшифровки кореневої ФС.

Верифікація образу initrd не підтримується так як даний файл формується на локальній системі користувача і не може бути засвідчений цифровим підписом дистрибутива, що сильно ускладнює організацію перевірки при використанні режиму SecureBoot (для запевнення initrd користувачеві необхідно згенерувати свої ключі та завантажити їх у прошивку UEFI). Крім того, існуюча організація завантаження не дозволяє застосовувати інформацію з регістрів TPM PCR (Platform Configuration Register) для контролю цілісності компонентів простору користувача, крім shim, grub та ядра. З наявних проблем також згадується ускладнення оновлення завантажувача та відсутність можливості обмеження доступу до ключів у TPM для старих версій ОС, які стали неактуальними після інсталяції оновлення.

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

  • Надання повністю верифікованого процесу завантаження, що охоплює всі етапи від прошивки до простору користувача, і підтверджує достовірність і цілісність компонентів, що завантажуються.
  • Прив'язка контрольованих ресурсів до регістрів TPM PCR з розподілом по власникам.
  • Можливість попереднього розрахунку значень PCR на основі використовуваних під час завантаження ядра, initrd, конфігурації та локального ідентифікатора системи.
  • Захист від Rollback-атак, пов'язаних із відкатом на минулу вразливу версію системи.
  • Спрощення та підвищення надійності оновлень.
  • Підтримка оновлень ОС, які не потребують повторного використання або локальної підготовки ресурсів, захищених TPM.
  • Готовність системи для проведення віддаленої атестації для підтвердження коректності ОС, що завантажується, і налаштувань.
  • Можливість прикріплення конфіденційних даних до певних стадій завантаження, наприклад вилучення з TPM ключів шифрування для кореневої ФС.
  • Надання безпечного, автоматичного та працюючого без участі користувача процесу розблокування ключів для розшифрування диска з кореневим розділом.
  • Використання чіпів, що підтримують специфікацію TPM 2.0 з можливістю відкату на системи без TPM.

Джерело: opennet.ru

Додати коментар або відгук