Установить линукс с шифрованием

Установка системы с шифрованием всего диска

Содержание

Описание руководства

Данная статья рассказывает, как создать надёжно зашифрованное хранилище данных на жестком диске компьютера и при этом не сломать спящий и ждущий режимы. Особенно актуально это для владельцев ноутбуков, т. к. в отличие от стационарных компьютеров шанс кражи/утери ноутбука выше и возникает обоснованное желание хранить информацию в зашифрованном виде. Однако, предлагаемая по-умолчанию опция шифрования домашней папки при помощи ecryptfs во-первых не шифрует корневой раздел системы 1) , а во-вторых ecryptfs шифрует раздел swap с применением случайно сгенерированного ключа, таким образом, перестает работать такая нужная в ноутбуках опция как спящий режим 2) 3) .

Предлагается же создать один большой зашифрованный раздел размером с весь диск компьютера 4) , поверх которого развернуть виртуальную группу LVM, в которой создать обычные (не шифрованные с точки зрения ОС) разделы /, /home и swap. При этом, пользователю придётся вводить пароль при каждом включении компьютера (даже при выходе из спящего режима), однако, за счёт смещения шифрования на более низкий уровень, ОС «не заметит» этого и все функции будут работать.

Установка

Итак, для установки нам потребуется диск альтернативной установки системы, который можно скачать тут. Ищите образ с alternate в названии.

Загрузите систему с alternate — диска, выберите язык и приступите к установке:

Выберите ручной режим разметки диска:

Если у вас новый диск или, если вы хотите очистить на нем таблицу разделов, выберите строку с названием диска:

и создайте на нем новую таблицу разделов:

После этого, создайте на диске раздел /boot, выбрав указателем свободное место на диске:

Укажите небольшой объем, от 300 МБ до 1ГБ, т.к. для /boot этого будет вполне достаточно:

В списке «использовать как» укажите /boot, не забудьте сделать раздел загрузочным:

Далее, не размечая оставшееся место, переходим в пункт «Настроить шифрование для томов»:

Соглашаемся записать изменения:

Выбираем «Create encrypted volumes»:

Далее выбираем (при помощи кнопки Space ) свободное место на диске и жмём «Продолжить»:

Если у вас нет паранойи, можете просто нажать «Настройка раздела закончена», если есть — установите параметр «Стереть данные» в «Да»:

Снова соглашаемся на запись изменений на диск:

Далее выбираем «Finish»:

Далее установщик попросит вас ввести парольную фразу, которой он «закроет» диск:

После этого подтвердите пароль:

Если вы используете слишком простой пароль 5) , установщик попросит подтверждения:

После создания шифрованного тома, нужно настроить LVM:

Снова соглашаемся на запись изменений:

Создаем группу томов:

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

После этого создаем логические тома:

Пример для swap:

Аналогично создаем диски для root и home, выделяя им желаемый объем. Если у вас большой диск — можете оставить некоторый его объем свободным, позднее вы сможете добавить его к любому логическому тому 6) .

После этого выбирайте «Закончить»:

Теперь нужно назначить файловые системы и точки монтирования для созданных дисков:

Выбирайте разделы, находящиеся в блоках, начинающихся на LVM, они названы, согласно именам, данным им вами при создании логических томов, например, в данном случае, это LV home, LV swap и LV root. Стоит заметить, что раздел root 7) не нужно делать загрузочным, т.к. роль загрузочного у нас выполняет отдельный раздел /boot.

По окончании, выбирайте «Закончить разметку и записать изменения на диск»:

И снова соглашаемся с записью изменений на диск (заодно можно ещё раз проверить все ли вы правильно разметили):

Далее продолжайте установку системы как обычно. Когда установщик спросит вас, зашифровать ли домашний каталог — откажитесь, ведь ваш диск уже зашифрован.

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

Изменение пароля

Работа с live-cd

Загрузитесь с live-cd 8) , выберите «Попробовать Ubuntu» и дождитесь полной загрузки системы. После этого, настройте подключение к интернету. Затем откройте терминал и выполните:

После успешной установки, переходите к этапу «Смена пароля».

Смена пароля

Описание

При установке диск шифруется при помощи связки LUKS и dm-crypt. LUKS использует в качестве идентификаторов доступа key slots, которые в данном случае выступают в виде пароля, однако могут быть и ключом. Всего доступно 8 слотов. По умолчанию (при создании шифрованного диска) используется слот 0.

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

Для операций со слотами — сначала нужно определиться с диском, на котором установлено шифрование. Выполните в терминале команду

Вывод будет примерно следующим:

Она даст вам список разделов на диске. Нужно найти тот раздел, на котором присутствует зашифрованный раздел. В данном случае это sda5.

Теперь можно просмотреть состояние слотов на этом разделе:

Видим, что слот 0 содержит пароль, а слоты 1-7 имеют статус DISABLED.

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

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

Если теперь посмотреть слоты, то станет видно, что статус ENABLED стоит теперь уже у двух слотов:

Теперь можно удалить старый пароль, находящийся в слоте 0:

И видим, что слот 0 стал DISABLED.

Заключение

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

Ссылки

