Linux secure boot что это

Как работает Secure Boot (безопасная загрузка) в Windows 8 и 10 и что она означает для Linux

Современные ПК поставляются с включённой функцией Secure Boot («Безопасная загрузка»). Это функция платформы в UEFI, которая заменяет традиционный BIOS ПК. Если производитель ПК хочет наклеить наклейку с логотипом «Windows 10» или «Windows 8» на свой компьютер, Microsoft требует, чтобы он включил безопасную загрузку и следовал некоторым рекомендациям.

К сожалению, это также мешает вам установить некоторые дистрибутивы Linux, что может быть довольно хлопотным.

Как безопасная загрузка защищает процесс загрузки вашего ПК

Безопасная загрузка предназначена не только для того, чтобы усложнить работу с Linux. Включение безопасной загрузки даёт реальные преимущества в плане безопасности, и даже пользователи Linux могут извлечь из этого пользу.

Традиционный BIOS загрузит любое программное обеспечение. Когда вы загружаете компьютер, он проверяет аппаратные устройства в соответствии с настроенным вами порядком загрузки и пытается загрузиться с них. Типичные ПК обычно находят и загружают загрузчик Windows, который загружает полную операционную систему Windows. Если вы используете Linux, BIOS найдёт и загрузит загрузчик GRUB или systemd-boot, которые используется в большинстве дистрибутивов Linux.

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

Безопасная загрузка предназначена для предотвращения этого. ПК с Windows 8 и 10 поставляются с сертификатом Microsoft, хранящимся в UEFI. UEFI проверит загрузчик перед его запуском и убедится, что он подписан Microsoft. Если руткит или другое вредоносное ПО действительно заменяет ваш загрузчик или вмешивается в него, UEFI не позволит ему загрузиться. Это не позволяет вредоносным программам захватить процесс загрузки и скрыться от вашей операционной системы.

Как Microsoft разрешает дистрибутивам Linux загружаться с безопасной загрузкой

Теоретически эта функция предназначена только для защиты от вредоносных программ. Так что Microsoft предлагает способ помочь дистрибутивам Linux загрузиться в любом случае. Вот почему некоторые современные дистрибутивы Linux, такие как Ubuntu и Fedora, «просто работают» на современных ПК даже с включённой безопасной загрузкой. Дистрибутивы Linux могут заплатить единовременную плату в размере 99 долларов за доступ к порталу Microsoft Sysdev, где они могут подать заявку на подпись своих загрузчиков.

Дистрибутивы Linux обычно имеют подпись shim («прокладка»). shim — это небольшой загрузчик, который просто загружает основной загрузчик GRUB дистрибутива Linux. Прокладка, подписанная Microsoft, проверяет, загружается ли загрузчик, подписанный дистрибутивом Linux, а затем дистрибутив Linux загружается нормально.

Ubuntu, Fedora, Red Hat Enterprise Linux и openSUSE в настоящее время поддерживают безопасную загрузку и будут работать без каких-либо настроек на современном оборудовании. Могут быть и другие, но это те, о которых мы знаем. Некоторые дистрибутивы Linux с философской точки зрения возражают против подачи заявки на подписку Microsoft.

Как отключить безопасную загрузку или управлять ею

Если бы безопасная загрузка была обязательной, вы не смогли бы запускать на своём ПК операционные системы, не одобренные Microsoft. Но вы, вероятно, можете управлять безопасной загрузкой из прошивки UEFI вашего ПК, которая похожа на BIOS на старых ПК.

Есть два способа контролировать безопасную загрузку. Самый простой способ — перейти к настройкам прошивки UEFI и полностью отключить Secure Boot.

Прошивка UEFI перестанет проверять, используете ли вы подписанный загрузчик или нет, и всё будет загружаться. Вы можете загрузить любой дистрибутив Linux или даже установить Windows 7, которая не поддерживает безопасную загрузку. Windows 8 и 10 будут работать нормально, вы просто потеряете преимущества безопасности, связанные с безопасностью загрузки, защищающей процесс загрузки.

Вы также можете дополнительно настроить безопасную загрузку. Вы можете контролировать, какие сертификаты для подписи предлагает безопасная загрузка. Вы можете свободно устанавливать новые сертификаты и удалять существующие. Например, организация, использующая Linux на своих ПК, может удалить сертификаты Microsoft и установить вместо них собственный сертификат организации. Тогда эти ПК будут использовать только загрузчики, одобренные и подписанные этой конкретной организацией.

Человек тоже может это сделать — вы можете подписать свой собственный загрузчик Linux и быть уверенным, что ваш компьютер может загружать только загрузчики, которые вы скомпилировали и подписали лично. Именно такой контроль и мощность предлагает безопасная загрузка.

Что Microsoft требует от производителей ПК

Microsoft не просто требует, чтобы поставщики ПК включили безопасную загрузку, если им нужна наклейка с сертификатом «Windows 10» или «Windows 8» на своих ПК. Microsoft требует, чтобы производители ПК реализовывали его особым образом.

Для ПК с Windows 8 производители должны были дать вам возможность отключить безопасную загрузку. Microsoft потребовала от производителей ПК передать пользователям аварийный выключатель безопасной загрузки.

Для ПК с Windows 10 это больше не является обязательным. Производители ПК могут включить безопасную загрузку и не давать пользователям возможность её выключить. Однако на самом деле нам неизвестно о каких-либо производителях ПК, которые так поступают.

Точно так же, хотя производители ПК должны включать основной ключ Microsoft Windows Production PCA для загрузки Windows, им не нужно включать ключ Microsoft Corporation UEFI CA. Этот второй ключ только рекомендуется. Это второй необязательный ключ, который Microsoft использует для подписи загрузчиков Linux. Документация Ubuntu объясняет это.

Другими словами, не все ПК обязательно будут загружать подписанные дистрибутивы Linux с включённой безопасной загрузкой. Опять же, на практике мы не видели ни одного компьютера, который делал бы это. Возможно, ни один производитель ПК не захочет выпускать единственную линейку ноутбуков, на которую нельзя установить Linux.

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

Безопасную загрузку нельзя отключить в Windows RT, но Windows RT мертва

Все вышесказанное верно для стандартных операционных систем Windows 8 и 10 на стандартном оборудовании Intel x86. Для ARM всё иначе.

В Windows RT — версии Windows 8 для оборудования ARM, которая поставлялась на Microsoft Surface RT и Surface 2, среди других устройств — безопасную загрузку нельзя было отключить. Сегодня безопасную загрузку по-прежнему нельзя отключить на оборудовании Windows 10 Mobile, другими словами, на телефонах под управлением Windows 10.

Это потому, что Microsoft хотела, чтобы вы думали о системах Windows RT на базе ARM как об «устройствах», а не о ПК. Как Microsoft сообщила Mozilla, Windows RT «больше не Windows».

Однако Windows RT теперь мертва. Версии настольной операционной системы Windows 10 для ARM-оборудования не существует, так что вам больше не о чем беспокоиться. Но если Microsoft вернёт оборудование Windows RT 10, вы, скорее всего, не сможете отключить на нем безопасную загрузку.

Источник

Почему 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-вариантом установки ОС.

Источник