Linux mint secure boot password

Как загрузить и установить Linux на компьютер с UEFI и Secure Boot

Новые компьютеры с системой Windows поставляются с прошивкой UEFI и с включенной загрузкой Secure Boot. Режим Secure Boot предотвращает загрузку операционных систем, если они не подписаны ключом, загруженным в UEFI; сразу «из коробки» можно загрузить только программное обеспечение, подписанное фирмой Microsoft.

Фирма Microsoft требует, чтобы производители компьютеров позволяли пользователям отключить режим Secure Boot, поэтому вы можете отключить режим Secure Boot или добавить свой собственный ключ для того, чтобы обойти это ограничение. Режим Secure Boot нельзя отключить на устройствах ARM под управлением Windows RT.

Как работает режим Secure Boot

Компьютеры, которые поставляются с системами Windows 8 и Windows 8.1 имеют прошивку UEFI вместо традиционного BIOS. По умолчанию прошивка UEFI машины будет загружать только загрузчики, подписанные ключом, встроенным в прошивку UEFI. Эта особенность известна как «Secure Boot» (безопасная загрузка) или «Trusted Boot» (проверенная загрузка). На традиционных компьютерах без этой функции безопасности, руткит может установить себя и стать загрузчиком boot loader. После этого BIOS компьютера будет загружать руткит в процессе загрузки, во время которой происходит загрузка самого загрузчика и загрузка Windows, скрывая себя от операционной системы и внедряя себя глубоко в систему.

Режим Secure Boot блокирует это — компьютер будет загружать только проверенное программное обеспечение, поэтому вредоносные начальные загрузчики не смогут заразить систему.

На компьютерах Intel x86 (а не на компьютерах ARM) у вас есть возможность управлять режимом Secure Boot. Вы можете выбрать вариант отключения этого режима или даже добавить ключ со своей собственной подписью. Организации могут использовать свои собственные ключи для того, чтобы обеспечить, чтобы могли загружаться только одобренные операционные системы Linux, например

Варианты установки Linux

У вас есть несколько вариантов установки Linux на компьютер с режимом Secure Boot:

• Выберите дистрибутив, в котором поддерживается режим Secure Boot: современные версии Ubuntu, начиная с Ubuntu 12.04.2 LTS и 12.10, будет загружаться и нормально устанавливаться на большинстве ПК с включенным режимом Secure Boot. Это объясняется тем, что загрузчик EFI первоначального этапа загрузки в Ubuntu подписан фирмой Microsoft. Впрочем, один из разработчиков Ubuntu отмечает , что загрузчик в Ubuntu не подписан ключом, который необходим согласно процессу сертификации Microsoft, а просто одним из ключей, о которых говорят, что он «рекомендован» фирмой Microsoft. Это означает, что Ubuntu не обязана загружаться на всех компьютерах с UEFI. Для того, чтобы использовать Ubuntu на некоторых компьютерах, пользователям, возможно, придется отключить режим Secure Boot.
• Отключение режима Secure Boot: Режим Secure Boot можно отключить, что позволит позволить превратить преимущество безопасной загрузки в возможность иметь что-нибудь свое для загрузки компьютера точно также, как это делается на старых компьютерах с традиционным BIOS. Это также потребуется сделать, если вы хотите установить старую версию Windows, которая не разрабатывалась с врозможностью использовать режим Secure Boot, например, Windows 7.
• Добавить в прошивку UEFI подписанный ключ: Некоторые дистрибутивы Linux позволяют подписывать свои загрузчики с помощью их собственного ключа, который вы можете добавить в свою прошивку UEFI. На данный момент, это, кажется, не является обычной практикой.

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

На большинстве новых компьютеров у вас должна иметься возможность устанавливать без каких-либо проблем текущие версии Ubuntu — либо релиз LTS, либо последний релиз. Инструкции о том, как загружаться со сменного носителя, смотрите в последнем разделе.

Как отключить режим Secure Boot

