Enroll mok что значит
Немного про UEFI и Secure Boot
UEFI (Unified Extensible Firmware Interface) — замена устаревшему BIOS. Эта спецификация была придумана Intel для Itanium, тогда она еще называлась EFI (Extensible Firmware Interface), а потом была портирована на x86, x64 и ARM. Она разительно отличается от BIOS как самой процедурой загрузки, так и способами взаимодействия с ОС. Если вы купили компьютер в 2010 году и позже, то, вероятнее всего, у вас UEFI.
Основные отличия UEFI от BIOS:
Как происходит загрузка в UEFI?
С GPT-раздела с идентификатором EF00 и файловой системой FAT32, по умолчанию грузится и запускается файл \efi\boot\boot[название архитектуры].efi, например \efi\boot\bootx64.efi
Т.е. чтобы, например, создать загрузочную флешку с Windows, достаточно просто разметить флешку в GPT, создать на ней FAT32-раздел и просто-напросто скопировать все файлы с ISO-образа. Boot-секторов больше нет, забудьте про них.
Загрузка в UEFI происходит гораздо быстрее, например, загрузка моего лаптопа с ArchLinux с нажатия кнопки питания до полностью работоспособного состояния составляет всего 30 секунд. Насколько я знаю, у Windows 8 тоже очень хорошие оптимизации скорости загрузки в UEFI-режиме.
Secure Boot
«Я слышал, что Microsoft реализовывает Secure Boot в Windows 8. Эта технология не позволяет неавторизированному коду выполняться, например, бутлоадерам, чтобы защитить пользователя от malware. И есть кампания от Free Software Foundation против Secure Boot, и многие люди были против него. Если я куплю компьютер с Windows 8, смогу ли я установить Linux или другую ОС? Или эта технология позволяет запускать только Windows?»
Начнем с того, что эту технологию придумали не в Microsoft, а она входит в спецификацию UEFI 2.2. Включенный Secure Boot не означает, что вы не сможете запустить ОС, отличную от Windows. На самом деле, сертифицированные для запуска Windows 8 компьютеры и лаптопы обязаны иметь возможность отключения Secure Boot и возможность управления ключами, так что беспокоится тут не о чем. Неотключаемый Secure Boot есть только на планшетах на ARM с предустановленной Windows!
Что дает Secure Boot? Он защищает от выполнения неподписанного кода не только на этапе загрузки, но и на этапе выполнения ОС, например, как в Windows, так и в Linux проверяются подписи драйверов/модулей ядра, таким образом, вредоносный код в режиме ядра выполнить будет нельзя. Но это справедливо только, если нет физического доступа к компьютеру, т.к., в большинстве случаев, при физическом доступе ключи можно заменить на свои.
Для Linux есть 2 пре-загрузчика, которые поддерживают Secure Boot: Shim и PRELoader. Они похожи, но есть небольшие нюансы.
В Shim есть 3 типа ключей: Secure Boot keys (те, которые в UEFI), Shim keys (которые можно сгенерировать самому и указать при компиляции), и MOKи (Machine Owner Key, хранятся в NVRAM). Shim не использует механизм загрузки через UEFI, поэтому загрузчик, который не поддерживает Shim и ничего не знает про MOK, не сможет выполнить код (таким образом, загрузчик gummiboot не будет работать). PRELoader, напротив, встраивает свои механизмы аутентификации в UEFI, и никаких проблем нет.
Shim зависит от MOK, т.е. бинарники должны быть изменены (подписаны) перед тем, как их выполнять. PRELoader же «запоминает» правильные бинарники, вы ему сообщаете, доверяете вы им, или нет.
Оба пре-загрузчика есть в скомпилированном виде с валидной подписью от Microsoft, поэтому менять UEFI-ключи не обязательно.
Secure Boot призван защитить от буткитов, от атак типа Evil Maid, и, по моему мнению, делает это эффективно.
Спасибо за внимание!
Используем Secure Boot в Linux на всю катушку
Технология Secure Boot нацелена на предотвращение исполнения недоверенного кода при загрузке операционной системы, то есть защиту от буткитов и атак типа Evil Maid. Устройства с Secure Boot содержат в энергонезависимой памяти базу данных открытых ключей, которыми проверяются подписи загружаемых UEFI-приложений вроде загрузчиков ОС и драйверов. Приложения, подписанные доверенным ключом и с правильной контрольной суммой, допускаются к загрузке, остальные блокируются.
Более подробно о Secure Boot можно узнать из цикла статей от CodeRush.
Чтобы Secure Boot обеспечивал безопасность, подписываемые приложения должны соблюдать некоторый «кодекс чести»: не иметь в себе лазеек для неограниченного доступа к системе и параметрам Secure Boot, а также требовать того же от загружаемых ими приложений. Если подписанное приложение предоставляет возможность недобросовестного использования напрямую или путём загрузки других приложений, оно становится угрозой безопасности всех пользователей, доверяющих этому приложению. Такую угрозу представляют загрузчик shim, подписываемый Microsoft, и загружаемый им GRUB.
Чтобы от этого защититься, мы установим Ubuntu с шифрованием всего диска на базе LUKS и LVM, защитим initramfs от изменений, объединив его с ядром в одно UEFI-приложение, и подпишем его собственными ключами.
Ограничения решений «из коробки»
Ubuntu, как и другие распространённые дистрибутивы, предлагает опцию шифрования всего диска с LVM во время установки. Дистрибутив в такой конфигурации без ошибок устанавливается на UEFI с активным Secure Boot.
Но Canonical в первую очередь заинтересована в работоспособности ОС на устройствах с включённым Secure Boot, а не в обеспечении безопасности за счёт него. Если вы хотите использовать Secure Boot как средство безопасности, то вы сами по себе.
Как Ubuntu реализует загрузку в Secure Boot с шифрованием всего диска и что с этим не так?
Red Hat разработали загрузчик shim, чтобы он работал на всех устройствах и служил на благо человечеству, соблюдая строгие предписания стандарта Secure Boot и загружая только доверенные UEFI-приложения. Canonical использует shim как прокси, встраивая в него свой публичный ключ и подписывая у Microsoft. Shim загружает GRUB, подписанный ключём Canonical, который затем загружает ядро, подписанное Canonical.
Начнём с того, что шифруется не весь диск — /boot остаётся незашифрованным, а значит и initramfs в нём. Доступ к initramfs означает root-доступ. Fail.
GRUB должен верифицировать загружаемые ядра и отвергать неверно подписанные. Он этого не делает. Triple Fail.
Что это всё означает?
Согласно политике Microsoft о подписывании UEFI-приложений, все подписанные загрузчики GRUB и shim, используемые для загрузки GRUB, уже должны быть занесены в чёрный список.
Вывод
Необходимо отказаться от чужих ключей. Пользователь должен контролировать Secure Boot. Загрузчик должен быть подписан пользователем, все незашифрованные и доступные для записи элементы в загрузке системы должны верифицироваться. Пользовательские данные должны быть зашифрованы. Чего мы и попытаемся добиться.
Установка Ubuntu с шифрованием всего диска с помощью LUKS и LVM
LUKS — Linux Unified Key Setup — обёртка для криптографической системы dm-crypt, позволяющая создавать виртуальные зашифрованные устройства в файлах и на физических дисках. С помощью LUKS можно зашифровать данные на всём диске для того, чтобы перед загрузкой ОС требовалось ввести пароль.
LVM — Logical Volume Manager — менеджер логических томов, с помощью которого мы разделим криптоконтейнер на тома. Тома LVM автоматически монтируются после ввода пароля к криптоконтейнеру, отдельный ввод пароля для каждого тома не требуется.
Следующие инструкции должны быть применимы к любому дистрибутиву на базе Ubuntu, для других потребуются коррективы. Сперва загрузитесь с Live CD или установочного образа в режиме Try before installing.
Разметка и шифрование
Чтобы загружаться с диска в режиме UEFI, он должен быть размечен в формате GPT. Разметку диска рассмотрим с помощью KDE Partition Manager и GParted. Если у вас их нет, установите один, соответствующий вашей среде.
Запустите редактор разделов и выберите интересующий вас диск, обычно это первый в системе — /dev/sda. Посмотрите свойства диска.
В строке Partition table указана используемая таблица разделов. Если диск размечен в формате dos/msdos (MBR), то его необходимо преобразовать в GPT. Это возможно сделать без потери данных, но здесь я этого описывать не буду, поищите инструкции в интернете. Если на диске нет важных данных и вы хотите форматировать его в GPT, создайте новую таблицу.
На диске должен быть как минимум один раздел ESP (EFI System Partition), в котором будут храниться загрузчики. Если на этом диске установлена ОС в режиме UEFI, то один такой раздел уже есть. В любом случае я рекомендую создать новый размером не меньше 100 МБ. ESP должен быть отформатирован в один из FAT-форматов, предпочтительно в FAT32, а также помечен как загрузочный.
Дальше нужно создать раздел для шифрования. Тем же образом, что и ESP, только без форматирования (unformatted), выставления флагов и размером побольше — так, чтобы вместил систему и раздел подкачки. Создадим в этом разделе криптоконтейнер LUKS через терминал, предварительно перейдя в режим суперпользователя.
Подтвердите форматирование, написав YES, введите пароль. Теперь откройте криптоконтейнер (sda2_crypt — имя для маппинга) и введите тот же пароль.
Контейнер должен стать доступным как блочное устройство /dev/mapper/sda2_crypt. Перейдём к разметке логических томов внутри криптоконтейнера. Инициализируем физический раздел LVM поверх /dev/mapper/sda2_crypt.
Внутри этого физического раздела создадим группу томов с именем ubuntu.
Теперь мы можем создавать логические тома внутри этой группы. Первым делом создадим том для раздела подкачки и инициализируем его. Рекомендуемый размер — от sqrt(RAM) до 2xRAM в гигабайтах.
С разметкой закончено, можно перейти к установке.
Установка
Так как мы планируем создать загрузчик самостоятельно, да и установщик Ubuntu не поддерживает шифрование /boot, запустим установку без создания загрузчика.
На этапе разметки диска выберите Вручную.
Здесь нам необходимо указать точки монтирования. Выберите /dev/mapper/ubuntu-root, укажите использование в качестве журналируемой файловой системы Ext4, точку монтирования (Mount Point) в /, без форматирования. Ubiquity сама подхватит /dev/mapper/ubuntu-swap как раздел подкачки и запомнит один из системных разделов EFI. Экран разметки должен выглядеть так:
Закончите установку и не перезагружайтесь.
Настройка crypttab, fstab и resume
Вам необходимо вручную заполнить /etc/crypttab — файл, описывающий монтируемые при загрузке криптоконтейнеры.
В него нужно добавить запись о /dev/sda2, монтируемом в /dev/mapper/sda2_crypt. Настроим монтирование по UUID, а не по имени устройства. Чтобы узнать UUID /dev/sda2, откройте другой терминал и воспользуйтесь командой:
Проверьте, чтобы в /etc/fstab были правильно описаны монтируемые разделы, а в /etc/initramfs-tools/conf.d/resume указан раздел для пробуждения из гибернации.
После всех изменений обновите образ initramfs.
Создание загрузчика
Ядро Linux поддерживает загрузку напрямую из UEFI, если оно было скомпилировано с параметром CONFIG_EFI_STUB. В таком случае initramfs обычно хранится рядом в ESP, и путь к нему передаётся в аргументах к ядру.
Однако отсутствие верификации initramfs позволяет встроить в него вредоносный код, имея доступ на запись в ESP. Teddy Reed предлагает компилировать ядро, встраивая в него initramfs.
Процесс компиляции ядра достаточно длительный, её придётся производить после каждого изменения initramfs. К счастью, есть другой способ. В пакете systemd (ранее в gummiboot ) находится linuxx64.efi.stub — заготовка UEFI-приложения, в которую можно встроить ядро, initramfs и аргументы, передаваемые ядру. Подписав это UEFI-приложение, мы защитим ядро и initramfs от изменений.
Запишем в /tmp/cmdline аргументы, которые будут передаваться ядру.
В /boot хранятся образы ядра (vmlinuz-*-generic) и initramfs (initrd.img-*-generic). Определите последнюю версию и встройте их в заготовку.
Полученное UEFI-приложение ubuntu.efi необходимо расположить в ESP в каталоге EFI/BOOT/. Установщик Ubuntu должен был определить ESP и настроить монтирование в /boot/efi. Если в этом ESP нет других загрузчиков, то ubuntu.efi можно скопировать в /boot/efi/EFI/BOOT/BOOTX64.EFI, тогда он будет загружаться при выборе этого раздела в меню загрузки UEFI.
UPD: Если в вашу прошивку не встроен UEFI Shell, то скачать его можно отсюда. Положите его в EFI/BOOT/BOOTX64.EFI любого ESP и загружайтесь с отключённым Secure Boot. Чтобы добавить загрузочную запись, введите команду:
Спасибо Prototik за ссылку на UEFI Shell. Список остальных команд можно найти здесь.
Если у вас включён Secure Boot, то загрузиться с ubuntu.efi не получится, так как он не подписан. Временно отключите Secure Boot и загрузитесь, либо продолжите из chroot.
Настройка Secure Boot
Генерацию ключей, их установку в прошивку и подписывание UEFI-приложений описал CodeRush здесь, поэтому я буду считать, что вы всё понимаете и умеете.
Остаётся только подписать созданный нами загрузчик.
Поместите BOOTX64.EFI в каталог EFI/BOOT/ раздела EFI, с которого вы планируете загружаться.
Автоматизация
Чтобы загрузчик автоматически обновлялся и подписывался при обновлении initramfs, создайте скрипт update-efi-loader в /etc/initramfs/post-update.d/, изменив пути где требуется.
Дайте скрипту право на исполнение.
При обновлении ядра придётся произвести эту операцию вручную.
Подписывание драйверов и модулей ядра
Чтобы добавить этот сертификат в прошивку, его необходимо преобразовать в формат PEM, затем в ESL и подписать ключом KEK.
Очевидные советы
Если вашей задачей стоит защита данных на устройстве, то Secure Boot выполнит свою работу и не больше. Остальное возлагается на вас.
Не добавляйте чужих ключей в прошивку. Даже от Microsoft. В первую очередь от Microsoft.
Не подписывайте UEFI Shell, KeyTool или другие приложения, имеющие доступ к записи в NVRAM. Используйте их в Setup Mode.
Не оставляйте устройство включённым без присмотра. Устройство в ждущем режиме (suspend to RAM) содержит в RAM расшифрованные данные и мастер-ключи от криптоконтейнеров.
Установите пароль на UEFI Setup не проще, чем от вашего криптоконтейнера.
При физическом доступе к внутренностям устройства можно отключить Secure Boot, сбросив память NVRAM или повредив её, а также оставить хардварную закладку. Такая атака успешна только тогда, когда она незаметна. Сделайте так, чтобы вы о ней могли узнать: заклейте винты на корпусе трудновоспроизводимыми стикерами, обмажьте их лаком с блёстками. Опечатайте своё устройство.
Поставьте первым в списке загрузки неподписанное приложение. Если вы однажды не увидите сообщение от Secure Boot, то ваше устройство однозначно скомпрометировано.
Надёжнее отключённого от интернета устройства, хранимого в сейфе, всё равно ничего не придумаешь. Уязвимости в реализации Secure Boot в конкретных прошивках не исключены.
Бонус: возвращение гибернации
При шифровании всего диска вместо ждущего режима для сохранения состояния и продолжения работы с места остановки обычно используется гибернация, она же спящий режим или suspend to disk.
Из соображений безопасности разработчики ядра отключили возможность гибернации при включённом верифицировании модулей ядра. Аргументируется это тем, что образ восстановления не верифицируется при пробуждении, раздел подкачки может быть подменён и тогда система проснётся с непроверенным и потенциально вредоносным кодом.
Это верно в том случае, если initramfs не верифицируется и/или раздел подкачки не зашифрован. Однако независимо от использования гибернации при таких условиях initramfs может быть подменён, а чувствительные данные восстановлены из раздела подкачки. В нашей конфигурации initramfs верифицируется, будучи включённым в подписанный загрузочный файл, а раздел подкачки зашифрован. Значит, данное ограничение для нас бессмысленно.
Chung-Yi Lee ещё в 2013 предложил верифицировать образ восстановления, а в 2015 представил реализующий его идею патч. Но воз и ныне там. Поэтому предположим, что мы достаточно защищены с нашим шифрованием, и вернём нам гибернацию без верификации.
Способ 1. Отключить верификацию модулей ядра
Включённая верификация модулей ядра отключает гибернацию. По умолчанию верификация модулей ядра включается вместе с Secure Boot, однако она от Secure Boot не зависит. Её можно отключить, оставив только Secure Boot.
Большого ущерба безопасности это нанести не должно. Модули ядра устанавливаются из доверенного источника вместе с обновлением ядра и хранятся на зашифрованном диске и в верифицируемом initramfs. Сторонние драйвера устанавливаются вручную, и будут они подписаны нами или нет, значения не имеет, ведь мы им уже доверяем. SecureApt для ядра и TLS/HTTPS для сторонних драйверов должны защитить от MiTM, и тогда остаётся только root-доступ к расшифрованному диску. Но в таком случае у злоумышленника уже есть наши данные.
Введите пароль, который затем потребуется посимвольно подтвердить. Теперь нужно загрузиться через shim и выбрать в нём Change Secure Boot state (sic!). Поместите /usr/lib/shim.efi в EFI/BOOT/BOOTX64.EFI на одном из ESP или добавьте загрузочную запись через UEFI Shell. Предварительно отключите Secure Boot, после верните обратно.
UPD 12.01.17: Вместе с shim.efi необходимо сохранять рядом и MokManager. В последних версиях пакета shim.efi и MokManager располагаются в /usr/lib/shim/, shimx64.efi и mmx64.efi.signed соответственно. Нужно переименовать mmx64.efi.signed в mmx64.efi.
Сейчас Secure Boot и гибернация работают, UEFI-приложения верифицируются, но модули ядра нет.
В принципе, shim и mokutil больше не требуются, их можно удалить.
Способ 2. Использовать старую версию ядра
Патч, отключающий гибернацию, появился в версии Ubuntu-4.4.0-18.34. Ubuntu-4.4.0-17.33 должна быть от него свободна. Однако оставаться на старом ядре, игнорируя обновления безопасности, не лучший вариант.
Способ 3. Скомпилировать своё ядро
Если ваше время ничего не стоит, то вы можете скомпилировать своё ядро без этого ограничения. Гарантий, что после долгих мучений вы будете довольны результатом, нет. Но если вы этого очень хотите, хвала Линусу Торвальдсу и GPLv2, у вас есть на это право. Вы можете предварительно протестировать скомпилированное мною ядро, чтобы не тратить зря время.
Получение исходного кода
apt-get
Самый простой способ получить исходный код для ядра вашей версии — скачать его из репозитория.
В /etc/apt/sources.list должны присутствовать указатели на репозитории исходных кодов. Обычно там уже есть закомментированные записи с deb-src. Раскомментируйте их для репозиториев xenial main и xenial-security main, либо добавьте сами, а затем обновите индекс apt.
Загрузите исходный код и перейдите в создавшуюся директорию.
Обратите внимание на то, чтобы apt скачивал актуальную версию исходного кода. Проверьте номер версии у файла .dsc.
Если вы хотите поддерживать ядро в актуальном состоянии и перекомпилировать его по мере выхода обновлений с сохранением своих изменений, выберите git. Первоначальная загрузка займёт продолжительное время.
Создайте локальную копию git-репозитория ядра текущего релиза Ubuntu и перейдите в создавшуюся директорию.
Создайте ветку temp для тега, соответствующего вашей версии, и переключитесь на неё.
Настройка
Загрузите пакеты, требуемые для компиляции (build dependencies).
Убедитесь, что скриптам выставлено право на исполнение, запустите чистку.
Скопируйте старый файл конфигурации в текущую директорию, запустите конфигурацию, выберите Load и загрузите config. Больше изменять ничего не требуется, выйдите и сохраните конфигурацию — Exit → Yes.
Измените файл kernel/power/hibernate.c, убрав проверку secure_modules().
Подготовьте файл к коммиту.
Если вы ещё не совершали коммитов и не вводили свои данные, сделайте это сейчас.
Сделайте коммит, введите комментарий.
Теперь ваши изменения сохранены в новом снимке состояния (snapshot). Если вы захотите обновиться до следующей версии и применить к ней те же самые изменения, используйте git rebase
Скрипты компиляции определяют версию ядра по последней записи в истории изменений (changelog) в директории debian.master. Добавьте новую запись, чтобы изменить версию.
К версии будет добавлен суффикс custom1, что отразится при сборке пакетов .deb и позволит установить их при уже установленных пакетах той же версии без суффикса. Однако этот суффикс распространяется только на имя пакета, но не на его содержимое: ядро и директория с его модулями будут иметь ту же версию 4.4.0-34-generic, и при установке старые файлы перезапишутся новыми. Чтобы этого избежать, измените версию ABI c 34 на, например, 3400.
Компиляция
Запустите чистку ещё раз и скомпилируйте ядро. Если вы не опытный разработчик ядра и не понимаете, как работают проверки ABI и модулей (я вот не понимаю), отключите их (skipabi=true, skipmodule=true), иначе ваша компиляция сломается на одном из последних этапов. Здесь используется многопоточная сборка пакетов с количеством потоков, равным количеству ядер процессора. Цель binary-generic означает компиляцию обычной разновидности ядра, архитектура определяется автоматически.
Снова соберите загрузочный файл.
Гибернация работает, но нестабильно. Как, впрочем, и без Secure Boot.
Способ 4. Отказ от гибернации и использование виртуализации
Если гибернация и работает, то это не делает её надёжным средством сохранения состояния. Это может быть проблемой моего железа, дистрибутива или, что более вероятно, KDE Plasma, но у меня Kubuntu просыпается через раз.
С большей надёжностью придёт и большая защищённость: чувствительные данные можно изолировать от опасной среды. Браузер и песочница для установки стороннних пакетов в одной виртуальной машине, важные персональные данные — в другой. Украсть мастер-ключ от зашифрованного диска в памяти хостовой ОС из гостевой гораздо сложнее. Кажется, для подобного существует Qubes OS. Но она данный момент не поддерживает Secure Boot. Fail.
На этом всё, приветствуются любые дополнения и замечания.
Примечания
↑ Теоретически можно исправить, установив пароль, встроив grub.cfg в образ GRUB с помощью grub-mkstandalone и установив в grub.cfg prefix на невалидный путь, чтобы GRUB не мог найти второй grub.cfg на диске. Но опять же требуется подписывать образ самостоятельно.
↑ А он есть у всех кроме параноиков оправданно озабоченных своей безопасностью пользователей.
↑ У меня загрузиться с USB не даёт. Windows 8 и 10 также без пароля не пускают в безопасный режим или консоль.
↑ Говорят, некоторые прошивки он окирпичивает. Безопаснее создать по ESP на каждый загрузчик.
Управление загрузчиками EFI в Linux: режим безопасной загрузки Secure Boot
Кроме реализации нового протокола загрузки, в UEFI добавлена новая функция, которая потенциально может вызвать много путаницы и проблем, но она также может улучшить безопасность системы: режим безопасной загрузки Secure Boot. Как следует из названия, режим Secure Boot является средством обеспечения безопасности. Его потенциал повышения безопасности системы будет наибольшим в системах Windows. Но, режим Secure Boot, из-за из своих особенностей, может усложнить загрузку Linux. В статье описывается, что представляет собой режим Secure Boot и как на него реагирует сообщество Linux. Имейте в виду, что ситуация меняется быстро, так что если вы читаете текст через несколько месяцев после его обновления, то положение дел уже могло измениться!
Что такое режим безопасной загрузки Secure Boot?
В течение десятилетий персональные компьютеры страдали от вирусов, червей и других вредоносных программ. Некоторые из самых ранних вирусов для персональных компьютеров распространялись как вирусы загрузочного сектора: Они размещались в виде кода в загрузочных секторах дискет и, когда пользователи загружали свои компьютеры с помощью зараженных дискет DOS, передавались от одного компьютера к другому. Несмотря на то, как дискеты потеряли свою важность, и широкую известность приобрели другие пути передачи вирусов, а обычным делом стало подключение к сети Интернет, вредоносный код, попадающий в компьютер во время начальной загрузки, всегда среди приоритетных интересов у авторов вредоносных программ. За счет того, что он выполняется раньше, чем ядро ОС возьмет управление над компьютером, вредоносная программа может «спрятаться» такими способами, которыми не удастся воспользоваться после того, как операционная система берет на себя управление. Предварительно загруженная вредоносная программа может стать невидимой для операционной системы, и антивирусным сканерам практически не удается обнаружить вредоносные программы, по крайней мере, без перезагрузки в спасательную систему, которая не заражена.
В BIOS совсем мало возможностей защиты от инфицирования предварительно загружаемыми вредоносными программами; когда происходит загрузка BIOS, ОС неявно доверяет всему, что выполняется в качестве загрузчика. До конца 2012 года это утверждение также было справедливо для большинства промышленных реализаций EFI. И для того, чтобы в процесс загрузки добавить дополнительный слой защиты был создан режим Secure Boot. При включенном режиме Secure Boot для любой программы EFI, которая запускается прошивкой, в прошивке проверяется наличие криптографической подписи. Если криптографическая подпись отсутствует, не соответствует ключу, хранящемуся в энергонезависимой памяти компьютера, или указана в энергонезависимой памяти в черном списке, то прошивка отказывается выполнять программу. Конечно, это просто начало процесса; надежный загрузчик EFI должен продолжить процесс загрузки в безопасном режиме, что в конечном счете приведет тому, что безопасной будет сама операционная система. Автору вирусов потребовалось бы создать подписанный вирус, что более трудно в случае, если пользователи контролируют работу с системными клавишами. Таким образом, предварительно загружаемая вредоносная программа может быть заблокирована. Есть масса способов чтобы затем сделать что-нибудь не так, как надо, но режим Secure Boot обеспечивает, по меньшей мере, основу, на которой можно будет создать в целом безопасный компьютер, по крайней мере, в теории!
В описании режима Secure Boot в спецификациях UEFI не предлагается никаких механизмов создания доверительной сети для ключей этого режима. Если исходить только из спецификаций UEFI, то можно решить, что режим Secure Boot будет активироваться непосредственно там, где компьютеры будут использоваться; администраторам на местах следует подписывать загрузчики, которые они используют, защищаясь тем самым от авторов вредоносных программ. Но, фирма Microsoft включила в свою сертификационную программу Windows 8 требование, которое обязывает продавцов поставлять компьютеры с включенным режимом Secure Boot. На практике это означает, что производители должны добавлять на свои компьютеры ключи от фирмы Microsoft, и если производители не будут добавлять другие ключи, то работать будут только загрузчики, подписанные Microsoft.
Затравкой первоначального публичного обсуждения этих вопросов был в сентябре 2011 года блог Мэтью Дж. Гарретта (Matthew J. Garrett), разработчика из Red Hat. Большая часть первоначального обсуждения на веб-форумах и в других общественных местах была исключительно паническая, и даже через год я иногда вижу слишком нервные посты. Я призываю успокоиться; как описано в этой статье, есть, по крайней мере, три способа решения режима Secure Boot: его отключение, использование предварительно подписанного загрузчика или использование своих собственных ключей.
Отключение режима Secure Boot
Если вы не уверены, что режим Secure Boot улучшит безопасность вашей системы, вы можете полностью его отключить. Учитывая тот факт, что большинство вредоносных программ нацелено на Windows, этот подход является наиболее разумным на компьютерах, на которых не работают системы Windows. Для того, чтобы сделать это, вы должны хорошо ориентироваться в экранах настройки, имеющихся в вашей прошивке. К сожалению, место, где должны находиться параметры режима Secure Boot, или способ, как их можно вызывать, не стандартизованы; поэтому я не могу предоставить процедуру, которая будет работать на любом компьютере. Однако я могу описать параметры на одном компьютере, который у меня есть и в котором поддерживается режим Secure Boot: материнская плата ASUS P8H77-I. Эта плата поставляется с отключенным режимом Secure Boot, но, основываясь на моем практическом опыте, я могу представить, как эта плата будет поставляться в случае, если бы она использовалась на компьютере с предварительно установленной системой Windows 8. Исходя из этих предположений, вам для того, чтобы отключить режим Secure Boot, потребуется выполнить следующее:
Конечно, прошивка вашего компьютера, скорее всего, будет отличаться от моей. Лучше всего, если вы хотите отключить режим Secure Boot, вам следует изучить параметры прошивки (настроек setup-а) вашей собственной системы. В вашей инструкции эта информация может присутствовать, либо ее там может не быть. В случае с моей материнкой ASUS P8H77-I, в руководстве не упоминалось о параметрах режима Secure Boot; я должен был разобраться с этим методом проб и ошибок. Я слышал о ситуациях, которые как лучше, так и хуже, чем с моей материнкой ASUS. В «лучшей» ситуации был пункт меню, снабженный довольно очевидным названием Secure Boot и варианты настройки Enabled (Включить) и Disabled (Выключить). В «худшей» ситуации, о которой я слышал от других, при попытке отключить режим Secure Boot красным цветом выдавались страшные сообщения, либо прежде, чем вы смогли бы получить доступ к прошивке, требовалось загрузится в Windows, и запускать программу, работающую под Windows.
Использование подписанного загрузчика
Использование программы Shim из системы Fedora
Чтобы соответствовать целям режима Secure Boot, загрузчик Linux должен обеспечивать аутентификацию ядра Linux, а дистрибутив Linux должен обеспечить дополнительные меры безопасности в тех ядрах, которые им предлагаются. К сожалению, эти цели не в ладах с философией свободы открытого исходного кода и свободой пользователей, позволяющей управлять своими компьютерами. Поэтому решение Secure Boot для Linux должно балансировать между этими двумя целями. Это именно то, что делает программа shim, созданная в системе Fedora. Она делает это с помощью поддержки использования следующих трех различных типов ключей:
Примечание: Вы можете спросить, почему эти возможности нельзя добавить в существующий загрузчик, например, в GRUB 2. Против этого есть несколько причин. Одна из них относится непосредственно к вопросам договоренностей: Как пишет в блоге Джеймса Боттомли (James Bottomley) в этом блоге, Microsoft отказывается подписывать двоичные файлы, распространяемые под некоторыми открытыми лицензиями, в том числе под лицензией GPLv3, которая используется как в GRUB 2, так и в rEFInd. Другая причина относится к сфере практики: загрузчик, такой как GRUB 2, является большой программой, которую в случае обнаружения ошибок велика может потребоваться быстро заменить. Но процесс подписания с участием третьих лиц может замедлить процесс выпуска релиза, что поставщики дистрибутивов считают неприемлемым.
Весь смысл режима Secure Boot состоит в том, чтобы предотвратить попытки вредоносной программы получить контроль над компьютером. Поэтому, когда загрузка происходит с включенным режимом Secure Boot, система Fedora 18 ограничивает действия, которые некоторые пользователи Linux считают само собой разумеющимися. Например, должны быть подписаны модули ядра Linux, что затрудняет использование драйверов ядра сторонних производителей, таких как те, которые необходимы проприетарным видеодрайверам фирм Nvidia и AMD/ATI. Чтобы запустить локально-скомпилированное ядро, вы должны подписать его ключом МОК и зарегистрировать этот ключ МОК в системе. Общий объем подобных ограничений полностью зависит от тех, кто разработал и подписал загрузчик, запускаемый с помощью программы shim, и ядра, запускаемого с помощью этого загрузчика. Скорее всего, что в некоторых дистрибутивах будут поставляться ядра, которые будут сравнительно не сильно обременены добавлением ограничений безопасности.
Примечание: Описанная здесь процедура утомительна, т.к. она требует самостоятельного подписывания загрузчиков и ядер. Как только в дистрибутивах появится программа shim, трудность этого процесса резко снизится. Если вам повезет, вы сможете использовать Ubuntu 12.10 или Fedora 18 с включенным режимом Secure Boot и не замечать отличие от установки без использования режима Secure Boot.
Если вы хотите сейчас использовать программу shim, то с практической точки зрения у вас есть три варианта: Вы можете запустить Ubuntu 12.10; вы можете запустить Fedora 18, или вы можете запустить подписанную версию, созданную Мэтью Гарретт (Matthew Garrett), добавить свой собственный ключ MOK и подписать любой двоичный файл, который захотите. К сожалению, прямо сейчас этот процесс все еще немного утомителен. Вкратце, он выглядит следующим образом:
Введите следующие две команды для создания своих открытых и закрытых ключей:
Скопируйте файл MOK.cer в каталог, где его сможет прочитать ваш загрузчик EFI, например, загрузчик ESP вашего компьютера.
Примечание: Версия 0.2 программы shim не может напрямую запускать ядра Linux. Вам все еще нужно использовать shim в сочетании с загрузчиком, например, старой версией GRUB, GRUB 2 или ELILO. Поскольку gummiboot запускает Linux с помощью системных вызовов EFI, он не будет работать с программой shim. То же самое касается программы rEFInd версий 0.4.7 и более ранних, но начиная с версии 0.5.0 rEFInd может «общаться» с программой shim и использовать ее для аутентификации загрузчиков, которые запускаются.
Нажмите клавишу со стрелкой, указывающей вниз, и для того, чтобы выбрать вариант Enroll key from disk (Взять ключ с диска), нажмите клавишу Enter. Экран будет очищен и вам будет предложено выбрать ключ, например, следующим образом:
В будущем, использовать программу shim будет легче, поскольку в дистрибутивах будут поставляться предварительно подписанные загрузчики, что устранит необходимость выполнения большинства этих шагов. Тем не менее, если вы хотите подписать свои собственные двоичные модули, вы все равно должны установить программное обеспечение, позволяющее подписывать программы, добавить свой собственный ключ через программу MokManager, и подписать двоичные файлы, которые вы создали самостоятельно или получили из другого источника.
Проверка ваших загрузчиков
Использование загрузчика PreLoader от Linux Foundation
С практической точки зрения, у PreLoader есть преимущество в случае, если вы хотите запустить не подписанный загрузчик (например, со старого дистрибутива Linux), либо если вы хотите распространять загрузочный образ системы, но у вас нет средств для оплаты вашего собственного ключа для подписи. Если вы не сильны с технической точки зрения, то в таких случаях загрузчик PreLoader особенно полезен, поскольку вам не нужно иметь дело с подписыванием ключей так, как это описано для случая применения программы shim. Если в вашем дистрибутиве подписаны загрузчики и/или ядра, то вам лучше отказаться от использования shim. Если загрузчики вашей системы (возможно, в том числе ее ядра) меняются редко и если вы готовы подписывать ключи, то любая из программ будет работать одинаково хорошо.
Чтобы использовать загрузчик PreLoader, выполните следующие действия:
Примечание: К сожалению, программа HashTool имеет очень серьезное ограничение: она может запоминать хэши только тех двоичных файлов, которые хранятся на диске, с которого эта программа запущена. Таким образом, вам, возможно, потребуется либо скопировать программу HashTool на диск, на котором хранятся ваши исполняемые файлы, либо скопировать двоичные файлы на диск, на котором хранится программа HashTool. После того, как вы запомните хэш двоичного файла, он будет работать при запуске из любого места.
В этот момент ваш компьютер должен перезагрузиться в ваш обычный загрузчик и, если вы зарегистрировали ядра и последующие загрузчики с помощью HashTool, то у вас у должна быть возможность запускать эти двоичные файлы так, как если бы они были подписаны ключом Secure Boot вашей платформы. Такая регистрация является важным пунктом. Если вы для запуска ядер Linux пользуетесь загрузчиком rEFInd или gummiboot, то вам необходимо регистрировать каждое новое ядро, когда вы (или системы пакетов вашего дистрибутива) его устанавливаете. Этот факт также означает, что у вас должна быть возможность запуска HashTool. ELILO это сделать не может, но вы можете для того, чтобы иметь возможность запускать программу HashTool, настроить rEFIt, rEFInd, gummiboot, GRUB Legacy и GRUB 2. На самом деле, загрузчик rEFInd версии 0.6.7 и последующих версий распознает двоичным модуль HashTool.efi и предоставляет на главном экране для него тег.
На самом деле загрузчик PreLoader использует за кулисами тот же список ключей MOK, что и программа shim; просто PreLoader использует его для хранения хэш-значений программ, а не их ключей. Вполне возможно, что в будущем программа shim и PreLoader будут приобретать черты друг друга. Однако на данный момент, если вы хотите использовать ключи, вы должны пользоваться программой shim, а если вы хотите использовать хэши не подписанных двоичных файлов, вы должны пользоваться загрузчиком PreLoader. Теоретически вам должно быть достаточно иметь возможность использовать один из этих инструментов с тем, чтобы запустить другой для последующего запуска вашего загрузчик, и это должно позволить вам использовать для проверки подлинности либо ключи, либо хэш-значения. Однако, я эту возможность не пробовал.