Используем Secure Boot в Linux на всю катушку / Хабр

Сначала немного теории

UEFI видит только один специальный ESP-раздел, обычно он имеет размер 100-200 мегабайт и форматирован в FAT32 (бывает в FAT16), в нем содержаться папки с названиями а-ля Boot, Microsoft, Fedora, Ubuntu и т.д. Если вы перепробовали достаточное количество ОС и никогда не форматировали этот раздел, то там могло набраться приличное количество папок. К примеру, у меня было 2 живых оси и лежало около 6 папок.

P.S.CodeRush подсказал, что поддерживаются все FS, если на них есть соответствующие драйверы:

Это неверно. UEFI видит все разделы, для ФС которых в конкретной реализации прошивки имеются драйверы. ESP же отличается от остальных разделов только тем, что а) для FAT драйвер иметь обязательно и б) на разделе ESP осуществляется поиск загрузчиков и автоматическое создание соответсвующих переменных BootXXXX, если загрузчики нашлись.

В самих папках лежат исполняемые файлы .efi которые и выступают в роли загрузчиков ОС. В папке debian вы наверняка обнаружите файл grubx64.efi, а в папке Microsoft – bootmgr.efi.

Большинство Linux-дистрибутивов монтируют ESP-раздел к /boot/efi, то есть загрузчик Debian будет лежать примерно на таком пути: /boot/efi/EFI/debian/grubx64.efi

C директорией разобрались, а что дальше?

Что это всё означает?

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

Согласно политике Microsoft о подписывании UEFI-приложений, все подписанные загрузчики GRUB и shim, используемые для загрузки GRUB, уже должны быть занесены в чёрный список.

Говорите, нужно просто отключить загрузку с внешних устройств? Это борьба с симптомами. Если у вас установлен незащищённый GRUB, то вас это не спасёт. Если на вашем устройстве стоит Windows, то вы можете выбрать из неё устройство для загрузки, и есть вероятность, что ваша прошивка это позволит4. Ещё остаётся PXE Network Boot. Поможет только пароль на включение устройства.

Dirtycow (cve-2021-5195)

Простыми словами dirtycow (рабочий эксплойт под Android) позволяет заменить память любого процесса (полезно, если хорошо знаешь ASM) или любой доступный для чтения файл, даже если он находится на readonly файловой системе. Желательно, чтобы подменяемый файл был меньше либо равен по размеру заменяемому.

Основная атака в dirtycow для Android — подмена /system/bin/run-as — подобие sudo для отладки приложений. Начиная с API android-19 (таблица соответствия версий API и Android) /system/bin/run-as имеет CAP_SETUID и CAP_SETGID capabilities флаги (в старых версиях используется обычный suid bit — 6755).

$ getcap bin/run-as 
bin/run-as = cap_setgid,cap_setuid ep

Если файловая система будет примонтирована в режиме read-write, то всё, что dirtycow подменяет, окажется на файловой системе. Потому необходимо сделать backup оригинального файла и восстановить его после получения доступа, либо не перемонтировать файловую систему в режиме read-write. Как правило раздел /system в Android по умолчанию примонтирован в режиме read-only.

Не зря dirtycow считается одной из серьезнейших уязвимостей, обнаруженных в Linux. И при наличии знаний с помощью dirtycow можно обойти все уровни защиты ядра, в том числе и SELinux.

Hooks

Kyocera долго не думала, а просто запилила хуки на потенциально опасные операции в Android: mount, umount, insmod (к загрузке разрешен всего один модуль — wlan и только если его загрузит init процесс), и прочее.

Вот где крылась проблема recovery. Он не мог отмонтировать файловую систему /system! Эти операции позволялись только init процессу. В том числе я не мог отключить SELinux потому что эта возможность была отключена при компиляции ядра. Обойти эти хуки можно было только, если ядро загружено с определенными параметрами (kcdroidboot.mode=f-ksg или androidboot.mode=kcfactory, о них чуть позже).

Root, да не тот

Первое, что я сделал это использовал dirtycow по прямому назначению — подменил /system/bin/run-as, который задал UID/GID в 0 (тоже самое делает su). Однако монтировать файловую систему я не мог, даже tmpfs. Загружать модули ядра я тоже не мог.

Просматривать dmesg — нет. Я даже не мог просматривать директории, которые имели права 700 и принадлежали другим системным пользователям. Я мог лишь читать и писать в блочные устройства, а просмотр файлов или директорий был возможен благодаря заданию UID/GID определенного пользователя (написал свой велосипед — аналог su, который мог задавать selinux context и пользователя/группу).

Первым делом я сделал дамп всей прошивки, boot и recovery:

Бонус: возвращение гибернации