Вы можете управлять режимом Secure Boot из вашего экрана настройки прошивки UEFI — UEFI Firmware Settings. Для доступа к этому экрану, вам нужно будет в Windows 8 получить доступ к меню параметров загрузки. Чтобы сделать это, откройте страницу Settings (Настройки) — чтобы попасть на эту страницу, нажмите клавишу Windows Key + I, затем нажмите кнопку питания, а затем нажмите и удерживайте клавишу Shift и одновременно щелкните мышкой по кнопке Restart (Перезагрузка).

Ваш компьютер будет перезагружен в экран расширенных параметров загрузки. Выберите вариант Troubleshoot (Диагностика), выберите вариант Advanced options (Дополнительные параметры), а затем выберите пункт UEFI Settings (Настройки UEFI). На некоторых компьютерах с системой Windows 8 вы можете не увидеть пункт UEFI Settings, даже если эти компьютеры поставляются с UEFI — в этом случае для того, чтобы получить информацию о том, как добраться до его экрана настроек UEFI, обратитесь к документации разработчика.

Вы попадете на экран настроек UEFI, где вы можете выбрать отключение режима Secure Boot или добавление своего собственного ключа.

Загрузка со сменного носителя

Вы можете загрузиться со сменного носителя при помощи точно такого же доступа к меню параметров загрузки — удерживайте нажатой клавишу Shift и щелкните мышкой по кнопке Restart (Перезагрузка). Подключите загрузочное устройство, выберите вариант Use a device (Использовать устройство), и выберите устройство, с которого необходимо загрузиться.

После загрузки со сменного носителя вы можете установить Linux точно также, как и обычно, или просто можете использовать живую среду сменного носителя (устройство live), не устанавливая его.

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

Источник

Linux Mint 19: Secure Boot

Contents

Secure Boot and Linux Mint 19

The idea is to create a signed GRUB EFI binary with required modules built-in. Secure Boot verifies this binary during boot. GRUB then reads the signed grub.cfg which contains the list of available kernels and then loads the signed kernel and initrd. GRUB’s verification is based on GPG which is independent of Secure Boot.

The guide was tested on a Debian system with the specs listed below, but should be easily adaptable.

• Device: COMEX-IE38M
• OS: Linux Mint 19
• Kernel: 4.15.0-34-generic
• BIOS:
• GRUB: 2.02-2ubuntu8.4
• efitools: 1.8.1

Installation of required tools

Secure Boot setup

• Generate your own keys for Secure Boot: PK, KEK, db

• Convert open part of the keys to the ESL format understood for UEFI

• Sign ESL files

• At this stage your are ready to sign GRUB EFI binary and add it to the list of binaries allowed by Secure Boot

GRUB EFI setup

GRUB EFI supports loading of GPG signed files only e.g. config or kernels through the verify module. The grub-mkstandalone command can be used to create a single GRUB binary with built-in modules and initial configuration script. The GRUB password is required to restrict access to the GRUB shell which allows running arbitrary commands. Your grub.cfg, kernel and initrd and their signatures would be placed on the EFI partition.

• Create initial GRUB configuration script grub.init.cfg

• Generate your GPG key

• Sing grub.init.cfg with your GPG key

• Creating single GRUB EFI binary with buit-in modules and signed grub.init.cfg

• Sign grubx64.efi with your db key

Prepare signed grub.cfg kernel and initrd on the EFI partition

• Mount your EFI partition to /boot/efi if not mounted yet

• Copy your existing config, kernel and initrd to the EFI partition

• Create a secure boot «menuentry» for the grub.cfg on the EFI partition

• Add the secure boot «menuentry» to grub.cfg on the EFI partition

• Sign grub.cfg, kernel and initrd with your GPG key

• Replace your existent bootloader with signed one

Источник

Почему меня попросили создать пароль для отключения безопасной загрузки при начальной установке Ubuntu 16.04?

При первоначальной установке Ubuntu 16.04 я установил флажок «Установить стороннее программное обеспечение», и под ним мне предложили отметить другой параметр, который позволял бы пакету ОС автоматически отключать безопасную загрузку самостоятельно, обязательным условием которого было создание пароля, который каким-то образом позволил бы всему этому процессу произойти.

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

