Використовуємо Secure Boot в Linux на всю котушку



Технологія Secure Boot націлена на запобігання виконання недоверенного коду при завантаженні операційної системи, тобто захист від буткіти і атак типу Evil Maid. Пристрої з Secure Boot містять в енергонезалежній пам'яті базу даних відкритих ключів, якими перевіряються підписи завантажуваних UEFI-додатків на зразок завантажувачів ОС і драйверів. Додатки, підписані довіреною ключем і з правильною контрольною сумою, допускаються до завантаження, решта блокуються.
Більш детально про Secure Boot можна дізнатися з циклу статей від CodeRush.
Щоб Secure Boot забезпечував безпеку, підписуються додатки повинні дотримуватися певний «кодекс честі»: не мати в собі лазівок для необмеженого доступу до системи та параметрами Secure Boot, а також вимагати того ж від завантажуються ними додатків. Якщо підписана програма надає можливість недобросовісного використання безпосередньо або шляхом завантаження інших додатків, воно стає загрозою безпеки всіх користувачів, які довіряють цим додатком. Таку загрозу представляють завантажувач shim, що підписується Microsoft, і завантажується їм GRUB.
Щоб від цього захиститися, ми встановимо Ubuntu з шифруванням усього диска на базі LUKS і LVM, захистимо initramfs від змін, об'єднавши його з ядром в одне UEFI-додаток, і підпишемо його власними ключами.
Обмеження рішень «з коробки»
Ubuntu, як і інші поширені дистрибутиви, пропонує опцію шифрування всього диска з LVM під час установки. Дистрибутив у такій конфігурації без помилок встановлюється на UEFI з активним Secure Boot.
Але Canonical в першу чергу зацікавлена в працездатності ОС на пристрої з включеним Secure Boot, а не в забезпеченні безпеки за рахунок нього. Якщо ви хочете використовувати Secure Boot як засіб безпеки, то ви самі по собі.

Як Ubuntu реалізує завантаження Secure Boot з шифруванням усього диска і що з цим не так?

Red Hat розробили завантажувач shim, щоб він працював на всіх пристроях і служив на благо людству, дотримуючись суворі приписи стандарту Secure Boot і завантажуючи тільки довірені UEFI-додатки. Canonical використовує shim як проксі, вбудовуючи в нього свій публічний ключ і підписуючи у Microsoft. Shim завантажує GRUB, підписаний ключем Canonical, який потім завантажує ядро, підписану Canonical.
  • Почнемо з того, що шифрується не весь диск — /boot залишається незашифрованим, а значить і initramfs в ньому. Доступ до initramfs означає root-доступ. Fail.
  • /boot залишається незашифрованим, тому що встановлюється за замовчуванням GRUB не може розшифрувати диск без криптографічних модулів. Які чомусь не вбудували в підписаний GRUB. GRUB'у заборонено завантажувати додаткові модулі в Secure Boot. Double Fail1.
  • GRUB повинен верифікувати файли ядра і відкидати невірно підписані. Він цього не робить. Triple Fail.
  • GRUB завантажує свої налаштування з файлу і надає доступ до консолі. Справжність конфігураційного файлу не перевіряється, з допомогою його модифікації або через консоль можна зробити що завгодно: завантажити UEFI Shell, інше ядро, initramfs або передати аргументи ядру і отримати root-доступ. Fatal Error2.

Що це все означає?

Якщо у вашій системі є ключ Microsoft3, то хто завгодно може завантажитися з зовнішнього пристрою, встановити буткіт і отримати повний контроль над вашим пристроєм. Немає необхідність відключати Secure Boot: він вже не працює.