При шифровании всего диска вместо ждущего режима для сохранения состояния и продолжения работы с места остановки обычно используется гибернация, она же спящий режим или suspend to disk.

Из соображений безопасности разработчики ядра отключили возможность гибернации при включённом верифицировании модулей ядра. Аргументируется это тем, что образ восстановления не верифицируется при пробуждении, раздел подкачки может быть подменён и тогда система проснётся с непроверенным и потенциально вредоносным кодом.

Это верно в том случае, если initramfs не верифицируется и/или раздел подкачки не зашифрован. Однако независимо от использования гибернации при таких условиях initramfs может быть подменён, а чувствительные данные восстановлены из раздела подкачки. В нашей конфигурации initramfs верифицируется, будучи включённым в подписанный загрузочный файл, а раздел подкачки зашифрован. Значит, данное ограничение для нас бессмысленно.

Chung-Yi Lee ещё в 2021 предложил верифицировать образ восстановления, а в 2021 представил реализующий его идею патч. Но воз и ныне там. Поэтому предположим, что мы достаточно защищены с нашим шифрованием, и вернём нам гибернацию без верификации.

Всё очень страшно и откуда у меня столько ос?

Да, всё страшно, пока. На самом деле ОС у вас всего две. Просто rEFInd собрал все .efi-бинарники и ещё отобразил ОС с возможностью загрузки напрямую. Для исправления этого недоразумения мы удалим лишнее, напишем свой конфиг и поставим красивую тему на rEFInd.

Первым делом зайдите в Linux, выбрав один из рабочих пунктов загрузки. В меню должен быть пункт для загрузки БЕЗ использования grubx64.efi! В разделе /boot проще работать из под администратора (потому у команду cd не хватает привелегий, а sudo она не работает), так что su и вводим пароль root’а.

Этот пункт не зря опциональный, потому что если у вас недостаточно опыта, то можно очень просто что-то сломать и не заметить. Рекомендую подготовить флешку с рабочим LiveCD, чтобы проводить восстановление, в случае неожиданностей.

Наша первая задача — удалить лишние директивы загрузки, их запросто может быть штук 6, а системы всего две.

Заходим в директорию:cd /boot/efi/EFI && lsВероятно тут будет пять папок:BOOT, microsoft, <ваш дистрибутив>, refind и tools.Если будет что-то лишнее — смело удаляйте.

Способ 1 (через очищение, опаснее):Убедившись что вы загрузились через rEFInd (!) и НЕ использовали для этого GRUB можете смело удалить папку вашего дистрибутива. Перезагрузитесь и проверьте, можете ли вы загрузиться в ваш Linux.

Если можете, то вероятно в меню загрузки осталось 4 директивы: Windows, Linux и два странных пункта, которые приводят (скорее всего) к загрузке Linux. Можно было догадаться, что это .efi-бинарники из папки EFI/BOOT. Папку можно удалить полностью. НО! Убедитесь, что у вас есть бэкап. Перазагружаемся. Всё отлично?

Удаляем GRUB:sudo apt-get remove grub2 grub2-efi grub grub-efiИли:sudo dnf remove grub2

Теперь можно ставить тему.

Некоторые UEFI другие директории вовсе не видят. Поэтому небольшой work around для таких систем существует. Удаляем папку BOOT, переименовываем папку refind в папку BOOT, а также сам файл refind_x64.efi в bootx64.efi. Перезагружаемся.

Способ 2 (через конфиг rEFInd, безопаснее):Этот способ гораздо безопаснее, потому что удалять и что либо трогать мы не будем, мы добьемся резальтата правильной настройкой конфига. Сам конфиг лежит тут: /boot/efi/EFI/refind/refind.confЧтобы настроить свой набор директив загрузки нужно использовать два параметра scanfor и menuentry, после настройки должен получится примерно такой конфиг:

# Сканируем записи созданные ручкуами, флешки и оптически приводыscanfor manual,external,optical# Пункт для загрузки Linuxmenuentry Linux {loader /EFI/ubuntu/grubx64.efiicon /EFI/refind/icons/os_linux.png}# Пункт для загрузки Windows 10menuentry “Windows 10” {loader EFIMicrosoftBootbootmgr.efiicon /EFI/refind/icons/os_win.png}

Разумеется это только часть конфига, другие параметры можно взять из примера

Мой конфиг на базе первого способа с комментариями

# Ожидание в секундах перед авто-выбором ОСtimeout 20# Скринсервер через 300 секунд, если ничего не выбрали, # но нажали любую клавишу и отменили автовыборscreensaver 300# Разрешение бут-менеджераresolution 1280 1024# Использовать графику при загрузке Linux.

