Какво е UEFI Secure Boot?

UEFI Secure boot е механизъм за проверка, който гарантира, че кодът, стартиран от фърмуера, е доверен.

Правилното и сигурно използване на UEFI Secure Boot изисква всеки двоичен файл, зареден при стартиране, да бъде валидиран спрямо известни ключове, разположени във фърмуера, които означават надеждни доставчици и източници за двоичните файлове, или доверени специфични двоични файлове, които могат да бъдат идентифицирани чрез криптографско хеширане.

Повечето хардуер x86 идва от фабрично предварително заредени ключове на Microsoft. Това означава, че обикновено можем да разчитаме на фърмуера на тези системи, за да се доверим на двоични файлове, подписани от Microsoft, а Linux общността силно разчита на това предположение, за да работи Secure Boot. Това е същият процес, използван например от Red Hat и SUSE.

Много ARM и други архитектури също поддържат UEFI Secure Boot, но може да не са предварително зареждане на ключове във фърмуера. При тези архитектури може да се наложи повторно подписване на зареждащи изображения със сертификат, който е зареден във фърмуера от собственика на хардуера.

Първоначален план за изпълнение:

Поддържани архитектури

amd64 : Двоичен файл с shim, подписан от Microsoft, и двоичен файл grub, подписан от Canonical, се предоставят в основния архив на Ubuntu като подписан с shim или grub-efi-amd64 .

arm64 : Към 20.04 („focal“), двоичен файл за shim, подписан от Microsoft, и двоичен файл grub, подписан от Canonical, се предоставят в основния архив на Ubuntu като подписан с shim или grub-efi-arm64 . Налице е GRUB бъг в процес на разследване , което трябва да бъде решен преди това работи край до край.

Как работи UEFI Secure Boot на Ubuntu

В Ubuntu всички предварително изградени двоични файлове, предназначени да бъдат заредени като част от процеса на зареждане, с изключение на изображението initrd, са подписани от UEFI сертификата на Canonical, който сам по себе си е имплицитно доверен, като е вграден в shim loader, самият подписан от Microsoft.

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

Докато системата се зарежда, фърмуерът зарежда подложката на shim, както е посочено в променливите BootEntry на фърмуера. Ubuntu инсталира свой собствен BootEntry по време на инсталацията и може да го актуализира всеки път, когато GRUB bootloader се актуализира. Тъй като двоичният файл на shim е подписан от Microsoft; той е валидиран и приет от фърмуера при проверка срещу сертификати, които вече присъстват във фърмуера. Тъй като двоичният файл на shim вгражда Canonical сертификат, както и собствена база данни за доверие, допълнителни елементи на зареждащата среда могат, освен че са подписани от един от приемливите сертификати, предварително заредени във фърмуера, да бъдат подписани от UEFI ключа на Canonical.

Следващото нещо, заредено от shim, е изображението от втори етап. Това може да бъде едно от двете неща: или GRUB, ако системата се зарежда нормално; или MokManager , ако се изисква управление на ключове, както е конфигурирано от променливите на фърмуера (обикновено се променя, когато системата е работила преди това).

При нормално зареждане; двоичният файл на GRUB (grub*.efi) се зарежда и се проверява неговото валидиране спрямо всички предишни известни надеждни източници. Двоичният файл GRUB за Ubuntu е подписан от ключа Canonical UEFI, така че е успешно валидиран и процесът на зареждане продължава.

Ако зареждането продължава с ключови задачи за управление, двоичният файл на MokManager (mm*.efi) се зарежда. Този двоичен файл има изрично доверие от shim, като е подписан от ефемерен ключ, който съществува само докато се създава двоичният файл на shim. Това означава, че само двоичният файл на MokManager, изграден с конкретна подложка, може да работи и ограничава възможността за компромис от използването на компрометирани инструменти. MokManager позволява на всеки потребител, присъстващ в системната конзола, да регистрира ключове, да премахва надеждни ключове, да регистрира двоични хешове и да превключва валидирането на Secure Boot на ниво shim, но повечето задачи изискват въвеждане на предварително зададена парола, за да се потвърди, че потребителят в конзолата наистина е лицето, което е поискало промени. Такива пароли оцеляват само при еднократно изпълнение на shim / MokManager; и се изчистват веднага след приключване или отмяна на процеса.След като управлението на ключове приключи, системата се рестартира и не продължава просто с зареждане, тъй като може да са необходими промени в управлението на ключовете за успешно завършване на зареждането.

След като системата продължи да се зарежда до GRUB; процесът GRUB зарежда всяка необходима конфигурация (обикновено зарежда конфигурация от ESP (EFI системен дял), сочеща към друг конфигурационен файл на основния или зареждащия дял), което ще го насочи към образа на ядрото за зареждане.

