Secure boot ��� linux

Как загрузить и установить 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.

Источник

Почему UEFI Secure boot это трудность для Linux

Недавняя публикация на Хабре об ограничениях UEFI вызвала широкое обсуждение, в продолжении темы, хочу поделиться переводом актуального поста из блога Matthew Garrett, одного из разработчиков RedHat.

Я писал о технических деталях поддержки Linux`ом спецификации UEFI Secure boot. Не смотря на то, что я прямо указал, что она игнорирует вопросы лицензирования и распространение ключей, тем не менее опираясь на неё люди утверждают, что поддержка Secure boot может быть добавлена в Linux с минимальными усилиями. В некотором смысле, они правы. Технические детали реализации достаточно просты. Но трудности заключены не в них.

Safe boot требует, что бы весь код, который взаимодействует с железом, был доверенным.

В настоящее время, если вы можете выполнить не доверенный код до загрузки ОС, то можете сделать с ОС всё, что захотите. Secure boot предоставляет механизм, который позволяет быть уверенным, что вы запускаете только доверенный код, что призвано защитить от подобных сценариев. Итак, ваши UEFI драйвера снабжены цифровой подписью, загрузчик так же снабжен цифровой подписью и может загрузить только подписанное ядро. Если для загрузки вами использовался только доверенный код, то вы можете быть уверены, что ваша ОС в безопасности. Но, в отличии от загрузки доверенного кода, Secure boot не даёт вам возможности быть уверенным, что выполняется только доверенный код. Это должно быть обеспечено политиками ОС.

На первый взгляд это не составляет большой проблемы. Но на самом деле является ей. Представьте, что у вас есть подписанный загрузчик Linux и подписанное ядро Linux и эти подписи сделаны с помощью глобального доверенного ключа. Они будут загружаться на любом железе использующем Secure boot. Теперь представьте, что злоумышленник пишет модуль ядра, который создаёт поддельное окружение UEFI, прерывает выполнение кода ядром и вызывает загрузчик Windows — что-то вроде kexec, но чуть более сложное. Загрузчик Windows уверен, что он выполняется в Secure boot, но на самом деле, всё, что на его взгляд заслуживает доверия, является поддельным кодом UEFI, написанным злоумышленником. Ключ шифрования пользователя записывается, ядро Windows модифицируется таким образом, что бы скрыть код Linux и не смотря на то, что всё выглядит замечательно, данные вашей кредитной карточки уже на пути в Китай. В этом сценарии подписанное ядро Linux просто используется как загрузчик вредоносного ПО. Единственным признаком, что что-то не так, является чуть более долгая загрузка ОС.

Подписанного ядра не достаточно. Подписанное ядро Linux должно предотвращать загрузку любых не подписанных модулей ядра. VirtualBox в Linux? До свидания. Бинарные драйверы Nvidia? До свидания. Всё что выходит за пределы стандартных модулей ядра? Так же до новых встреч. Самостоятельная сборка новых драйверов? В другой раз. Всё это явно не сделает людей счастливее.

(Тоже самое, конечно, касается и Windows. Windows 7 позволяет запретить проверку цифровой подписи драйверов, но Windows 8 не позволит этого сделать, если система использует механизм Secure boot).

Лицензирование

GPLv3 имеет различные требования к доступности ключей используемых для подписи. Согласно новым требованиям Microsoft, система должна поддерживать установку пользовательских ключей, что позволит пользователям использовать их собственные загрузчики ОС, этого вполне может быть достаточно, что бы соблюсти требования лицензии. Но мы попадаем в зависимость от Microsoft — если они уберут это требование, то пользователи теряют свою свободу и мы оказываемся в неловком положении с вопросом о лицензировании. Обсуждения о том, что конкретно мы сможем предпринять в этом случае, еще продолжаются, но на текущей момент эта проблема не решена.

Распространение ключей

Спецификация UEFI не определяет, кто будет являться центральным удостоверяющим центром. Microsoft настаивает, что бы каждый имел свой собственный ключ. Мы, конечно, можем сгенерировать собственные ключи, но не всё так просто с производителями оборудования. Не существует пути, который гарантировал бы, что все производители железа поддержат их. И, очевидно, если мы сгенерируем ключ, мы не сможем просто передать его приватную часть третьим лицам. Это значит, что для людей станет невозможным выпуск собственных дистрибутивов, основанных на других, без получения их личного ключа. Для получения ключа будет требоваться какая-либо процедура проверки идентификации, которая, вероятно, окажется дорогостоящей, и так же вероятно, что может потребоваться легально зарегистрированная организация, для обеспечения проверки идентификационных данных. Думаю, это будут сертификаты Extended Validation, а не Startssl Free. Таким образом, диструбутивы Linux созданные энтузиастами, окажутся в прошлом.

Разве Custom mode не решает эту проблему?

Сертификационные требования Microsoft указывают, что все системы должны поддерживать Custom mode, реализация этой функции должна обеспечить возможность пользователям устанавливать их собственные ключи. Производители Linux смогут поставлять их собственные ключи вместе с дистрибутивом и устанавливать собственные политики. Все счастливы. На самом деле, всё не так хорошо. Людям придётся тратить невероятное количество времени и усилий для того чтобы установить Linux, вместо того, чтобы просто вставить CD в привод. Потребность изменения прошивки и её перенастройка добавляет дополнительный барьер и ограничивает возможность установки Linux лишь более технически грамотными пользователями. А это еще хуже. Вот полное описание требований к Custom mode:
1. Для физически находящегося за устройством пользователя, должна быть возможность использования режима Custom mode, для модифицирования содержимого базы данных сигнатур Secure boot и PK (прим. переводчика: PK — private key).
2. Если пользователь удаляет PK, то при выходе из режима Custom mode, система будет функционировать в режиме Setup Mode c выключенным по-умолчанию Secure Boot.
3. Меню настройки прошивки должно уведомлять о включении Secure boot, а так же о режиме функционирования Standard или Custom mode. Меню настройки так же должно предоставлять возможность возвратиться от Custom к Standard mode, с восстановлением заводских настроек по-умолчанию.

Здесь кое-что упущено, например:
— Какое-либо описание UI. Это делает фактически невозможным документирование процесса установки Linux, когда первый шаг (а) запутан и (б) зависит от производителя. Производители железа стараются выделить себя, предлагая свои собственные уникальные интерфейсы прошивок. Custom mode в них может выглядеть совершенно по-разному.
— Какое-либо описание формата ключа. Простое бинарное представление ключа? Или структура EFI_SIGNATURE_DATA? Ключ в кодировке base64, далее защищенный ROT13? Мы просто не знаем.
— Какой-либо путь для использования режима Custom mode при unattended-варианте установки ОС. Интерфейс прошивки требует физического присутствия пользователя. Желаете установить ОС на несколько тысяч машин по сети? Это не масштабируемый подход.
— … и одна мелочь, на самом деле, нигде нет требований, что бы пользователь мог сам добавлять ключ, производители железа могут воспользоваться этим, разрешив лишь удалять ключи. Это не плохо, пока пользователи могут удалять PK, потому-что затем они вернутся обратно в Setup mode и смогут установить наши ключи из установщика, но на практике это по-прежнему будет вызывать проблемы.

Всё таки Custom mode не решает всех проблем. Custom mode с строго определенным UI и форматом ключа был бы на много лучше, но по-прежнему не решит проблему с автоматическим unattended-вариантом установки ОС.

Источник

• SecureBoot

Unified Extensible Firmware Interface. See the main UEFI page for more details.

UEFI Secure Boot (SB) is a verification mechanism for ensuring that code launched by a computer’s UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process, before the operating system has been loaded.

SB works using cryptographic checksums and signatures. Each program that is loaded by the firmware includes a signature and a checksum, and before allowing execution the firmware will verify that the program is trusted by validating the checksum and the signature. When SB is enabled on a system, any attempt to execute an untrusted program will not be allowed. This stops unexpected / unauthorised code from running in the UEFI environment.

Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means the firmware on these systems will trust binaries that are signed by Microsoft. Most modern systems will ship with SB enabled — they will not run any unsigned code by default, but it is possible to change the firmware configuration to either disable SB or to enrol extra signing keys.

Most of the programs that are expected to run in the UEFI environment are boot loaders, but others exist too. There are also programs to deal with firmware updates before operating system startup (like fwupdate and fwupd), and other utilities may live here too.

Other Linux distros (Red Hat, Fedora, SUSE, Ubuntu, etc.) have had SB working for a while, but Debian was slow in getting this working. This meant that on many new computer systems, users had to first disable SB to be able to install and use Debian. The methods for doing this vary massively from one system to another, making this potentially quite difficult for users.

Starting with Debian version 10 («Buster»), Debian included working UEFI Secure Boot to make things easier.

What is UEFI Secure Boot NOT?

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.

SB is also not meant to lock users out of controlling their own systems. Users can enrol extra keys into the system, allowing them to sign programs for their own systems. Many SB-enabled systems also allow users to remove the platform-provided keys altogether, forcing the firmware to only trust user-signed binaries.

shim is a simple software package that is designed to work as a first-stage bootloader on UEFI systems.

It was developed by a group of Linux developers from various distros, working together to make SB work using Free Software. It is a common piece of code that is safe, well-understood and audited so that it can be trusted and signed using platform keys. This means that Microsoft (or other potential firmware CA providers) only have to worry about signing shim, and not all of the other programs that distro vendors might want to support.

Shim then becomes the root of trust for all the other distro-provided UEFI programs. It embeds a further distro-specific CA key that is itself used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows for a clean delegation of trust — the distros are then responsible for signing the rest of their packages. Shim itself should ideally not need to be updated very often, reducing the workload on the central auditing and CA teams.

For extra trust and safety, from version 15 onwards the shim binary build is 100% reproducible — you can rebuild the Debian shim binary yourself to verify that no unexpected changes have been embedded in this key piece of security software.

MOK — Machine Owner Key

Generalities

A key part of the shim design is to allow users to control their own systems. The distro CA key is built in to the shim binary itself, but there is also an extra database of keys that can be managed by the user, the so-called Machine Owner Key (MOK for short).

Keys can be added and removed in the MOK list by the user, entirely separate from the distro CA key. The mokutil utility can be used to help manage the keys here from Linux userland, but changes to the MOK keys may only be confirmed directly from the console at boot time. This removes the risk of userland malware potentially enrolling new keys and therefore bypassing the entire point of SB.

There are more docs online for how to work with MOK, for example:

Generating a new key

Enrolling your key

If you also have a kernel to sign, you may wish to do the next step first as it will save you one reboot.

Источник