Этот параметр позволит загружать ОС с красивой Plymouth# заставкой в разрешении указанном вышеuse_graphics_for linuxscanfor internal,external,optical,netboot,biosexternal# Подключение темыinclude themes/refind-theme-regular/theme.conf

Отдельно про Plymouth можно почитать здесь.

Включение красивой темы

До dual boot буквально один шаг

В отличии от Windows большинство дистрибутивов имеют отличную индикацию UEFI-режима. К примеру Debian в своем установщике черным по белому пишет, что система запущенна в UEFI-mode. Другие дистрибутивы проявляют это странным grub-загрузчиком, который выглядит «как-то не так».

Думаю если вы собрались ставить Linux, то вы наверняка сами знаете как ставить ваш любимый дистрибутив, поэтому я не буду заострять внимание на подробностях установки отдельно взятого дистрибутива. Потому что этот этап до боли прост. Если вы уже действительно прогрузились в UEFI-режиме и установили Windows как надо, то Dual Boot уже практически в кармане.

Итак всё что вам потребуется сделать при установке Linux:Выбрать раздел /dev/sda2 (в вашем случае это может быть другой раздел) и указать точку монтирования — /boot/efi. Всё. Нет, правда, всё. Разумеется не забудьте разметить ext4 / Btrfs / ReiserFS / XFS / JFS раздел, примонтировать его в корень /.

Данная логика была проверена во всех вышеозначенных дистрибутивах. То есть повторюсь ещё раз: Главное показать вашему дистрибутиву где у вас этот заветный ESP-раздел и куда надо ему кидать загрузчик. Он его не форматирует, а просто добавляет GRUB. А вот уже сам GRUB вершит магию, изменяет приоритеты загрузки и т.д. Замечу, что некоторые дистрибутивы сами монтируют этот раздел куда надо, так как видят флаги ESP и BOOT. К примеру в установщике Debian нужно просто создать пользовательский раздел и всё.

Использование недорогих 10/40 гбит/с сетевых адаптеров с интерфейсом hp flexiblelom

Для соединения пары домашних серверов мне захотелось выйти за пределы привычных 1Гбит/с и при этом сильно не переплачивать за сетевое оборудование. На известном сайте были приобретены недорогие серверные адаптеры HP 764285-B21, по сути являющиеся ОЕМ аналогами Mellanox ConnectX-3 Pro, и QSFP медный кабель (DAC). Эти двухпортовые адаптеры могут работать на скоростях 10 и 40 Гбит/с в режиме Ethernet портов и до 56 Гбит/с в режиме InfiniBand. Низкая цена на вторичном рынке обусловлена нестандартным интерфейсом HP FlexibleLOM, разъем которого хотя и похож на стандартный PCIe x8, но имеет иное расположение линий PCIe и поэтому может использоваться только в совместимых серверах HP. Тем не менее выход есть – Tobias Schramm спроектировал специальный адаптер для установки карт HP FlexibleLOM в обычный слот PCIe. Я заказал платы адаптера на jlcpcb.com и 8х коннекторы на алиэкспресс. После монтажа коннектора на плату адаптера и установки всей конструкции в слот она успешно определилась как устройство на шине PCIe:

lspci | grep Mellanox
23:00.0 Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 Pro]

Однако после установки Ethernet драйвера Mellanox (я использовал Ubuntu 16.04 и 20.04, предполагаю для других версий и для Windows порядок действий будет аналогичен) Ethernet интерфейсы не появились в системе. Это означало, что драйвер по какой-либо причине не смог распознать адаптер и скорее всего потребуется перепрошивка. Изучая вывод dmesg можно примерно установить причину ошибки, в моём случае в прошивке адаптеров была включена опция SR-IOV, несовместимая с используемой материнской платой.

Для перепрошивки адаптера скачиваем и распаковываем Mellanox firmware tools для вашей ОС. Установку производим с ключом –oem (sudo ./install –oem), это позволит сразу установить дополнительные утилиты для сборки новой прошивки.

После установки MFT определяем текущую версию прошивки:

mlxfwmanager -d 23:00.0
Querying Mellanox devices firmware ...

Device #1:
----------

  Device Type:      ConnectX3Pro
  Part Number:      764285-B21_Ax
  Description:      HP InfiniBand FDR/Ethernet 10Gb/40Gb 2-port 544 FLR-QSFP Adapter
  PSID:             HP_1380110017
  PCI Device Name:  23:00.0
  Port1 MAC:        24be05c557c1
  Port2 MAC:        24be05c557c2
  Versions:         Current        Available     
     FW             2.42.5700      N/A           

  Status:           No matching image found

…и делаем бэкап текущей прошивки и конфигурации адаптера:

flint -d 23:00.0 ri original_firmware.bin
flint -d 23:00.0 dc original_config.ini

Изучив раздел [HCA] файла конфигурации находим требуемый параметр sriov_en и, предварительно скопировав конфигурацию в новый файл new_config.ini, выставляем ему нулевое значение. Также проверяем, что eth_xfi_en равен единице – это позволит активировать Ethernet режим портов:

[HCA]
...
eth_xfi_en = 1
sriov_en = 0
...

Далее нам потребуется исходный файл прошивки .mlx для нашего чипсета (в моём случае это ConnectX-3 Pro), как выяснилось раньше их можно было свободно скачать с сайта Mellanox, однако сейчас лавочку прикрыли, оставив только готовые бинарные прошивки, которые, к сожалению, нам не подходят. В результате поисков мне удалось найти прямую ссылку на скачивание исходной прошивки предыдущей версии 2.36:

wget http://www.mellanox.com/downloads/firmware/ConnectX3Pro-rel-2_36_5000-web.tgz

Распаковываем архив и извлекаем искомый fw-ConnectX3Pro-rel.mlx, затем собираем новую прошивку с помощью mlxburn:

mlxburn -fw fw-ConnectX3Pro-rel.mlx -conf new_config.ini -wrimage new_firmware.bin

На всякий случай проверяем новую прошивку:

flint -i new_firmware.bin verify

     FS2 failsafe image. Start address: 0x0. Chunk size 0x80000:

     NOTE: The addresses below are contiguous logical addresses. Physical addresses on
           flash may be different, based on the image start address and chunk size

     /0x00000038-0x0000065b (0x000624)/ (BOOT2) - OK
     /0x0000065c-0x00002b9b (0x002540)/ (BOOT2) - OK
     /0x00002b9c-0x00003b27 (0x000f8c)/ (Configuration) - OK
     /0x00003b28-0x00003b6b (0x000044)/ (GUID) - OK
     /0x00003b6c-0x00003cc3 (0x000158)/ (Image Info) - OK
     /0x00003cc4-0x00010fc3 (0x00d300)/ (DDR) - OK
     /0x00010fc4-0x00012027 (0x001064)/ (DDR) - OK
     /0x00012028-0x000123f7 (0x0003d0)/ (DDR) - OK
     /0x000123f8-0x0005008b (0x03dc94)/ (DDR) - OK
     /0x0005008c-0x00054f0f (0x004e84)/ (DDR) - OK
     /0x00054f10-0x00059103 (0x0041f4)/ (DDR) - OK
     /0x00059104-0x00059bfb (0x000af8)/ (DDR) - OK
     /0x00059bfc-0x0008915f (0x02f564)/ (DDR) - OK
     /0x00089160-0x0008cd0b (0x003bac)/ (DDR) - OK
     /0x0008cd0c-0x000a1d7f (0x015074)/ (DDR) - OK
     /0x000a1d80-0x000a1e87 (0x000108)/ (DDR) - OK
     /0x000a1e88-0x000a6a8b (0x004c04)/ (DDR) - OK
     /0x000a6a8c-0x000a827b (0x0017f0)/ (Configuration) - OK
     /0x000a827c-0x000a82ef (0x000074)/ (Jump addresses) - OK
     /0x000a82f0-0x000a8e03 (0x000b14)/ (FW Configuration) - OK
     /0x00000000-0x000a8e03 (0x0a8e04)/ (Full Image) - OK

-I- FW image verification succeeded. Image is bootable.

…и затем прошиваем в адаптер:

flint -d 23:00.0 -i new_firmware.bin -allow_psid_change burn

    Current FW version on flash:  2.42.5700
    New FW version:               2.36.5000

    Note: The new FW version is older than the current FW version on flash.

 Do you want to continue ? (y/n) [n] : y

Burning FS2 FW image without signatures - OK  
Restoring signature                     - OK

После перепрошивки адаптера обязательно перезагружаем сервер.

В моём случае после всех вышеперечисленных манипуляций драйвер mlx4_core успешно распознал адаптер и сетевые интерфейсы появились в системе. Для ускорения процесса загрузки я дополнительно отключил boot options:

mlxconfig -d 23:00.0 set BOOT_OPTION_ROM_EN_P1=false
mlxconfig -d 23:00.0 set BOOT_OPTION_ROM_EN_P2=false
mlxconfig -d 23:00.0 set LEGACY_BOOT_PROTOCOL_P1=0
mlxconfig -d 23:00.0 set LEGACY_BOOT_PROTOCOL_P2=0

…и удалил BootROM:

flint -d 23:00.0 --allow_rom_change drom

