Ленарт Потеринг предложи нова архитектура за подигање потврдена со Линукс

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

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

Можноста за повикување од UEFI ви овозможува да користите проверка на интегритетот и валидноста на дигиталниот потпис што го опфаќа не само јадрото, туку и содржината на initrd. Во исто време, поддршката за повикување од традиционалните подигнувачи ви овозможува да зачувате функции како што се испорака на неколку верзии на кернелот и автоматско враќање на работен кернел во случај да се откријат проблеми со новото јадро по инсталирањето на ажурирањето.

Во моментов, повеќето дистрибуции на Линукс го користат синџирот „фирмвер → дигитално потпишан Microsoft shim слој → дигитално потпишана дистрибуција GRUB подигнувач → дигитално потпишана дистрибуција Линукс кернелот → непотпишана initrd околина → root FS“ во процесот на иницијализација. Недостатокот на initrd верификација во традиционалните дистрибуции создава безбедносни проблеми, бидејќи, меѓу другото, оваа средина извлекува клучеви за дешифрирање на root FS.

Верификацијата на сликата на initrd не е поддржана, бидејќи оваа датотека е генерирана на локалниот систем на корисникот и не може да се потврди со дигитален потпис на дистрибуцијата, што во голема мера ја отежнува организацијата на верификацијата при користење на режимот SecureBoot (за да се потврди initrd, на корисникот му треба да ги генерира неговите клучеви и да ги вчита во фирмверот на UEFI). Дополнително, постоечката организација за подигање не дозволува користење на информации од регистрите TPM PCR (Platform Configuration Register) за контрола на интегритетот на компонентите на корисничкиот простор, освен shim, grub и кернелот. Меѓу постојните проблеми, се споменува и компликацијата на ажурирањето на подигнувачот и неможноста да се ограничи пристапот до клучевите во TPM за постарите верзии на ОС кои станале ирелевантни по инсталирањето на ажурирањето.

Главните цели на имплементација на новата архитектура за подигање се:

• Обезбедување на целосно потврден процес на преземање, покривајќи ги сите фази од фирмверот до корисничкиот простор и потврдувајќи ја валидноста и интегритетот на преземените компоненти.
• Поврзување на контролираните ресурси со TPM PCR регистрите со поделба по сопственици.
• Способност да се пресметуваат вредностите на PCR врз основа на подигање на јадрото, initrd, конфигурација и локалниот системски ID.
• Заштита од напади на враќање поврзани со враќање на претходната ранлива верзија на системот.
• Поедноставете ја и подобрете ја веродостојноста на ажурирањата.
• Поддршка за ажурирања на ОС кои не бараат повторно примена или локално обезбедување ресурси заштитени со TPM.
• Подготвеност на системот за далечинско сертификација за да се потврди исправноста на бутабилниот оперативен систем и поставките.
• Способност да се прикачат чувствителни податоци на одредени фази на подигање, на пример, извлекување клучеви за шифрирање за root FS од TPM.
• Обезбедете безбеден, автоматски и тивок процес за отклучување клучеви за дешифрирање на диск со root партиција.
• Употреба на чипови кои ја поддржуваат спецификацијата TPM 2.0, со можност за враќање на системи без TPM.

Извор: opennet.ru