EFI приложенията до този момент, които имат пълен достъп до системния фърмуер, включително достъп до промяна на доверени променливи на фърмуера, ядрото за зареждане също трябва да бъде валидирано спрямо доверителната база данни. Официалните ядра на Ubuntu са подписани от Canonical UEFI ключа, те са успешно валидирани и контролът е предаден на ядрото. Initrd изображенията не са валидирани.

В случай на неофициални ядра или ядра, изградени от потребители, трябва да се предприемат допълнителни стъпки, ако потребителите желаят да заредят такива ядра, като същевременно запазят пълните възможности на UEFI Secure Boot. Всички ядра трябва да бъдат подписани, за да могат да се зареждат от GRUB, когато е активирано UEFI Secure Boot, така че потребителят ще трябва да продължи със собственото си подписване . Като алтернатива, потребителите може да искат да деактивират валидирането в shim, докато се стартират с активирано Secure Boot на официално ядро, като използват „sudo mokutil –disable-validation“, като предоставят парола при подкана и рестартират; или да деактивирате напълно защитеното зареждане във фърмуера.

До този момент всеки неуспех на валидиране на изображение за зареждане се среща с критична грешка, която спира процеса на зареждане. Системата няма да продължи зареждането и може автоматично да се рестартира след определен период от време, като се има предвид, че други променливи на BootEntry могат да съдържат зареждащи пътища, които са валидни и надеждни.

След като бъдат заредени, валидираните ядра ще деактивират Boot Services на фърмуера, като по този начин ще отпаднат привилегиите и ефективно ще преминат към потребителски режим; където достъпът до доверени променливи е ограничен само за четене. Предвид широките разрешения, предоставени на модулите на ядрото, всеки модул, който не е вграден в ядрото, също ще трябва да бъде валидиран при зареждане. Модулите, създадени и изпратени от Canonical с официалните ядра, са подписани от ключа Canonical UEFI и като такива са надеждни. Изработените по поръчка модули ще изискват от потребителя да предприеме необходимите стъпки за подписване на модулите, преди зареждането им да е разрешено от ядрото. Това може да бъде постигнато с помощта на командата 'kmodsign' [вижте {Как да се подпиша} раздел].

Неподписаните модули просто се отказват от ядрото. Всеки опит да ги вмъкнете с insmod или modprobe няма да успее със съобщение за грешка.

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

Как мога да направя неавтоматизирано подписване на драйвери?

Някои проекти може да изискват използването на персонализирани драйвери на ядрото, които не са настроени по такъв начин, че да работят с DKMS. В тези случаи хората трябва да се възползват от инструментите, включени в пакета, подписан с подложка: скриптът update-secureboot-policy е достъпен за генериране на нов MOK (ако вече не са създадени модули, създадени от DKMS).

Използвайте следната команда, за да регистрирате съществуващ ключ в shim:

sudo update-secureboot-policy –enroll-key

Ако няма MOK, скриптът ще излезе със съобщение за това. Ако ключът вече е регистриран, скриптът ще излезе, без да прави нищо. Ако ключът съществува, но не е показано, че е регистриран, потребителят ще бъде подканен да въведе парола, която да използва след рестартиране, така че ключът да може да бъде регистриран.

Човек може да генерира нов MOK, като използва следната команда:

sudo update-secureboot-policy –new-key

И след това запишете новосъздадения ключ в shim с споменатата по-рано команда за тази задача.

След това модулите на ядрото могат да бъдат подписани с командата kmodsign (вижте UEFI/SecureBoot/Подписване ) като част от техния процес на изграждане.

Последици за сигурността при управление на ключа на собственика на машина

MOK, генериран по време на инсталиране или при надстройка, е специфичен за машината и е разрешен само от ядрото или подложката за подписване на модули на ядрото, като се използва специфичен KeyUsage OID (1.3.6.1.4.1.2312.16.1.2), обозначаващ ограниченията на МОК.