Кроме того, если не планируется использование интерфейсов InfiniBand, можно принудительно перевести оба порта в режим Ethernet:

mlxconfig -d 23:00.0 set LINK_TYPE_P1=2
mlxconfig -d 23:00.0 set LINK_TYPE_P2=2

Компиляция

Запустите чистку ещё раз и скомпилируйте ядро. Если вы не опытный разработчик ядра и не понимаете, как работают проверки ABI и модулей (я вот не понимаю), отключите их (skipabi=true, skipmodule=true), иначе ваша компиляция сломается на одном из последних этапов.

fakeroot debian/rules clean
skipabi=true skipmodule=true DEB_BUILD_OPTIONS=parallel=$(getconf _NPROCESSORS_ONLN) do_tools=false no_dumpfile=1 
fakeroot debianrules binary-generic

Если компиляция прошла успешно, то в вашей домашней директории появятся три пакета .deb. Необходимо установить linux-image-<version>.deb, а также желательно linux-image-extra-<version>.deb. Это можно сделать с помощью dpkg -i <путь к пакету> или через QApt, открыв пакет в файловом менеджере, если он это поддерживает. Будьте осторожны: если вы не изменяли версию ABI, то старое ядро и модули перезапишутся.

Снова соберите загрузочный файл.

Копаем recovery

Проверяю разницу между boot и recovery разделами. Все идентично кроме initramfs. В initramfs раздела recovery изучаю init.rc, в котором описан лишь один сервис, который запускает /sbin/recovery. Изучаю strings sbin/recovery | less, затем исходники оригинального recovery.

Как видно, по умолчанию recovery просто отображает логотип Android. А если необходимо что-то сделать, то в штатном режиме в раздел /cache записывается файл /cache/recovery/command, который может содержать параметры запуска recovery. Если в этот файл записать –show_text то мы должны увидеть меню.

Запускаю dirtycow exploit, выставляю UID/GID, записываю файл и запускаю adb reboot recovery. Телефон перезагружается и я попадаю в меню стандартного recovery. Уже что-то. Пробую прошить ZIP файл с supersu через adb sideload.

Выясняю, что initramfs содержит публичный ключ res/keys в формате minicrypt, которым проверяется цифровая подпись ZIP файла. Оказалось это стандартный тестовый ключ Android, и что я могу подписать этим ключём любой архив. Проверить это можно следующим образом:

java -jar dumpkey.jar android/bootable/recovery/testdata/testkey.x509.pem > mykey
diff -u mykey res/keys

Попробовал установить ZIP напрямую с sdcard, но в recovery при монтировании sdcard возникала ошибка. Изучил etc/recovery.fstab, оказалось что в режиме recovery sdcard монтируется как vfat:

Наводим красоту, ставим refind

сожалению

счастью я болею сильной формой перфекционизма. И простой GRUB2 меня не устраивал, больно он страшный и не красивый. Беглый гуглинг рассказал мне о BURG, «красивом» форке GRUB, но он был заброшен и на данный момент скорее мертв, чем жив. К счастью для UEFI-машин есть отличная альтернатива — rEFInd.

rEFInd является форком, заброшенного ныне rEFIt, а также его логическим продолжением. Первый создавался в первую очередь для Mac’ов и работы рядом с Boot Camp, нынешний форк такой узкой специализации не имеет и подходит практически для любых конфигураций.

Стоит сразу заметить, что rEFInd НЕ является загрузчиком. Это так называемый Boot Manager, он вызвает другие .efi-бинарники к исполнению, а также может направить UEFI на запуск ядра прямо с раздела /boot. Другими словами то есть систему загружает не он, а сам UEFI. Для Multi-Boot машин является отличным решением. Сам по себе rEFInd является .efi-приложением, собранным средствами UEFI Shell. Сам находится в директории EFI/refind/refind_x64.efi

Помимо того, что можно выбирать между уже установленными системами на ПК, приятным плюсом можно выделить автоматическое обнаружение загрузочных флешек и дисков. На КПДВ это можно увидеть. У меня имеется загрузочная флешка с Debian (не установщиком, а полноценной ОС) и можно увидеть удобную индикацию того, что это именно флешка, а не что-то другое.

Если у вас имеется несколько ядер, то их список можно увидеть по нажатию клавиши F2. Помимо этого в файле /boot/refind_linux.conf можно задать несколько вариантов с разными параметрами ядра (например первый — стандартный для загрузки GUI, второй — безопасный режим без видеодрайвера и т.д, можно сделать дюжину вариантов, по умолчанию всего три).

Настройка