После успешной установки ОС я перезагрузил компьютер и проверил BIOS. В BIOS безопасная загрузка все еще была включена. Однако, вернувшись в Ubuntu, я могу без проблем воспроизводить файлы MP3 и Flash, что, как я полагаю, указывает на успешную установку стороннего программного обеспечения.

Я еще не сталкивался с какими-либо проблемами (за исключением того факта, что пользовательский интерфейс иногда был немного привередлив и глючил), но я хотел бы знать, чего на самом деле я достиг, создав этот пароль.

Что случилось с паролем, который я создал? Нужно ли будет помнить это по какой-либо причине? Это не то же самое, что мой логин / пароль sudo.

Ubuntu постоянно редактировал мой BIOS, чтобы сделать для себя исключение? Если да, как я могу просмотреть эти изменения и, возможно, отменить их? Это где пароль будет входить?

Почему Ubuntu все равно нужно отключить / пропустить безопасную загрузку, чтобы установить пакет ubuntu-limited-extras? Моя установка в порядке? Я настроился на будущие проблемы? Должен ли я попробовать переустановить с отключенной безопасной загрузкой вручную, чтобы не получать это приглашение?

Дополнительная информация: Я использую систему UEFI и работаю с двойной загрузкой Ubuntu 16.04 вместе с Windows 10.

Другой пользователь задал вопрос о подобной проблеме здесь. В отличие от этого пользователя, я не получаю предупреждение о «загрузке в небезопасном режиме», но я также хотел бы знать, создал ли Ubuntu исключение для себя и как я могу управлять такими исключениями. В отличие от меня, этот пользователь не упомянул ничего о необходимости создания пароля.

Источник

Укрощаем UEFI SecureBoot

Введение

С ликбезом закончили, теперь к делу. Несмотря на то, что про создание своих ключей и настройку SecureBoot написано за три последних года с десяток отличных статей (ссылки на часть из которых приведены в разделе Литература), воз и ныне там. Основная проблема с информацией о настройке SecureBoot даже в англоязычном сегменте сети (не говоря уже о рунете) — большая часть статей, текстов и постов обрывается на «вот у нас теперь есть ключи в формате EFI Signature List, добавьте их зависимым от вашего вендора прошивки способом и готово». При этом сами вендоры не торопятся описывать меню настройки SecureBoot ни в документации на свои платформы для OEM’ов, ни в мануалах на конечные системы, в результате пользователь теряется на незнакомой местности и либо отключает SecureBoot, мешающий загружать его любимую OpenBSD (или что там у него), либо оставляет его на настройках по умолчанию (а чего, Windows грузится же). Именно этот последний шаг я и попытаюсь описать более подробно, но не в ущерб остальным необходимым шагам.

Тестовая конфигурация

Специально для этой статьи я достал из закромов пару не самых новых ноутбуков с прошивками на платформах Phoenix SCT и Insyde H2O, а также совершенно новую плату congatec (разработкой прошивки для которой я занят в данный момент) на платформе AMI AptioV. Встречайте, наши тестовые стенды:

1. AMI, они же «треугольные«: congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)

2. Insyde, они же «квадратные«: Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)

3. Phoenix, они же «полукруглые«: Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)

Об интерфейсах для настройки SecureBoot

Готовим плацдарм

Начнем с лирического отступления о наличии нужного софта для разных ОС. Несмотря на то, что Microsoft является одним из разработчиков технологии, в открытом доступе до сих пор отсутствуют нормальные средства для работы с ней из Windows (ключи можно сгенерировать утилитой MakeCert из Windows SDK, а для всего остального предлагается использовать HSM третьих лиц за большие деньги). Я подумывал сначала взять и написать нужную утилиту на Qt, но потому решил, что ключи и подписи каждый день генерировать не нужно, а на пару раз хватит и существующих решений. Можете попробовать переубедить меня в комментариях, если хотите.
В общем, для всего нижеперечисленного вам понадобится Linux (который можно запустить с LiveUSB, если он у вас не установлен). Для него существует целых два набора утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign. У меня есть положительный опыт работы с первым набором, поэтому речь пойдет именно о нем.
В итоге, кроме Linux, нам понадобятся несколько вещей:
1. Пакет openssl и одноименная утилита из него для генерирования ключевых пар и преобразования сертификатов из DER в PEM.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для преобразования сертификатов в формат ESL и подписи файлов в этом формате, и KeyTool.efi для управления ключами системы, находящейся в SetupMode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM’ов и приложений для UEFI Shell) вашим ключом.
Загрузите Linux, установите вышеуказанные пакеты, откройте терминал в домашней директории и переходите к следующему шагу.