Згідно політиці Microsoft про підписання UEFI-додатків, всі підписані завантажувачі GRUB і shim, що використовуються для завантаження GRUB, вже повинні бути занесені в чорний список.
Говорите, потрібно просто відключити завантаження з зовнішніх пристроїв? Це боротьба з симптомами. Якщо у вас встановлений незахищений GRUB, то вас це не врятує. Якщо на вашому пристрої стоїть Windows, то ви можете вибрати з неї пристрій для завантаження, і є ймовірність, що ваша прошивка це дозволить4. Ще залишається PXE Network Boot. Допоможе лише пароль на включення пристрою.
Висновок
Необхідно відмовитися від чужих ключів. Користувач повинен контролювати Secure Boot. Завантажувач повинен бути підписаний користувач, усі незашифровані і доступні для запису елементи в завантаженні системи повинні верифікувати. Користувальницькі дані повинні бути зашифровані. Чого ми і спробуємо добитися.
Установка Ubuntu з шифруванням усього диска за допомогою LUKS і LVM
LUKS — Unified Linux Key Setup — обгортка для криптографічного системи dm-crypt, дозволяє створювати віртуальні зашифровані пристрою у файлах і на фізичних дисках. З допомогою LUKS можна зашифрувати дані на всьому диску для того, щоб перед завантаженням ОС потрібно ввести пароль.
LVM — Logical Volume Manager — менеджер логічних томів, з допомогою якого ми розділимо криптоконтейнер на тома. Тома LVM автоматично монтуються після введення пароля до криптоконтейнеру, окремий пароль для кожного тому не потрібно.
Наступні інструкції повинні бути застосовні до будь-якого дистрибутиву на базі Ubuntu, для інших потрібні корективи. Спершу завантажитеся з Live CD або інсталяційного образу в режимі Try before installing.

Розмітка і шифрування

Щоб завантажитися з диска в режимі UEFI, він повинен бути розміщений в форматі GPT. Розмітку диска розглянемо з допомогою KDE Partition Manager і GParted. Якщо у вас їх немає, встановіть один, відповідний вашому середовищі.
sudo apt-get install partitionmanager # KDE
sudo apt-get install gparted # GNOME та інші

Запустіть редактор розділів і оберіть диск, зазвичай це перший у системі /dev/sda. Подивіться властивості диска.
KDE Partition Manager: Два рази клікніть по диску,
GParted: View -> Device Information.

В рядку Partition table вказана використовувана таблиця розділів. Якщо диск розмічений у форматі dos/msdos (MBR), то його необхідно перетворити в GPT. Це можливо зробити без втрати даних, але тут я описувати не буду, пошукайте інструкції в інтернеті. Якщо на диску немає важливих даних і ви хочете відформатувати його в GPT, створіть нову таблицю.
KDE Partition Manager: New Partition Table — GPT
GParted: Device -> Create Partition Table — gpt

На диску повинен бути як мінімум один розділ ESP (EFI System Partition), в якому будуть зберігатися завантажувачі. Якщо на цьому диску не встановлена ОС в режимі UEFI, то один такий розділ вже є. У будь-якому випадку я рекомендую створити новий розміром не менше 100 МБ. ESP повинен бути відформатований в один з FAT-форматів, переважно в FAT32, а також позначений як завантажувальний.
KDE Partition Manager: Клікнути по нерозмічену області -> New
File system: fat32
Size: 128.00 MiB
Free space before: 0.00 — місце після таблиці GPT
ОК, Apply
Вибрати створений розділ і відкрити властивості (Properties), виставити прапор boot
ОК, Apply

GParted: Клікнути по нерозмічену області -> New
File system: fat32
New size: 128 MiB
Free space preceding: 1 MiB або більше — місце під таблицю GPT
Add, Apply
Вибрати створений розділ і відкрити управління прапорами (Manage Flags), виставити прапор boot
Close

Далі потрібно створити розділ для шифрування. Тим же чином, що і ESP, тільки без форматування (unformatted), виставлення прапорів і розміром побільше — так, щоб вмістив систему і розділ підкачки. Створимо в цьому розділі криптоконтейнер LUKS через термінал, попередньо перейшовши в режим суперкористувача.
sudo -i