Статья написана по мотивам вот этой вот статьи.

Источник

Статья Установка Arch Linux с шифрованием и ключом на флешке

Установка Arch Linux с шифрованием и ключом на флешке.

Начнем с того что данные должны находиться на шифрованном жестком диске. Это как минимум. Лучше диск должен быть съемным, причем быстро. Хорошо если ключ шифрования имеет большую длину и вводиться без ошибок. Да, нужно иметь 2 ос, одну для работы а вторую для остальных дел. Вторая ос, это Linux которая находится на шифрованном съемном диске, лучше всего SSD. В данное время некоторые ноутбуки все еще оснащаются DVD приводом, так вот его лучше снять и поставить вот такую штуку DVD HDD

Если необходим будет привод для чтения дисков то он вставляется за 5 сек. В основной ос не храним ничего противозаконного, стандартный набор софта. А вот вторая Ос шифрованная и быстросъемная. Вводить каждый раз пароль длинной 255 символов это для мазохистов, поэтому ключ будем хранить на флешке, которая вставляется только при загрузке ос, а дальше вынимается и прячется. Самый маленький размер имеет карта флеш-памяти M2, Достаточно будет и 2х гигов. В качестве флешки используем вот такой переходник

На microSD флешке храниться ключ от жесткого диска. Если что то microSD ломается и данные не востановишь. Тут можно сделать два пути, или у нас есть резервный ключ (да-да те 255 символов что брутом не осилишь) или простой пароль, который сносит все шифрование нафиг. 255 символов лучше спрятать в картинке в помощь стенография, и закинуть в инет ))). Ну или нацарапать на стене + пару символов спереди и сзади чтоб наверняка. Тк если диск изымут при обыске то никто не будет загружать ноут с ним. Делают дамп и с дампом работают. Флешка должна быть всегда вдалеке от компа, и рядом только в случае его включения. Жесткий диск лучше хранить в тайнике и только при работе вынимать его. Да и не забудь про бронированную дверь, пока ее будут вскрывать у тебя есть несколько секунд чтоб прожевать флешку и вырубить ноут, максимум разбить SSD. Если же все-таки тебя застали с работающим ноутом, то он должен выключаться автоматически через какое-то время простоя. Еще лучше если у тебя будет скрипт, который вырубит ноут. Затрет рандомом заголовок диска.

Необходимое железо и софт

Все ясно, оборудование которое понадобится

1. Ноут
2. Флешка (На нее запилю установочный образ Arch Linux)
3. Жесткий диск (Arch на шифрованном разделе + /boot на отдельном разделе этого диска)
4. Карта microSD для записи ключа шифрования
5. Второй ноут с которого буду ставить все через сеть (Ну лень мне набивать команды вручную, легче копировать через буфер).

Сливаю образ арча Arch Linux — Downloads. И программу для записи ее на флешку ROSA ImageWriter — Rosalab Wiki. Запиливаю образ на флешку. Вставляю в ноут жесткий диск на который ставлю Arch, Флеш-карточку microSD и флешку с установочным образом.

Гружусь с флешки.

Когда загрузил ноут с флешки

Wifi-menu — Подключаюсь к wi-fi
ping -c4 ya.ru — Проверяю пинг
Ifconfig -a — Смотрю адрес интерфейса
passwd root — Задаю пароль суперпользователя
systemctl start sshd.service — запуск SSH демона

На другом ноуте подключаюсь к wi-fi и подключаюсь к серверу

Смотрю все разделы которые определились

/dev/sda — Флешка образом Arch (с нее ставим Arch Linux)
/dev/sdb — Жесткий диск на который ставлю систему
/dev/sdc — Флешка для хранения ключа

Затру рандомом весь жесткий, да это очень долго так что лучше на ночь закинуть.

И вот таким образом разбиваю хард (Вместо sda у нас sdb, я делал на виртуалке, так что немного различаются названия)

Шифрую жесткий диск

Тут небольшое отступление, здесь необходимо сгенерировать хороший стойкий пароль, который лучше закинуть в картинку с помощью стенографии или нацарапать в подвале )))

Генератор паролей | LastPass можно использовать другой генератор, этот как пример.

Источник

Используем 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.

/boot остаётся незашифрованным, потому что устанавливаемый по умолчанию GRUB не может расшифровать диск без криптографических модулей. Которые почему-то не встроили в подписанный GRUB. GRUB’у запрещено загружать дополнительные модули в Secure Boot. Double Fail 1 .

GRUB должен верифицировать загружаемые ядра и отвергать неверно подписанные. Он этого не делает. Triple Fail.

GRUB загружает свои настройки из файла и по умолчанию предоставляет доступ к консоли. Подлинность конфигурационного файла не проверяется, с помощью его модификации или через консоль можно сделать что угодно: загрузить UEFI Shell, другое ядро, initramfs или передать аргументы ядру и получить root-доступ. Fatal Error 2 .

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

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

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

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

Вывод

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