Загрузите пакеты, требуемые для компиляции (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);
 }

 /**
--

Скрипты компиляции определяют версию ядра по последней записи в истории изменений (changelog) в директории debian.master. Добавьте новую запись, чтобы изменить версию.

EDITOR=nano debchange -c debian.master/changelog -l "custom"

К версии будет добавлен суффикс custom1, что отразится при сборке пакетов .deb и позволит установить их при уже установленных пакетах той же версии без суффикса. Однако этот суффикс распространяется только на имя пакета, но не на его содержимое: ядро и директория с его модулями будут иметь ту же версию 4.4.

linux (4.4.0-3400.53custom1) UNRELEASED; urgency=medium

  * Allow hibernation on Secure Boot
...

Настройка 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/initramfs-tools/conf.d/resume указан раздел для пробуждения из гибернации.

После всех изменений обновите образ initramfs.

update-initramfs -u

Не выходите из системы и chroot,

Очевидные советы

Если вашей задачей стоит защита данных на устройстве, то Secure Boot выполнит свою работу и не больше. Остальное возлагается на вас.

• Не добавляйте чужих ключей в прошивку. Даже от Microsoft. В первую очередь от Microsoft.

• Не подписывайте UEFI Shell, KeyTool или другие приложения, имеющие доступ к записи в NVRAM. Используйте их в Setup Mode.

• Не оставляйте устройство включённым без присмотра. Устройство в ждущем режиме (suspend to RAM) содержит в RAM расшифрованные данные и мастер-ключи от криптоконтейнеров.

• Установите пароль на UEFI Setup не проще, чем от вашего криптоконтейнера.

• При физическом доступе к внутренностям устройства можно отключить Secure Boot, сбросив память NVRAM или повредив её, а также оставить хардварную закладку. Такая атака успешна только тогда, когда она незаметна. Сделайте так, чтобы вы о ней могли узнать: заклейте винты на корпусе трудновоспроизводимыми стикерами, обмажьте их лаком с блёстками. Опечатайте своё устройство.

• Поставьте первым в списке загрузки неподписанное приложение. Если вы однажды не увидите сообщение от Secure Boot, то ваше устройство однозначно скомпрометировано.

• Надёжнее отключённого от интернета устройства, хранимого в сейфе, всё равно ничего не придумаешь. Уязвимости в реализации Secure Boot в конкретных прошивках не исключены.

Первым делом нам нужно записать windows

Потому что если поставить Windows второй, то она затрет загрузчик. Восстановить? Без проблем. Но зачем возня, если можно сразу сделать всё по уму? Впрочем я всё равно обговорю нюансы восстановления чуть позже в конце статьи.

В отличии от Linux, Windows записать гораздо проще, на мой взгляд. Первый способ до возможно многим знаком, нужно просто зайти в cmd.exe от имени администратора и ввести эти команды. Не сложно заметить, то тут нет абсолютно никакой магии. Мы просто форматируем флешку в FAT32:

diskpartlist diskselect disk <номер флешки>cleancreate partition primaryselect partition 1activeformat fs fat32 quickassignexit

После этого нужно просто открыть ISO-файл архиватором и перекинуть содержимое на чистую флешку. Всё, UEFI-флешка готова. На Linux можно сделать всё аналогичным образом, просто форматируем в FAT32 и копируем содержимое.

Полученную флешка должна отлично загружаться любым ПК с поддержкой UEFI.

Кстати, обратимся к теории: наш образ с Windows 10 содержит папочку efi, в ней как раз лежит всё добро для начала загрузки, которое должен увидеть наш UEFI. Поэтому простого форматирования и копирования в большинстве случаев хватает для большинства ПК.

Однако я предпочитаю второй способ с использованием утилиты Rufus. Он меня никогда не подводил. Однако это Windows-only способ. На Linux-системах использование ddresque для создания загрузочной флешки Windows НЕ РАБОТАЕТ. Так что пробуйте другие утилиты, если первый способ с простым форматирование не помог.

Всё что вам будет нужно: выбрать вашу флешку, выставить параметр «Схема раздела и тип системного интерфейса» на «GPT для компьютеров с UEFI», и нажать старт. Остальные параметры трогать не нужно. Лучше использовать флешки помельче (на 8-16 гигабайт).

Наверняка один из способов должен был прокатить, лично я ни разу с проблемами на этом этапе не встречался, главное чтобы компьютер поддерживал UEFI.

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

Если вам нужно установить сторонние или собственные драйвера и модули ядра, их необходимо подписать. Для подписи модулей ядра требуются сертификат в формате 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

Примечания

1. ↑Решаемо путём сборки образа GRUB с нужными модулями с помощью grub-mkstandalone, но его придётся подписывать самому.

2. ↑Теоретически можно исправить, установив пароль, встроив grub.cfg в образ GRUB с помощью grub-mkstandalone и установив в grub.cfg prefix на невалидный путь, чтобы GRUB не мог найти второй grub.cfg на диске. Но опять же требуется подписывать образ самостоятельно.

3. ↑А он есть у всех кроме

параноиковоправданно озабоченных своей безопасностью пользователей.

4. ↑У меня загрузиться с USB не даёт. Windows 8 и 10 также без пароля не пускают в безопасный режим или консоль.

5. ↑Говорят, некоторые прошивки он окирпичивает. Безопаснее создать по ESP на каждый загрузчик.

Пробуем отключить selinux

На тот момент я думал, что все ошибки об отсутствии привилегий вызваны SELinux (я полностью забыл о том, что могут быть урезаны capabilities). Логов dmesg я не видел, logcat ничего релевантного не показывал. И я начал думать как отключить SELinux.

Первая зацепка, которую я смог найти:

$ grep -A2 reload_policy boot/ramfs/init.rc 
on property:selinux.reload_policy=1
    restart ueventd
    restart installd

Исходники говорят о том, что при изменении этой опции, init перезагружает политики SELinux из файла /sepolicy.

Т.е. я при помощи dirtycow могу перезаписать /sepolicy и командой setprop selinux.reload_policy 1 загрузить обновленную политику.

Для начала нужно выяснить что из себя представляет /sepolicy. Изучить его можно с помощью команды sesearch (пакет setools в Debian).

$ sesearch --allow sepolicy
$ sesearch --neverallow sepolicy
$ sesearch --auditallow sepolicy
$ sesearch --dontaudit sepolicy

В моём случае /sepolicy содержал только allow, что значит — при enforcing режиме SELinux в Android разрешено делать только то, что объявлено в политике. А процессу init разрешалось только загружать политику, но не отключать:

$ sesearch --allow sepolicy | grep 'load_policy'
   allow init kernel : security load_policy ;

Моей задачей было — разрешить init контексту задать selinux->enforce в permissive (setenforce 0).

Первое, что я сделал — собрал стандартную политику стокового Android, подменил оригинальный /sepolicy, загрузил (под root пользователем setprop selinux.reload_policy 1) и получил сообщение в статусной строке, что телефон находится в незащищенном режиме.

Первая же мысль: стоковая политика не подходит этому телефону и он при отсутствии прав начинает тупить.

Я собрал новую политику, в которой просто описал все существующие SELinux context и объявил их permissive. Тоже не помогло.

Потом я решил пересобрать политику и по возможности добавить привилегии для shell контекста.

Я нашел статью, в которой говорится как “декомпилировать” политику. Немного повозившись я смог собрать все зависимости и запустить утилиту sedump. На выходе я получил текстовый файл, который я смог собрать обратно (для KitKat checkpolicy -M -c 26 -o sepolicy.new policy.conf) и даже получить файл с точно таким же размером что и оригинальный sepolicy, но разным hex содержимым. Загрузка новой политики вызвала точно такие же результаты, что и ранее — телефон через какое-то время перезагружался.

Я решил собрать две политики: из policy.conf, который я получил и из policy.conf, в котором добавлены все привилегии для allow init kernel : security, в том числе и setenforce. Сравнить файлы в hex и по аналогии заменить байты в оригинальном sepolicy.

Как выяснилось две пересобранные политики отличались всего парой байт. Я начал искать похожие совпадения в оригинальном sepolicy, но не нашёл. Затем я просто написал brute force скрипт, который в заданном диапазоне смещений заменяет два байта на “0xFF,0xFF”, запускает sesearch –allow | grep “нужный результат”.

Чуть позже я нашел утилиту sepolicy-inject, которая добавляет привилегии в уже скомпилированный sepolicy файл. Если правило уже существует, то добавление максимальных привилегий не увеличивает конечный размер политики. К сожалению запуск утилиты добавляет всего одно правило за раз.

Потом я узнал, что в Android есть команда load_policy, которая перезагружает политику по любому пути. Танцы с бубном оказались лишними.

adb shell run-as /data/local/tmp/run -u system -c u:r:init:s0 load_policy /data/local/tmp/sepolicy.new

Можно было добавить любой permissive домен, загрузить новую политику и работать в контексте этого домена (кстати, supersu от chainfire для новых версий Android так и работает). Но даже это не дало возможности отключить SELinux. Я решил копать в другом направлении.

Разметка и шифрование

Чтобы загружаться с диска в режиме 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
    OK, Apply
    Выбрать созданный раздел и открыть свойства (Properties), выставить флаг boot
    OK, 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

С разметкой закончено, можно перейти к установке.

Расшифровка kyocera properties

Kyocera наряду с android system properties использует свой внутренний механизм properties, который мне тоже не удалось выяснить. Наверняка там хранятся интересные опции, которые могут влиять в том числе и на снятие защиты bootloader’а. В телефоне есть библиотека libkcjprop_jni.so и демон kcjprop_daemon. Библиотеку можно подключить и использовать её функции, но у меня пока не нашлось времени этого сделать.

Опции пишутся на файловую систему, внутри бинарные данные:

$ ls -la /sysprop/kcjprop/rw/8d9d788ddd5fecfdbc6c5f7c5cecfc    
-rw-rw---- root     root           16 1970-01-22 21:01 8d9d788ddd5fecfdbc6c5f7c5cecfc

Создание загрузчика

Ядро 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 аргументы, которые будут передаваться ядру.

Способ 3. скомпилировать своё ядро

Если ваше время ничего не стоит, то вы можете скомпилировать своё ядро без этого ограничения. Гарантий, что после долгих мучений вы будете довольны результатом, нет. Но если вы этого очень хотите, хвала Линусу Торвальдсу и GPLv2, у вас есть на это право. Вы можете предварительно протестировать скомпилированное мною ядро, чтобы не тратить зря время.

$ 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

linux_4.4.0-34.53.dsc

sudo apt-get install git

git clone git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git
cd ubuntu-xenial

$ git tag -l Ubuntu-*
...
Ubuntu-4.4.0-33.52
Ubuntu-4.4.0-34.53
Ubuntu-4.4.0-35.54
...

git checkout -b temp Ubuntu-4.4.0-34.53

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

cp /boot/config-4.4.0-34-generic config
fakeroot debian/rules editconfigs

--- 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);
 }

 /**
--

EDITOR=nano debchange -c debian.master/changelog -l "custom"

linux (4.4.0-3400.53custom1) UNRELEASED; urgency=medium

  * Allow hibernation on Secure Boot
...

fakeroot debian/rules clean
skipabi=true skipmodule=true DEB_BUILD_OPTIONS=parallel=$(getconf _NPROCESSORS_ONLN) do_tools=false no_dumpfile=1 
fakeroot debianrules binary-generic

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, а гостевой — предпочитаемую для работы. При завершении работы автоматически останавливать виртуальную машину с сохранением состояния, а затем отключать устройство.

С большей надёжностью придёт и большая защищённость: чувствительные данные можно изолировать от опасной среды. Браузер и песочница для установки стороннних пакетов в одной виртуальной машине, важные персональные данные — в другой. Украсть мастер-ключ от зашифрованного диска в памяти хостовой ОС из гостевой гораздо сложнее. Кажется, для подобного существует Qubes OS. Но она данный момент не поддерживает Secure Boot. Fail.

На этом всё, приветствуются любые дополнения и замечания.

Установка

Так как мы планируем создать загрузчик самостоятельно, да и установщик Ubuntu не поддерживает шифрование /boot, запустим установку без создания загрузчика.

ubiquity -b

На этапе разметки диска выберите Вручную.

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

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

Установка ubuntu с шифрованием всего диска с помощью luks и lvm

LUKS — Linux Unified Key Setup — обёртка для криптографической системы dm-crypt, позволяющая создавать виртуальные зашифрованные устройства в файлах и на физических дисках. С помощью LUKS можно зашифровать данные на всём диске для того, чтобы перед загрузкой ОС требовалось ввести пароль.

LVM — Logical Volume Manager — менеджер логических томов, с помощью которого мы разделим криптоконтейнер на тома. Тома LVM автоматически монтируются после ввода пароля к криптоконтейнеру, отдельный ввод пароля для каждого тома не требуется.

Следующие инструкции должны быть применимы к любому дистрибутиву на базе Ubuntu, для других потребуются коррективы. Сперва загрузитесь с Live CD или установочного образа в режиме Try before installing.

Эксперименты с загрузчиками

Для проведения экспериментов я заказал из штатов за символическую сумму Kyocera Brigadier с разбитым экраном.

Я проверил цифровые подписи aboot загрузчиков. Subject’ы сертификатов оказались идентичными, следовательно они могут быть взаимозаменяемыми. Решился на эксперимент: прошить aboot от KC-S701 в Brigadier. Загрузчик заработал. На удивление, защита emmc от записи с этим загрузчиком не включилась и я смог спокойно восстановить загрузчик от Brigadier.

Тут история могла бы закончиться, но “телефон не загрузился” — это черный экран. И на моё счастье это был черный экран не Qualcomm QHSUSB__BULK, который требует специального подписанного загрузчика для восстановления телефона, а тот самый download mode, который представляет телефон как USB mass storage. Телефон был восстановлен. На сегодняшний день это последнее, что я предпринял.