Отформатируем розділ із зазначенням сучасних алгоритмів шифрування і хешування. В режимі XTS довжину ключа необхідно вказувати в два рази більше, тому для AES-256 потрібно вказати ключ довжиною 512 біт. Параметр
--iter-time
задає час в мілісекундах, що витрачається на генерацію ключа з введеного пароля функцією PBKDF2. Більша кількість ітерацій ускладнює перебір пароля, але і збільшує час очікування після введення правильного пароля.
cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 2000 /dev/sda2

Підтвердіть форматування, написавши YES, введіть пароль. Тепер відкрийте криптоконтейнер (sda2_crypt — ім'я для мапінгу) і введіть той самий пароль.
cryptsetup luksOpen /dev/sda2 sda2_crypt

Контейнер повинен стати доступним як блочний пристрій /dev/mapper/sda2_crypt. Перейдемо до розмітки логічних томів всередині криптоконтейнера. Ініціалізуємо фізичний розділ LVM поверх /dev/mapper/sda2_crypt.
pvcreate /dev/mapper/sda2_crypt

Всередині цієї фізичної розділу створимо групу томів з ім'ям ubuntu.
vgcreate ubuntu /dev/mapper/sda2_crypt

Тепер ми можемо створювати логічні томи всередині цієї групи. Першим ділом створимо тому для розділу підкачки і ініціалізуємо його. Рекомендований розмір — від sqrt(RAM) до 2xRAM в гігабайтах.
lvcreate -n swap -L 4G ubuntu # створити логічний том з міткою swap розміром 4 ГБ в групі ubuntu
mkswap /dev/ubuntu/swap

Додамо тому для кореня і створимо в ньому файлову систему ext4. Доброю практикою вважається залишати вільне місце і розширювати томи по мірі необхідності, тому виділимо для кореня 20 ГБ. За бажанням у вільному місці можна буде розмістити додаткові томи для home, usr, var і так далі. Виділити все вільне місце для тома можна за допомогою параметра
l 100%FREE
.
lvcreate -n root -L 20G ubuntu
mkfs.ext4 /dev/ubuntu/root

З розміткою закінчено, можна перейти до установки.

Установка

Так як ми плануємо створити завантажувач самостійно, так і установник Ubuntu не підтримує шифрування /boot, запустимо установку без створення завантажувача.
ubiquity -b

На етапі розмітки диска виберіть Вручну.
Тут нам необхідно вказати точки монтування. Вибрати /dev/mapper/ubuntu-root, вкажіть використання в якості журналируемой файлової системи Ext4, точку монтування (Mount Point) /, без форматування. Ubiquity сама підхопить /dev/mapper/ubuntu-swap, розділ підкачки і запам'ятає один із системних розділів EFI. Екран розмітки повинен виглядати так:


Закінчите установку і не перезагружайтесь.

Налаштування crypttab, fstab і resume

Змонтуйте корінь встановленої системи в /mnt, зв'яжіть /dev, /sys і /proc /mnt/dev, /mnt/sys і /mnt/proc відповідно, а також /etc/resolv.conf з /mnt/etc/resolv.conf, щоб у вас був доступ до мережі. Тепер змініть кореневий каталог за допомогою
chroot
.
mount /dev/ubuntu/root /mnt
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
mount --bind /etc/resolv.conf /mnt/etc/resolv.conf
chroot /mnt
mount -a # змонтувати ESP розділ /boot/efi автоматично, якщо він записаний установником у /etc/fstab

Вам необхідно вручну заповнити /etc/crypttab — файл, що описує монтовані при завантаженні криптоконтейнеры.
nano /etc/crypttab

У нього потрібно додати запис про /dev/sda2, що монтується в /dev/mapper/sda2_crypt. Налаштуємо монтування по UUID, а не по імені пристрою. Щоб дізнатися UUID /dev/sda2, відкрийте інший термінал і скористайтеся командою:
sudo blkid

В рядку, що починається з /dev/sda2, буде записаний його UUID. Скопіюйте його (Ctrl+Shift+C). В /etc/crypttab додайте запис виду имя_маппинга UUID=<UUID> none luks, вставивши UUID (Ctrl+Shift+V). Закрийте
nano
, натиснувши Ctrl+X і Y, підтвердивши збереження.


Перевірте, щоб у /etc/fstab були правильно описані монтовані розділи, а в /etc/initrmfs-tools/conf.d/resume вказаний розділ для пробудження з глибокого сну.


Після всіх змін оновіть образ initramfs.
update-initramfs -u

Не виходите з системи і
chroot
,
Створення завантажувача
Ядро Linux підтримує завантаження безпосередньо з UEFI, якщо воно було скомпільовано з параметром CONFIG_EFI_STUB. У такому разі initramfs зазвичай зберігається поруч у ESP, і шлях до нього передається в аргументах до ядра.
Однак відсутність верифікації initramfs дозволяє вбудувати в нього шкідливий код, маючи доступ на запис у ESP. Teddy Reed пропонує компілювати ядро, вбудовуючи в нього initramfs.
Процес компіляції ядра досить тривалий, її доведеться проводити після кожної зміни initramfs. На щастя, є інший спосіб. У пакеті
systemd
(раніше в
gummiboot
) перебуває linuxx64.efi.stub — заготівля UEFI-додатки, в яку можна вбудувати ядро, initramfs і аргументи, що передаються ядру. Підписавши це UEFI-додаток, ми захистимо ядро і initramfs від змін.
Для цієї операції потрібно пакет
binutils
.
sudo apt-get install binutils

Запишемо в /tmp/cmdline аргументи, які будуть передаватися ядра.
echo -n "quite splash" > /tmp/cmdline

В /boot зберігаються образи ядра (vmlinuz-*-generic) і initramfs (initrd.img-*-generic). Визначте останню версію і вбудуйте їх заготівлю.
objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-4.4.0-34-generic --change-section-vma .linux=0x2000000 \
--add-section .initrd=/boot/initrd.img-4.4.0-34-generic --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub ubuntu.efi

Отримане UEFI-додаток ubuntu.efi необхідно розташувати в ESP в каталозі EFI/BOOT/. Установник Ubuntu повинен був визначити ESP і налаштувати монтування в /boot/efi. Якщо в цьому ESP немає інших завантажувачів, то ubuntu.efi можна скопіювати в /boot/efi/EFI/BOOT/BOOTX64.EFI, тоді він буде завантажуватися при виборі цього розділу в меню завантаження UEFI.
mkdir -p /boot/efi/EFI/BOOT
cp ubuntu.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

Якщо ESP вже записаний завантажувач BOOTX64.EFI, то можна створити ще один ESP, або записати ubuntu.efi під іншим ім'ям і додати відповідну завантажувальну запис через вбудовану в вашу прошивку консоль UEFI (UEFI Shell). Використання
efibootmgr
не рекомендовано5.
Якщо у вас включений Secure Boot, то завантажитися з ubuntu.efi не вийде, так як він не підписаний. Вимкніть Secure Boot і завантажитеся, або продовжите з chroot.
Налаштування Secure Boot
Генерацію ключів, їх установку в прошивку і підписування UEFI-додатків описав CodeRush тут, тому я буду вважати, що ви все розумієте і вмієте.
Залишається тільки підписати створений нами завантажувач.
sbsign --key ISK.key --cert ISK.pem --output BOOTX64.EFI ubuntu.efi

Помістіть BOOTX64.EFI в каталог EFI/BOOT/ розділу EFI, з якого ви плануєте завантажуватися.

Автоматизація

Щоб завантажувач автоматично оновлювався і підписувався при оновленні initramfs, скрипт створіть update-efi-loader в /etc/initramfs/post-update.d/, змінивши шляху де потрібно.
echo -n "quiet splash" > /tmp/cmdline

objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-$(uname -r) --change-section-vma .linux=0x2000000 \
--add-section .initrd=/boot/initrd.img-$(uname -r) --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub /tmp/ubuntu.efi

sbsign --key /root/keys/ISK.key --cert /root/keys/ISK.pem --output /boot/efi/EFI/BOOT/BOOTX64.EFI /tmp/ubuntu.efi

Дайте скрипту право на виконання.
chmod a+x /etc/initramfs/post-update.d/update-efi-loader

При оновленні ядра доведеться провести цю операцію вручну.

Підписування драйверів і модулів ядра

Якщо вам потрібно встановити сторонні або власні драйвера і модулі ядра, їх необхідно підписати. Для підпису модулів ядра потрібні сертифікат у форматі DER і ключ без пароля, тобто згенерований з параметром
nodes
.
openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \
-subj "/CN=Kernel Key" -outform DER -out kernel.der \
-keyout kernel.key

Для підписування використовується скрипт
sign-file
.
/usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 kernel.key kernel.der module.ko

Щоб додати цей сертифікат в прошивку, його необхідно конвертувати у формат PEM, потім у ESL та підписати ключем KEK.
openssl x509 -inform der -in kernel.der -outform pem -out kernel.pem
cert-to-efi-sig-list -g "$(uuidgen)" kernel.pem kernel.esl
sign-efi-sig-list -k KEK.key -c KEK.pem kernel kernel.esl kernel.auth

Очевидні поради

Якщо вашим завданням стоїть захист даних на пристрої, то Secure Boot виконає свою роботу і не більше. Інше покладається на вас.
  • Не додавайте чужих ключів в прошивку. Навіть від Microsoft. В першу чергу від Microsoft.
  • Не підписуйте UEFI Shell, KeyTool або інші програми, які мають доступ до запису в NVRAM. Використовуйте їх в Setup Mode.
  • Не залишайте пристрій включеним без нагляду. Пристрій в режим очікування (suspend to RAM) містить в RAM розшифровані дані та майстер-ключі від криптоконтейнеров.
  • Встановіть пароль на UEFI Setup не простіше, ніж від вашого криптоконтейнера.
  • При фізичному доступі до нутрощів пристрою можна відключити Secure Boot, скинувши пам'ять NVRAM або пошкодивши її, а також залишити хардварную закладку. Така атака буде успішною лише тоді, коли вона непомітна. Зробіть так, щоб ви про неї могли дізнатися: заклейте гвинти на корпусі трудновоспроизводимыми стікерами, повапните їх лаком з блискітками. Опечатайте свій пристрій.
  • Поставте першим у списку завантаження непідписання додаток. Якщо ви одного разу не побачите повідомлення від Secure Boot, то ваш пристрій однозначно скомпрометовано.
  • Надійніше відключеного від інтернету пристрою, зберігається в сейфі, все одно нічого не придумаєш. Уразливості в реалізації Secure Boot в конкретних прошивках не виключені.
Бонус: повернення сну
При шифруванні всього диска замість режиму очікування для збереження стану і продовження роботи з місця зупинки зазвичай використовується гібернація, вона ж сплячий режим або suspend to disk.
З міркувань безпеки розробники ядра відключили можливість глибокого сну при включеному верифицировании модулів ядра. Аргументується це тим, що образ відновлення не перевіряється при пробудженні, розділ підкачки може бути підмінений і тоді система прокинеться з неперевіреними і потенційно шкідливим кодом.


Це вірно в тому випадку, якщо initramfs не перевіряється і/або розділ підкачки не зашифрований. Однак незалежно від використання сну при таких умовах initramfs може бути підмінений, а чутливі дані відновлені з розділу підкачки. В нашій конфігурації initramfs перевіряється, будучи включеним в підписаний завантажувальний файл, а розділ підкачки зашифрований. Отже, дане обмеження для нас безглуздо.
Chung-Yi Lee ще в 2013 запропонував верифікувати спосіб відновлення, а в 2015 представив реалізує його ідею патч. Але віз і нині там. Тому припустимо, що ми достатньо захищені з нашим шифруванням, і повернемо нам гібернацію без верифікації.

Спосіб 1. Відключити верифікацію модулів ядра

Включена верифікація модулів ядра відключає режим глибокого сну. За замовчуванням верифікація модулів ядра включається разом з Secure Boot, проте вона від Secure Boot не залежить. Її можна вимкнути, залишивши тільки Secure Boot.
Великої шкоди безпеці це нанести не повинно. Модулі ядра встановлюються з надійного джерела разом з оновленням ядра і зберігаються на зашифрованому диску і в верифицируемом initramfs. Сторонні драйвера встановлюються вручну, і вони будуть підписані нами чи ні, значення не має, адже ми їм довіряємо. SecureApt для ядра і SSL/HTTPS для сторонніх драйверів повинні захистити від MiTM, і тоді залишається тільки root-доступ до расшифрованному диску. Але в такому разі у зловмисника вже є наші дані.
«Залишити заявку» на відключення верифікації модулів можна за допомогою
mokutil
, а підтвердить її завантажувач
shim
.
sudo apt-get install mokutil shim
sudo mokutil --disable-validation

Введіть пароль, який потім потрібно посимвольно підтвердити. Тепер потрібно завантажитися через
shim
та вибрати в ньому Change Secure Boot state (sic!). Помістіть /usr/lib/shim.efi EFI/BOOT/BOOTX64.EFI на одному з ESP або додайте завантажувальну запис через UEFI Shell. Попередньо вимкніть Secure Boot, після поверніть назад.

Зараз Secure Boot і гібернація працюють, UEFI-додатки верифікуються, але модулі ядра немає.
В принципі,
shim
та
mokutil
не потрібні, їх можна видалити.


Спосіб 2. Використовувати стару версію ядра

Патч, що відключає гібернацію, з'явився у версії Ubuntu-4.4.0-18.34. Ubuntu-4.4.0-17.33 повинна бути від нього вільна. Однак залишатися на старому ядрі, ігноруючи оновлення безпеки, не кращий варіант.

Спосіб 3. Скомпілювати своє ядро

Якщо ваш час нічого не коштує, то ви можете скомпілювати своє ядро без цього обмеження. Гарантій, що після довгих мук ви будете задоволені результатом, немає. Але якщо ви цього дуже хочете, хвала Лінусу Торвальдсу і GPLv2, у вас є на це право. Ви можете попередньо протестувати скомпільований мною ядро, щоб не витрачати даремно час.
Інструкції

Отримання вихідного коду

apt-get
найпростіший спосіб отримати вихідний код ядра вашої версії — завантажити його з репозиторію.
/etc/apt/sources.list повинні бути покажчики на репозиторії вихідних кодів. Зазвичай там вже є закомментированные запису deb-src. Розкоментуйте їх для репозиторіїв xenial main і xenial-security main, або додайте самі, а потім оновіть індекс apt.
$ sudo nano /etc/apt/sources.list
...
deb-src http://ru.archive.ubuntu.com/ubuntu/ xenial main restricted
deb-src http://security.ubuntu.com/ubuntu xenial-security main restricted
...
$ apt-get update

Завантажити вихідний код і перейдіть в цю директорію.
apt-get source linux-image-$(uname -r)
cd linux-4.4.0

Зверніть увагу на те, щоб apt скачував актуальну версію вихідного коду. Перевірте номер версії файлу .dsc.
linux_4.4.0-34.53.dsc

git
Якщо ви хочете підтримувати ядро в актуальному стані і перекомпілювати його в міру виходу оновлень із збереженням своїх змін, виберіть git. Первісна завантаження займе тривалий час.
Встановіть git.
sudo apt-get install git

Створити локальну копію git-репозиторію ядра поточного релізу Ubuntu і перейдіть в цю директорію.
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git
cd ubuntu-xenial

За замовчуванням git вказує на гілку master, відповідну версії останнього релізу. Переключитися на іншу версію можна по тегу релізу цієї версії. Щоб перелічити всі теги по заданій масці, використовуйте
git tag -l <маска>
.
$ git tag -l Ubuntu-*
...
Ubuntu-4.4.0-33.52
Ubuntu-4.4.0-34.53
Ubuntu-4.4.0-35.54
...

Створіть гілку temp для тега, відповідного вашої версії, і перейдіть на неї.
git checkout -b temp Ubuntu-4.4.0-34.53

Налаштування

Завантажте пакети, необхідні для компіляції (build dependencies).
sudo apt-get build-dep
sudo apt-get ccache fakeroot kernel-package libncurses5-dev

Переконайтеся, що скриптам виставлено право на виконання, запустіть чистку.
chmod a+x debian/rules
chmod a+x debian/scripts/*
chmod a+x debian/scripts/misc/*
fakeroot debian/rules clean

Скопіюйте старий файл конфігурації в поточну директорію, запустіть конфігурацію, виберіть Load завантажити config. Більше нічого змінювати не потрібно, вийдіть і збережіть конфігурацію — Exit → Yes.
cp /boot/config-4.4.0-34-generic config
fakeroot debian/rules editconfigs

Змініть файл kernel/power/hibernate.c, прибравши перевірку secure_modules().
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -67,7 +67,7 @@ static const struct platform_hibernation_ops *hibernation_ops;

bool hibernation_available(void)
{
- return ((nohibernate == 0) && !secure_modules());
+ return (nohibernate == 0);
}

/**
--

Якщо ви використовуєте gitПідготуйте файл до коммиту.
git add kernel/power/hibernate.c

Якщо ви ще не здійснювали комітів і не вводили свої дані, зробіть це зараз.
git config --global user.email "you@example.com"
git config --global user.name "Your Name"

Зробіть комміт, введіть коментар.
$ git commit
...
Allow hibernation on Secure Boot

Тепер ваші зміни буде збережено у новому знімку стану (snapshot). Якщо ви захочете оновитися до наступної версії і застосувати до неї ті ж самі зміни, використовуйте
git rebase <гілка або тег>

$ git rebase Ubuntu-4.4.0-35.54
Спочатку перемотувати покажчик поточного коміта, щоб застосувати ваші зміни поверх нього...
Застосування: Allow hibernation on Secure Boot

Скрипти компіляції визначають версію ядра за останній запис в історії змін (changelog) в директорії debian.master. Щоб додати новий запис, щоб змінити версію.
EDITOR=nano debchange -c debian.master/changelog -l "custom"

До версії буде додано суфікс custom1, що позначиться при збірці пакунків .deb і дозволить встановити їх при вже встановлених пакетах тієї ж версії без суфікса. Однак цей суфікс поширюється тільки на ім'я пакета, але не на його вміст: ядро і директорія з його модулями будуть мати ту ж версію 4.4.0-34-generic, і при установці старі файли перезапишутся новими. Щоб цього уникнути, змініть версію ABI c 34 на, наприклад, 3400.
linux (4.4.0-3400.53custom1) UNRELEASED; urgency=medium

* Allow hibernation on Secure Boot
...

Компіляція

Запустіть чистку ще раз і скомпілюйте ядро. Якщо ви не досвідчений розробник ядра і не розумієте, як працюють перевірки ABI і модулів (я от не розумію), відключіть їх (skipabi=true, skipmodule=true), інакше ваша компіляція зламається на одному з останніх етапів. Тут використовується багатопотокова збирання пакетів з кількістю потоків, рівним кількості ядер процесора. Мета binary-generic означає компіляцію звичайної різновиди ядра, архітектура визначається автоматично.
fakeroot debian/rules clean
skipabi=true skipmodule=true DEB_BUILD_OPTIONS=parallel=$(getconf _NPROCESSORS_ONLN) do_tools=false no_dumpfile=1 \
fakeroot debian\rules binary-generic

Якщо компіляція пройшла успішно, то у вашій домашній директорії з'являться три пакета .deb. Необхідно встановити linux-image-<version>.deb, а також бажано linux-image-extra-<version>.deb. Це можна зробити за допомогою
dpkg -i <шлях до пакету>
або QApt, відкривши пакет у файловому менеджері, якщо він це підтримує. Будьте обережні: якщо ви не змінювали версію ABI, то старе ядро і модулі перезапишутся.
Знову зберіть завантажувальний файл.
echo -n "quiet splash" > /tmp/cmdline

objcopy \
--add-section .osrel=/etc/os-release --change-section-vma .osrel=0x20000 \
--add-section .cmdline=/tmp/cmdline --change-section-vma .cmdline=0x30000 \
--add-section .linux=/boot/vmlinuz-4.4.0-34-generic --change-section-vma .linux=0x2000000 \
--add-section .initrd=/boot/initrd.img-4.4.0-34-generic --change-section-vma .initrd=0x3000000 \
/usr/lib/systemd/boot/efi/linuxx64.efi.stub /tmp/test.efi

sbsign --key /root/keys/my.key --cert /root/keys/my.pem --output /boot/efi/EFI/BOOT/BOOTX64.EFI /tmp/test.efi


Гібернація працює, але нестабільно. Як, втім, і без Secure Boot.


Спосіб 4. Відмова від сну і використання віртуалізації

Якщо гібернація і працює, то це не робить її надійним засобом збереження стану. Це може бути проблемою мого заліза, дистрибутива або, що більш імовірно, KDE Plasma, але у мене Kubuntu прокидається через раз.
За вже описаною технологією в якості хостової ОС можна встановити відповідний дистрибутив Linux, а гостьовий бажану для роботи. При завершенні роботи автоматично зупиняти віртуальну машину із збереженням стану, а потім вимикати пристрій. При включенні ж відновлювати стан. Якщо ваш пристрій підтримує апаратну віртуалізацію, то для цього підійде
Qemu-KVM
. Але це вже тема для окремої статті.
З більшою надійністю прийде і більша захищеність: чутливі дані можна ізолювати від небезпечного середовища. Браузер та пісочниця для установки стороннних пакетів в одній віртуальній машині, важливі персональні дані — в іншій. Вкрасти майстер-ключ від зашифрованого диска в пам'яті хостової ОС з гостьової набагато складніше. Здається, для такого існує Qubes OS. Але вона даний момент не підтримує Secure Boot. Fail.
На цьому все, вітаються будь-які доповнення та зауваження.
Примітки
  1. можна Вирішити шляхом складання образу GRUB з потрібними модулями за допомогою
    grub-mkstandalone
    , але його доведеться підписувати самому.
  2. Теоретично можна виправити, встановивши пароль, вмонтувавши grub.cfg в образ GRUB з допомогою
    grub-mkstandalone
    і встановивши в grub.cfg prefix на невалидный шлях, щоб GRUB не міг знайти другий grub.cfg на диску. Але знову ж таки потрібно підписувати образ самостійно.
  3. А він є у всіх, крім параноїківвиправдано стурбованих своєю безпекою користувачів.
  4. У мене завантажитися з USB не дає. Windows 8 та 10 також без пароля не пускають в безпечний режим або консоль.
  5. Кажуть, деякі прошивки він окирпичивает. Безпечніше створити за ESP на кожен завантажувач.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.