Последните версии на shim включват логика да се следват ограниченията на ключовете само за подписване на модули. Тези ключове ще бъдат разрешени да бъдат записани във фърмуера в доверителната база данни на shim, но ще бъдат игнорирани, когато shim или GRUB валидират изображения за зареждане във фърмуера. Функцията verify () на Shim ще валидира успешно само изображения, подписани от ключове, които не включват „Само подписване на модул“ (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID. Ядрата на Ubuntu използват глобалната база данни за доверие (която включва както shim, така и фърмуера) и ще приемат всеки от включените ключове като ключове за подписване при зареждане на модули на ядрото.

Предвид ограниченията, наложени върху автоматично генерирания МОК и факта, че потребителите с достъп на суперпотребител до системата и достъп до системната конзола за въвеждане на паролата, необходима при записване на ключове, вече имат достъп на високо ниво до системата; генерираният MOK ключ се съхранява във файловата система като обикновени файлове, собственост на root с разрешения само за четене. Счита се, че това е достатъчно за ограничаване на достъпа до MOK за подписване от злонамерени потребители или скриптове, особено като се има предвид, че в системата не съществува MOK, освен ако не изисква драйвери на трети страни. Това ограничава възможността за компромис от злоупотреба с генериран MOK ключ до подписване на злонамерен модул на ядрото. Това е еквивалентно на компромис с приложенията на потребителската страна, който вече би бил възможен със суперпотребителски достъп до системата, а осигуряването на това е извън обхвата на UEFI Secure Boot.

Предишните системи може да са имали забранено валидиране на Secure Boot в shim. Като част от процеса на надстройка, тези системи ще бъдат мигрирани към повторно активиране на проверката на Secure Boot в shim и записване на нов MOK ключ, когато е приложимо.

Процес на генериране и подписване на MOK

Процесът на генериране и подписване на ключове е малко по -различен в зависимост от това дали имаме работа с чисто нова инсталация или с ъпгрейд на системата, работеща преди това с Ubuntu; тези два случая са ясно маркирани по -долу.

Във всички случаи, ако системата не се зарежда в режим UEFI, няма да се случат специални стъпки за подписване на модула на ядрото или генериране на ключ.

Ако защитеното зареждане е деактивирано, генерирането и записването на MOK все още се случва, тъй като по -късно потребителят може да активира защитеното зареждане. Системата им трябва да работи правилно, ако е така.

Потребителят инсталира Ubuntu на нова система

Потребителят преминава през инсталатора. В началото, когато се подготвя за инсталиране и само ако системата изисква модули на трети страни да работят, потребителят е подканен за системна парола, която е ясно маркирана като необходима след завършване на инсталацията, и докато системата се инсталира, новият MOK се генерира автоматично без допълнително взаимодействие с потребителя.

Драйверите на трети страни или модулите на ядрото, необходими на системата, ще бъдат автоматично изградени, когато пакетът е инсталиран, а процесът на изграждане включва стъпка за подписване. Стъпката за подписване автоматично използва MOK, генериран по -рано, за да подпише модула, така че да може да бъде зареден веднага след рестартиране на системата и MOK е включен в базата данни на системата за доверие.

След като инсталацията приключи и системата се рестартира, при първо зареждане на потребителя се представя програмата MokManager (част от инсталирания shim loader), като набор от панели за текстов режим, които всички потребители да регистрират генерирания MOK. Потребителят избира „Enroll MOK“, показва му се пръстов отпечатък на сертификата за записване и се подканва да потвърди записването. След като бъде потвърден, новият MOK ще бъде въведен във фърмуера и потребителят ще бъде помолен да рестартира системата.

Когато системата се рестартира, драйверите на трети страни, подписани от току-що записания МОК, ще бъдат заредени според нуждите.

Потребителят надгражда Ubuntu-активирана UEFI система до нова версия, където системата изисква драйвери на трети страни

При надстройка пакетите с подложка и подпис се подновяват. Задачите след инсталиране на пакета, подписани с shim, продължават да генерират нов MOK и подканват потребителя за парола, която е ясно посочена като необходима, след като процесът на надстройване приключи и системата се рестартира.

По време на надстройката пакетите на ядрото и модулите на трети страни се надграждат. Модулите на трети страни се възстановяват за новите ядра и процесът им след изграждането продължава автоматично да ги подпише с MOK.

След надстройка се препоръчва на потребителя да рестартира системата си.

При рестартиране, потребителят се представя с програмата MokManager (част от инсталирания shim loader), като набор от панели в текстов режим, които всички потребители да регистрират генерирания MOK. Потребителят избира „Enroll MOK“, показва му се пръстов отпечатък на сертификата за записване и се подканва да потвърди записването. Потребителят също получава подкана да разреши повторно валидиране на Secure Boot (в случай, че е установено, че е деактивиран); и MokManager отново изисква потвърждение от потребителя. След като всички стъпки бъдат потвърдени, валидирането на подложката се активира отново, новият MOK ще бъде въведен във фърмуера и потребителят ще бъде помолен да рестартира системата.

Във всички случаи, след като системата работи с активиран UEFI Secure Boot и с последна версия на shim; инсталирането на всеки нов DKMS модул (драйвер на трета страна) ще продължи да подписва вградения модул с MOK. Това ще се случи без взаимодействие с потребителя, ако в системата съществува валиден MOK ключ и изглежда, че вече е регистриран.

Ако няма MOK или съществуващият MOK не е записан, автоматично ще се създаде нов ключ точно преди подписването и потребителят ще бъде подканен да регистрира ключа, като предостави парола, която ще се изисква при рестартиране.

Благодарим ви за прочитането на статията! Ако намерихте информацията за полезна, можете да дарите посредством бутоните по-долу:

Donate ☕️ Дарете с PayPal Donate 💳 Дарете с Revolut