Отформатируем раздел с указанием современных алгоритмов шифрования и хеширования. В режиме XTS длину ключа необходимо указывать в два раза больше, поэтому для AES-256 нужно указать ключ длиной 512 бит. Параметр —iter-time задаёт время в миллисекундах, затрачиваемое на генерацию ключа из вводимого пароля функцией PBKDF2. Большее количество итераций усложняет перебор пароля, но и увеличивает время ожидания после ввода верного пароля.

Подтвердите форматирование, написав YES, введите пароль. Теперь откройте криптоконтейнер (sda2_crypt — имя для маппинга) и введите тот же пароль.

Контейнер должен стать доступным как блочное устройство /dev/mapper/sda2_crypt. Перейдём к разметке логических томов внутри криптоконтейнера. Инициализируем физический раздел LVM поверх /dev/mapper/sda2_crypt.

Внутри этого физического раздела создадим группу томов с именем ubuntu.

Теперь мы можем создавать логические тома внутри этой группы. Первым делом создадим том для раздела подкачки и инициализируем его. Рекомендуемый размер — от sqrt(RAM) до 2xRAM в гигабайтах.

Добавим том для корня и создадим в нём файловую систему ext4. Хорошей практикой считается оставлять свободное место и расширять тома по мере необходимости, поэтому выделим для корня 20 ГБ. По желанию в свободном месте можно будет разметить дополнительные тома для home, usr, var и так далее. Выделить всё свободное место для тома можно с помощью параметра -l 100%FREE .

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

Установка

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

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

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

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

Настройка crypttab, fstab и resume

Смонтируйте корень установленной системы в /mnt, свяжите /dev, /sys и /proc с /mnt/dev, /mnt/sys и /mnt/proc соответственно, а также /etc/resolv.conf с /mnt/etc/resolv.conf, чтобы у вас был доступ к сети. Теперь смените корневой каталог с помощью chroot .

Вам необходимо вручную заполнить /etc/crypttab — файл, описывающий монтируемые при загрузке криптоконтейнеры.

В него нужно добавить запись о /dev/sda2, монтируемом в /dev/mapper/sda2_crypt. Настроим монтирование по UUID, а не по имени устройства. Чтобы узнать UUID /dev/sda2, откройте другой терминал и воспользуйтесь командой:

В строке, начинающейся с /dev/sda2, будет записан его UUID. Скопируйте его (Ctrl+Shift+C). В /etc/crypttab добавьте запись вида имя_маппинга UUID= none luks, вставив UUID (Ctrl+Shift+V). Закройте nano , нажав Ctrl+X и Y, подтвердив сохранение.

Проверьте, чтобы в /etc/fstab были правильно описаны монтируемые разделы, а в /etc/initramfs-tools/conf.d/resume указан раздел для пробуждения из гибернации.

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

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

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

Ядро Linux поддерживает загрузку напрямую из UEFI, если оно было скомпилировано с параметром CONFIG_EFI_STUB. В таком случае initramfs обычно хранится рядом в ESP, и путь к нему передаётся в аргументах к ядру.

Однако отсутствие верификации initramfs позволяет встроить в него вредоносный код, имея доступ на запись в ESP. Teddy Reed предлагает компилировать ядро, встраивая в него initramfs.

Процесс компиляции ядра достаточно длительный, её придётся производить после каждого изменения initramfs. К счастью, есть другой способ. В пакете systemd (ранее в gummiboot ) находится linuxx64.efi.stub — заготовка UEFI-приложения, в которую можно встроить ядро, initramfs и аргументы, передаваемые ядру. Подписав это UEFI-приложение, мы защитим ядро и initramfs от изменений.

Для данной операции потребуется пакет binutils .

Запишем в /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.

Если в ESP уже записан загрузчик BOOTX64.EFI, то можно создать ещё один ESP, либо записать ubuntu.efi под другим именем и добавить соответствующую загрузочную запись через встроенную в вашу прошивку консоль UEFI (UEFI Shell). Использование efibootmgr не рекомендовано 5 .

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/, изменив пути где требуется.

Дайте скрипту право на исполнение.

При обновлении ядра придётся произвести эту операцию вручную.

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

Если вам нужно установить сторонние или собственные драйвера и модули ядра, их необходимо подписать. Для подписи модулей ядра требуются сертификат в формате DER и ключ без пароля, то есть сгенерированный с параметром -nodes .

Для подписывания используется скрипт sign-file .

Чтобы добавить этот сертификат в прошивку, его необходимо преобразовать в формат 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-доступ к расшифрованному диску. Но в таком случае у злоумышленника уже есть наши данные.

«Оставить заявку» на отключение верификации модулей можно с помощью mokutil , а подтвердит её загрузчик shim .

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

По умолчанию git указывает на ветку master, соответствующую версии последнего релиза. Переключиться на другую версию можно по тегу релиза этой версии. Чтобы перечислить все теги по заданной маске, используйте git tag -l .

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

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

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

Гибернация работает, но нестабильно. Как, впрочем, и без Secure Boot.

Способ 4. Отказ от гибернации и использование виртуализации

Если гибернация и работает, то это не делает её надёжным средством сохранения состояния. Это может быть проблемой моего железа, дистрибутива или, что более вероятно, KDE Plasma, но у меня Kubuntu просыпается через раз.

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

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

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

Примечания

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

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

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

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

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

Источник