Генерируем собственные ключи для SecureBoot

Как обычно, есть несколько способов сделать что-либо, и чем мощнее используемый инструмент, тем таких способов больше. OpenSSL же как инструмент развит настолько, что кажется, что он умеет делать вообще всё, а если почитать к нему man — то и абсолютно всё остальное. Поэтому в этой статье я ограничусь непосредственной генерацией ключевых файлов, а танцы вокруг создания собственного CA оставлю на самостоятельное изучение.

Генерируем ключевые пары

Конвертируем открытые ключи в формат ESL

Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел 30.4.1 в текущей версии 2.5) и интересен тем, что файлы в нем можно соединять друг с другом конкатенацией, и этот факт нам еще пригодится.
Ключ -g добавляет к сгенерированному ESL-файлу GUID, в нашем случае — случайный, полученый запуском утилиты uuidgen и использованием ее вывода. Если этой утилиты у вас нет — придумывайте GUIDы сами или оставьте значение по умолчанию.

Подписываем ESL-файлы

С другой стороны, если вы не хотите терять возможность загрузки Windows и подписанных ключом Microsoft исполняемых компонентов (к примеру, GOP-драйверов внешних видеокарт и PXE-драйверов внешних сетевых карточек), то к нашему ISK.esl надо будет добавить еще пару ключей — ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики и ключ Microsoft UEFI driver signing CA, которым подписываются компоненты третьих сторон (именно им, кстати, подписан загрузчик Shim, с помощью которого теперь стартуют разные дистрибутивы Linux, поддерживающие SecureBoot из коробки).
Последовательность та же, что и под спойлером выше. Конвертируем из DER в PEM, затем из PEM в ESL, затем добавляем к db.esl, который в конце концов надо будет подписать любым ключом из KEK:

Теперь подписываем PK самим собой:
Подписываем KEK.esl ключом PK:
Подписываем db.esl ключом KEK:

Если еще не надоело, можно добавить чего-нибудь еще в db или создать хранилище dbx, нужные команды вы теперь знаете, все дальнейшее — на ваше усмотрение.

Подписываем загрузчик

Осталось подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу SecureBoot после добавления ваших ключей. Для тестов я советую подписать утилиту RU.efi, она графическая и яркая, и даже издалека видно, запустилась она или нет. На самом деле, утилита эта чрезвычайно мощная и ей можно натворить немало добрых и не очень дел, поэтому после тестов лучше всего будет её удалить, и в дальнейшем подписывать только загрузчики.
В любом случае, подписываются исполняемые файлы вот такой командой:
Здесь я заодно переименовал исполняемый файл в bootx64.efi, который нужно положить в директорию /EFI/BOOT тестового USB-носителя с ФС FAT32. Для 32-битных UEFI (избавь вас рандом от работы с ними) используйте bootia32.efi и RU32.efi.

В результате вот этого всего у вас получились три файла .auth, которые нужно будет записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком порядке. Скопируйте все три файла в корень другого USB-носителя с ФС FAT32, на котором в качестве /EFI/BOOT/bootx64.efi выступит /usr/share/efitools/efi/KeyTool.efi (скопируйте его еще и в корень, на всякий случай) и ваш «набор укротителя SecureBoot» готов.

Укрощение строптивого

AMI AptioV

У большинства прошивок, основанных на коде AMI, управление технологией SecureBoot находится на вкладке Security, у меня это управление выглядит так:

Заходим в меню Key Management (раньше оно было на той же вкладке, сейчас его выделили в отдельное) и видим там следующее:

Выбираем нужную нам переменную, после чего сначала предлагают выбрать между установкой нового ключа и добавлением к уже имеющимся, выбираем первое:

Теперь предлагается либо установить значение по умолчанию, либо загрузить собственное из файла, выбираем последнее:

Далее нужно устройство и файл на нем, а затем выбрать формат этого файла, в нашем случае это Authenticated Variable:

Затем нужно подтвердить обновление файла, и если все до этого шло хорошо, в результате получим лаконичное сообщение:

Повторяем то же самое для KEK и PK, и получам на выходе вот такое состояние:

Все верно, у нас есть единственный PK, всего один ключ в KEK и три ключа в db, возвращаемся в предыдущее меню кнопкой Esc и включаем SecureBoot:

Готово, сохраняем настройки и выходим с перезагрузкой, после чего пытаемся загрузиться с нашей флешки и видим вот такую картину:

Отлично, неподписанные загрузчики идут лесом, осталось проверить подписанный. Вставляем другую флешку, перезагружаемся и видим что-то такое:

Вот теперь можно сказать, что SecureBoot работает как надо.
Если у вашего AMI UEFI такого интерфейса для добавления ключей нет, то вам подойдет другой способ, о котором далее.

Insyde H2O

Здесь все несколько хуже, чем в предыдущем случае. Никакого интерфейса для добавления собственных ключей нет, и возможностей настройки SecureBoot предлагается всего три: либо удалить все переменные разом, переведя SecureBoot в Setup Mode, либо выбрать исполняемый файл, хеш которого будет добавлен в db, и его можно будет запускать даже в том случае, если он не подписан вообще, либо вернуться к стандартным ключам, в качестве которых на этой машине выступают PK от Acer, по ключу от Acer и MS в KEK и куча всякого от Acer и MS в db.
Впрочем, нет интерфейса — ну и черт с ним, у нас для этого KeyTool есть, главное, что в Setup Mode перейти можно. Интересно, что BIOS Setup не дает включить SecureBoot, если пароль Supervisor Password не установлен, поэтому устанавливаем сначала его, затем выполняем стирание ключей:

После чего на соседней вкладке Boot выбираем режим загрузки UEFI и включаем SecureBoot:

Т.к. фотографии у меня посреди ночи получаются невыносимо отвратительными, то скриншоты KeyTool‘а я сделаю на предыдущей системе, и придется вам поверить в то, что на этой все выглядит точно также (мамой клянусь!).
Загружаемся с нашего носителя в KeyTool, и видим примерно следующее:

Выбираем Edit Keys, попадаем в меню выбора хранилища:

Там сначала выбираем db, затем Replace Keys, затем наше USB-устройство, а затем и файл:

Нажимаем Enter и без всяких сообщений об успехе нам снова показывают меню выбора хранилища. Повторяем то же самое сначала для KEK, а затем и для PK, после выходим в главное меню двойным нажатием на Esc. Выключаем машину, включаем заново, пытаемся загрузить KeyTool снова и видим такую картину (которую я утащил из дампа прошивки, ее фото на глянцевом экране еще кошмарнее, чем предыдущие):

Ну вот, одна часть SecureBoot’а работает, другая проверяется запуском подписанной нами RU.efi и тоже работает. У меня на этой системе Windows 8 установлена в UEFI-режиме, так вот — работает и она, Microsoft с сертификатом не подвели.

Phoenix SCT

Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:

Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool‘а, иначе на этой платформе его запустить не получится:

Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool‘а заканчивается вот так:

При этом установленный на той же машине Linux продолжает исправно загружаться, как и подписанная нами RU.efi, так что SecureBoot можно признать работоспособным.

Заключение

В итоге, благодаря утилитам с открытым кодом, удалось завести SecureBoot на системах с UEFI трех различных вендоров, сгенерировать свои собственные ключи и подписать ими нужные нам исполняемые файлы. Теперь загрузка платформы целиком в наших руках, но только в случае, если пароль на BIOS стойкий и не хранится открытым текстом, как у некоторых, а в реализации SecureBoot нет каких-либо известных (или еще неизвестных) дыр. Сам по себе SecureBoot — не панацея от буткитов, но с ним ситуация с безопасной загрузкой все равно намного лучше, чем без него.
Надеюсь, что материал вам поможет, и спасибо за то, что прочитали эту портянку.

Источник