grub (2.06) + luks2 = не работает

Кто-то сумел завести luks2 + grub?

Заводится включением в initramfs хук encrypt. Пароль вводишь не в грабе. Он вообще к шифрованию не причастен.

вообще-то насколько я знаю причастен. Граб пытается вычитать свой конфиг, собственно на этом этапе он и валится. Аналогичная ситуация если у тебя например перестраивающийся RAID 5/6 - он просто видит кашу на винте.

https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption#Dracut

Всё что ты делаешь в grub – это указываешь параметром ядра где находится зашифрованный раздел, расшифровка и монтирование происходит средствами initramfs. Grub умеет расшифровывать luks на прямую, но только luks1.

пример /etc/default/grub в студию

Зачем вообще нужен гроб? Ну, кроме необходимости загрузки с legacy BIOS.

EFI Stub и initramfs в одном бинарнике с ядром решают большинство проблем.

А зачем шифровать /boot? Разве туда может случайно утечь секрет?

в теории подмена initrd/ядра со скомпроментированным luks

А зачем шифровать /boot?

подмена initrd/ядра со скомпроментированным luks

this

От этого спасает не шифрование, а измерения внешней по отношению к исполняемому потоку системой.

Если /boot просто зашифрован (даже с помощью LUKS), то это не помешает злоумышленнику подменить его своей (зашифрованной другим ключом или вовсе незашифрованной) версией.

А сам груб так же подменить не получится?

Получится. От этого на PC/x86 спасёт либо Secure Boot (при условии, что злоумышленник не может вскрыть корпус ПК или как-то иначе сбросить настройки, либо заменить прошивку) и/или TPM (ключ от корня положить в него, а при загрузке вводить PIN с политикой «критические загрузочные компоненты не были модифицированы»).

Официально писали про поддержку luks2 в свежем грабе, а по факту (как я понял) оно не умеет до сих пор в новый формат ключей Argon2i, но может в старый PBKDF2

Да, это так. В рассылке есть патч, который добавляет поддержку Argon2i, как один из способов решения проблемы - можно скомпилировать grub с этим патчем.

При подсовывании luks2 + PBKDF2 + lvm - не работает, lvmid не найден.

Нужно разбираться, смотреть разметку диска, выхлопы lvdisplay и проч. Также нужно загрузиться в командную строку grub и посмотреть какие разделы доступны после открытия раздела luks.

Всё что ты делаешь в grub – это указываешь параметром ядра где находится зашифрованный раздел, расшифровка и монтирование происходит средствами initramfs. Grub умеет расшифровывать luks на прямую, но только luks1.

Не совсем. Часть grub может располагаться в зашифрованном разделе boot. Незашифрованным остаётся EFI файл с внедренным в него модулями шифрования и luks. При загрузке grub расшифровывает свою вторую часть, а именно normal.mod и прочие модули, которые располагаются на зашифрованном boot. Такая схема теоретически усложняет атаку - можно подменить только сам EFI файл (а не произвольный модуль), что можно выявить контрольной суммой. Писать, что это чересчур - не нужно, тут понятно, что такие атаки - только теоретические.

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

Если /boot просто зашифрован (даже с помощью LUKS), то это не помешает злоумышленнику подменить его своей (зашифрованной другим ключом или вовсе незашифрованной) версией.

Если речь про зашифрованный boot раздел (часть grub, которая в нём располагается), то подменить его конечно же нельзя. Если речь идёт о незашифрованном загрузчке (EFI файле grub), то его тупо заменить можно, но это выявляется проверкой контрольной суммы.

это выявляется проверкой контрольной суммы

Но код, который выполняет проверку, загружается тоже из grub.

Самый простой вариант для злоумышленника - grub при загрузке initrd патчит его в памяти (на несколько сотен байт), а потом записывает на диск прежнюю версию себя. Любая проверка целостности grub в юзерспейсе подтвердит, что контрольные суммы в порядке (ведь так и есть на самом деле), но вражеский код уже будет в системе. Им может быть лишний процесс, ждущий, пока поднимется сеть и пересылающий на удалённый сервер ключевую фразу, которая была передана grub в самом начале процесса загрузки.

Да, проверка контрольной суммой не даёт 100% гарантии, об этом говорится в документации груба и в вики. Скажем так, это способ по максимальной защите загрузки средствами grub. Для защиты core img надо использовать secure boot.

Но если core img защищён secure boot, то зачем шифровать /boot? Куда проще строить цепочку доверия от него, например вставив туда модуль check_signatures.

В общем я понял, рабочего решения пока нет, ждем пока напилят в грабе.

Суть в том, что ноут используется для удаленного доступа по работе, и просто обезопасится, что в случае утери оного ssh-ключи и всякие там впн доступы не стали известны.

Про secure boot я в курсе, что нужно подписать загрузчик в efi, чтобы все усложнить. В биосе очень много опций по поводе security, (ноут Dell Vostro 5481) - производитель очень любит огороженные решения, поэтому я не удивлюсь, что эти товарищи учли возможность извлечения батарейки, сброс биоса, и т.д. В самом биосе также есть опции «в случае кражи».

Суть в том, что ноут используется для удаленного доступа по работе, и просто обезопасится, что в случае утери оного ssh-ключи и всякие там впн доступы не стали известны.

Для конкретно этого шифрование /boot не нужно, достаточно после утери-находки ноута его вайпать.

Но да, жизнь была бы лучше если бы FDE было нормой и тупо работало.

после утери-находки ноута его вайпать.

может быть в далеком (или не очень) завезут такую фичу, что ноут разблокируется средствами биоса - паролем/ключом/сканером отпечатка. Если нет - кирпич/полный сброс.

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

хм, не знал - не пользовался особо ноутами.

Но да, жизнь была бы лучше если бы FDE было нормой и тупо работало.

Почему? Чтобы сказать самому себе «у меня вот вообще весь диск зашифрован»?

Если пользователь не делает что-то очень странное, то ни в прошивке, ни в grub, ни в содержимом /boot нет секретов. Шифрование защищает от извлечения секретов. Измерения защищают от изменений.

Для шифрования есть LUKS. Для измерений есть TPM и Secure Boot.

Мне сложно представить себе злоумышленника, умеющего модифицировать /boot для того, чтобы украсть ключ шифрования, но которой увидев «настоящий» FDE испугается и не перепишет незашифрованную часть загрузчика своим кодом.

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

Шифрование защищает от извлечения секретов. Измерения защищают от изменений.

Мудро, но я хочу иметь секретом все кроме загрузчика, для простоты. Почему мои ядро и initramfs должны торчать наружу? Почему вообще нормально, что видно, что у меня там линукс? Это провал.

А чем загрузчик и прошивка хуже? Почему когда торчат наружу прошивка и загрузчик - это ок, а ядро и initramfs - уже нет?

А чем загрузчик и прошивка хуже? Почему когда торчат наружу прошивка и загрузчик - это ок

Нипочему, это тоже не идеально.

Загрузчик + /boot > загрузчик. Зачем делать публичной, например, дату моего последнего nixos-rebuild switch, если можно не делать? Может тогда и диск не шифровать? База паролей все равно gpg зашифрована.

Почему когда торчат наружу прошивка и загрузчик - это ок, а ядро и initramfs - уже нет?

В initramfs и ядро можно много чего запихнуть (пересобрать/перепаковать)

В initramfs и ядро можно много чего запихнуть

А в загрузчик - ещё больше, ведь можно попросить его запихнуть в initramfs и ядро всё, что угодно.

Зачем делать публичной, например, дату моего последнего nixos-rebuild switch, если можно не делать?

А вот с этим уже не могу не согласиться. Да, действительно, есть сценарии, когда имеет смысл скрыть содержимое grub.cfg.

Правда, я бы при такой необходимости вовсе перестал использовать grub, а держал бы в открытой части диска небольшой linux, загружающий через kexec рабочую систему. Код ядра, lvm и cryptsetup сильно более качественный, чем код grub - его поддерживает больше людей, и он обладает куда более привычной и качественной инфраструктурой. А ещё с kexec отпадает необходимость держать две реализации одних и тех же механизмов, что не даёт описанной в теме проблеме возникнуть - luks2 уж наверняка будет совместим сам с собой.

check_signatures позволит выявить подмену модулей с остановкой процесса загрузки. Перенос модулей на зашифрованный /boot позволит вообще предотвратить подмену модулей, так как они находятся на зашифрованной части диска. В данном случае вместо проверки контрольной суммой есть решение лучше - перенос на зашифрованный раздел. В случае EFI файла (о чём было написано в комментариях выше) такого способа нет, поэтому приходится довольствоваться контрольной суммой.

Почему? Чтобы сказать самому себе «у меня вот вообще весь диск зашифрован»?

Что плохого в полном (без учёта EFI раздела) шифровании всего диска?

Если пользователь не делает что-то очень странное, то ни в прошивке, ни в grub, ни в содержимом /boot нет секретов. Шифрование защищает от извлечения секретов. Измерения защищают от изменений.

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

Мне сложно представить себе злоумышленника, умеющего модифицировать /boot для того, чтобы украсть ключ шифрования, но которой увидев «настоящий» FDE испугается и не перепишет незашифрованную часть загрузчика своим кодом.

Частично согласен. Вероятность обеих сценариев очень мала - даже в практике спецслужб, которые охотятся на политических активистов, не было публичных случаев, когда модифицировался загрузчик. Тем не менее, если рассматривать ситуацию теоретически, гораздо сложнее модифицировать код EFI файла, чем отдельного модуля grub. Поэтому с этой точки зрения перенос максимально возможной инфы (частей grub) на зашифрованный раздел - более лучшее решение.

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

Практической пользы в этом действительно нет. Бесмысленно выносить незашифрованный загрузчик на отдельную флэшку для обеспечения 100% шифрования основного диска.

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

Не поможет, злоумышленник может перенести их на незашифрованную часть диска или зашифровать их по-своему и учесть это в коде расшифровки.

Что плохого в полном (без учёта EFI раздела) шифровании всего диска?

Субъективно это создаёт ложное ощущение безопасности - система с зашифрованным несекретным разделом не становится более защищённой, чем без его шифрования. В системе становится больше кусков, от которых зависит безопасность, реализующих одно и то же по-разному, а значит выше шанс ошибиться и неправильно что-то настроить. Проще довериться уже хорошо изученному шифрованию корня, а /boot и ESP оставить открытыми - хуже от этого не будет.

Выше был комментарий про nixos - тут я пока затрудняюсь определиться, стоит ли считать записи о поколениях системы в grub.cfg секретными. Более простого способа выбрать init для таких систем, чем тот, что есть сейчас (выбор generation из grub), я быстро придумать не могу.

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

гораздо сложнее модифицировать код EFI файла, чем отдельного модуля grub

Это не так. Инструментов по внедрению кода в PE-файлы и различных статей на эту тему написано гораздо больше, чем про grub-модули. Под Windows с тем же форматом исполняемых файлов куча людей написали кучу вирусов.

А если злоумышленник изучил работу grub (и даже не особо разбирается в EFI), то он уже знает, что ему надо внедряться в секцию mods у grubx64.efi - в ней и лежат встроенные модули grub, ровно в том же формате, что и в /boot/grub/x86_64-efi/*.mod, просто с дополнительным заголовком (mimg). Или он может просто запустить grub-mkimage и сгенерировать новый образ со своим модулем и конфигом.

не столько защищают от изменений, сколько выявляют подмену

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

Не поможет, злоумышленник может перенести их на незашифрованную часть диска или зашифровать их по-своему и учесть это в коде расшифровки.

Такой возможности у злоумышленника без доступа к зашифрованному разделу нет. Он может получить доступ только если внедрится во время работающей системы или если знает пароль. Но в таких условиях внедряться в загрузчик не нужно - доступ уже есть.

Субъективно это создаёт ложное ощущение безопасности - система с зашифрованным несекретным разделом не становится более защищённой, чем без его шифрования.

Ну это явно не так. FDE лучше чем отсутствие шифрования или шифрование только /home раздела или отдельных кусков информации. FDE позволяет обезопасить от 100% практических попыток получить доступ к информации и защиту от 99% теоретических способов взломать защиту (где 1% - это обсуждаемая модификация незащищённой части загрузчика). Баланс выгод и недостатков FDE очевиден: с одной стороны защита всего диска (системы и данных пользователя), с другой стороны - теоретическая возможность модификации части загрузчика, публичных случаев чего нет. Если государству потребуется пароль от политического активиста, то оно прибегнет к паяльнику, а не станет модифицировать загрузчик. Вообще модификация загрузчика - это чистая теория, для практических целей защиты FDE более чем хватает.

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

Перенос части grub не создаёт каких-то новых кусков и не увеличивает шансы ошибиться в настройке. Такая установка предусмотрена штатными средствами grub, для этого есть документация и вики.

Проще довериться уже хорошо изученному шифрованию корня, а /boot и ESP оставить открытыми - хуже от этого не будет.

Расположение части grub в зашированном корне тоже «хорошо изучено». То, что /boot можно оставить незашифрованным - ну можно, тут не принципиально. Правда, какой-нибудь идиот из центра Э может случайно затереть /boot раздел с grub - в таком случае проще восстановить один EFI файл, чем весь раздел.

Это не так. Инструментов по внедрению кода в PE-файлы и различных статей на эту тему написано гораздо больше, чем про grub-модули. Под Windows с тем же форматом исполняемых файлов куча людей написали кучу вирусов.

Ага, есть куча вирусов по модификации PE файлов. Только вот проблема - программировать их сложнее, так как в буте всяких win32api нет) Впрочем, вопрос сложности модификации PE файла или модуля grub непринципиален - это вопрос чисто теоретический.

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

Речь шла о механизмах проверки незащищённой части загрузчика. В случае grub это можно сделать через Secure boot, либо написав скрипт, который сверяет контрольную сумму незащищённой части загрузчика с заранее заданным значением. Но такой скрипт (есть пример в арчевики) можно запустить только после выполнения незащищённой части загрузчика, когда потенциальный вредоносный код уже запущен. Если рассматривать такую теоретическую ситуацию, то скрипт покажет, что контрольная сумма не совпадает, но будет уже поздно. Не один из этих способов не защищает от того, что диск монтируется и EFI файл подменяется. Поэтому я написал, что такие методы («измерения») позволяют только выявить уже совершённую подмену, а не «защитить от изменений». А защититься от подмены модулей grub можно - переместив их не зашифрованный /boot, что я пытаюсь донести.

Я всё ещё не понимаю, как именно работает защита.

Такой возможности у злоумышленника без доступа к зашифрованному разделу нет.

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

На том же диске где-то будет лежать код расшифровщика в незашифрованном виде.

Вообще модификация загрузчика - это чистая теория

Под Windows существуют буткиты. Некоторые из них даже используются владельцами систем - обход забытого пароля администратора (kon-boot), удалённой блокировки украденных машин (computrace), решения проблем с активацией ОС (slic injectors).

А уж сколько загрузочных вирусов под DOS было.

Задачи на модификацию загрузчиков иногда встречаются в CTF.

Баланс выгод и недостатков FDE очевиден: с одной стороны защита всего диска (системы и данных пользователя)

защититься от подмены модулей grub можно - переместив их не зашифрованный /boot, что я пытаюсь донести

Предположим, что есть компьютер, где /boot зашифрован, а grubx64.efi - нет. Что помешает злоумышленнику, который вытащил диск из компьютера (и может произвольно его читать/писать), записать на диск любой загрузчик по его выбору с теми модулями, которые ему нравятся? А когда законный владелец компьютера включит его и введёт парольную фразу, расшифровывающую диск, вернуть всё обратно.

https://en.wikipedia.org/wiki/Evil_maid_attack#Full_disk_encryption_systems

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

Стоп. А вы представляете себе как работает шифрование? Возможности запихнуть вирус или вообще любой файл на зашифрованный диск без знания пароля нет.

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

На том же диске где-то будет лежать код расшифровщика в незашифрованном виде.

Да, в обсуждаемом случае код расшифровщика находится в EFI файле grub на EFI разделе (если основная часть grub вынесена на зашифрованный раздел), или находится в нескольких модулях grub на незашифрованном разделе. Только, как я написал выше, это не поможет - подменить файлы на зашифрованном разделе без знания ключа невозможно, данные можно только «испортить». Это ответ на изначальный комментарий: «Не поможет, злоумышленник может перенести их на незашифрованную часть диска или зашифровать их по-своему и учесть это в коде расшифровки.») - т.е. якобы атакующий может без знания пароля каким-то образом перемещать файлы по диску.

Под Windows существуют буткиты. Некоторые из них даже используются владельцами систем - обход забытого пароля администратора (kon-boot), удалённой блокировки украденных машин (computrace), решения проблем с активацией ОС (slic injectors).

А уж сколько загрузочных вирусов под DOS было.

Задачи на модификацию загрузчиков иногда встречаются в CTF.

Написать windows буткит, который меняет файлы на незашифрованном разделе и внедрить в загрузчик код, который перехватывает ключ и отправляет его куда-то - это разные по сложности задачи. Я сформулирую свою позицию насчёт теоретических угроз так - на данный момент нет известных публичных случаев, когда спецслужба государства (США/Китай/Россия/Белоруссия) или какая-то организация взломали компьютер противника, внедрив код в загрузчик (как в случае полностью незашифрованного загрузчика, так и с помощью частично зашифрованного). Зато если случаи пыток и краж ноутбуков при перелётах. Поэтому с точки зрения практики FDE позволяет отсечь широкий спектр попыток получить доступ к диску, за исключением применения силового способа, от которого нет приёма. А если рассматривать силовой способ, то вообще значения не имеет защита загрузчика.

Предположим, что есть компьютер, где /boot зашифрован, а grubx64.efi - нет. Что помешает злоумышленнику, который вытащил диск из компьютера (и может произвольно его читать/писать), записать на диск любой загрузчик по его выбору с теми модулями, которые ему нравятся? А когда законный владелец компьютера включит его и введёт парольную фразу, расшифровывающую диск, вернуть всё обратно.

В теории - нет. Также как ничто не помешает изменить полностью незашифрованный загрузчик, что упрощает задачу. Однако, этот способ требует серьёзных затрат и усилий - надо написать grubx64.efi так, чтобы не испорить его, надо сохранить где-то пароль, надо внедрить в загрузчик бинарь, который читает сохранённый пароль и отправляет его не сервер. Причём нужно поставить не любой загрузчик с любыми модулями, а именно grub, так как подмена grub на systemd-boot (например) очевидно. В теории если предполагать, что в распоряжении атакующего есть много ресурсов, это реализуемо.

На практике - да, защитит. FDE отсеет мимопроходящих (желающих посмотреть), а у каких-то кулхацкеров им. Kali Linux отпадёт охота ковыряться в grub. Если против вас государство, то оно не будет модифицировать EFI файл, оно вас будет пытать, а в обвинительном заключении напишет, 2+2=17, а кто не согласен - иностранный агент.

Много написано, но как я понял народ не совсем понял цель сего занятия.

Если вы хотите хранить что-то очень ценное, например данные, составляющие коммерческую тайну - используйте несистемные носители с жесткими алгоритмами шифрования вроде truecrypt, и переносные устройства - не самый лучший вариант.

В моем случае - это защитить ~/ (ssh-ключи, автозаполненные формы в браузере) и несколько файлов в /etc, где у меня настроен ipsec+l2tp. Доступы можно поменять, поэтому пока теоретический кулхацкер вася будет заниматься переписыванием загрузчика и поиском эксплойта, доступы будут сменены.

Есть SecureBoot со своими ключами в TPM.

Не всегда легко контролировать распространение секретов по системе.

Что-то может утечь в /var/log, что-то в .bash_history рута, например sudo curl -u admin:secret https://.... Есть /var/lib/docker, где в каждом контейнере может происходить то же самое. Там же могут оказаться исходники какого-нибудь рабочего сервиса.

Поэтому идея зашифровать не только /home, но и весь корень вполне здравая.

Только, как я написал выше, это не поможет - подменить файлы на зашифрованном разделе без знания ключа невозможно, данные можно только «испортить».

А это и не нужно. У тебя есть целый plaintext-раздел, куда можно запихнуть что угодно. Ты даже не догадаешься, что вводишь пароль в левый загрузчик.

т.е. якобы атакующий может без знания пароля каким-то образом перемещать файлы по диску

Слишком буквальное понимание «переместить».

так собственно для этого и используется FDE (:

Он вообще к шифрованию не причастен

Да, да, не причастен. А кто тебе раздел, на котором лежит ядро, расшифрует?

Не делай так.

Такую подмену ты заметишь, да и бессмысленно это. Вектор атаки тут другой. Нужно подменить загрузчик на тот, который залогирует пароль.

Тут по идее secure boot спасать должен, но и биос можно можно прошить при физическом доступе. Так что достаточной мерой безопасности будет просто запрет грузиться с флешек, а при утере и получении устройства назад, считать его заведомо скомпрометированным и как минимум накатить EFI-раздел из бекапа, а лучше просто всё затереть и зашифровать по-новой, если есть уверенность, что биос остался нетронутым.

А это и не нужно. У тебя есть целый plaintext-раздел, куда можно запихнуть что угодно. Ты даже не догадаешься, что вводишь пароль в левый загрузчик.

Вы не поняли предмет обсуждения. Всё началось с этого:

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

kmeaw возвразил, что

Не поможет, злоумышленник может перенести их на незашифрованную часть диска или зашифровать их по-своему и учесть это в коде расшифровки.

потому что якобы:

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

На том же диске где-то будет лежать код расшифровщика в незашифрованном виде.

Что очевидно не так: у злоумышленника нет возможности без знания пароля переместить модули груба с зашифрованного раздела на EFI раздел. Да и вообще, это злоумышленнику не нужно. Про то, можно поменять EFI файл и перехватить пароль я много раз говорил, но для обсуждаемого вопроса (перенос модулей grub на зашифрованный диск сокращает возможности по атаке) это значения не имеет.

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

Ему не нужно ничего физически перемещать, ты слишком узко интерпретируешь это слово. Эти модули не уникальны, не проблема их раздобыть.

перенос модулей grub на зашифрованный диск сокращает возможности по атаке

Не очень, особенно без Secure Boot.

Ему не нужно ничего физически перемещать, ты слишком узко интерпретируешь это слово. Эти модули не уникальны, не проблема их раздобыть.

Ну и как можно подменить располагающиеся на зашифрованном /boot разделе модули (без модификации EFI файла)?

Не очень, особенно без Secure Boot.

То, что остаётся проблема с EFI файлом, не означает, что сокращение других возможностей по защите бесмысленно. По такой логике можно сказать, что вообще всё FDE бессмысленно, так как остаётся проблема EFI загрузчика. Да, его надо как-то защитить, но тем не менее возможностей по атаке меньше. Кстати, ещё один плюс защиты части grub - упрощение восстановления. Открытый /boot раздел с грабом любой кулхацкер может удалить, тогда надо переустановить груб. Если торчит наружу один EFI загрузчик - достаточно просто сохранить один файл.

Ну и как можно подменить располагающиеся на зашифрованном /boot разделе модули (без модификации EFI файла)?

Откуда условие про модификацию? Именно так и подменяется что угодно.

Открытый /boot раздел с грабом любой кулхацкер может удалить, тогда надо переустановить груб. Если торчит наружу один EFI загрузчик - достаточно просто сохранить один файл.

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

Да, его надо как-то защитить

Secure Boot защитит и загрузчик, и все загружаемые им файлы, которые, таким образом, можно и не прятать. Хочешь - прячь, ничего плохого, но безопасность это не особо повышает.

Откуда условие про модификацию? Именно так и подменяется что угодно.

То есть в вашей схеме подменить модули grub на зашифрованном разделе без модификации ELF загрузчика нельзя? Ну тогда это ч.т.д. Речь собственно об этом и шла - перенос части загрузчика на шифрованный раздел (что возможно только с grub, другие загрузчики это не поддерживают) улучшает безопасность. Остаётся проблема модификации EFI файла, но это более общая проблема и не отменяет полезности шифрования части загрузчика.

Никто такой ерундой не занимается с девяностых

Что подтверждает то, что шифровать grub по максимуму имеет смысл.

Secure Boot защитит и загрузчик, и все загружаемые им файлы, которые, таким образом, можно и не прятать. Хочешь - прячь, ничего плохого, но безопасность это не особо повышает.

Это никто не отрицает.

биос можно можно прошить при физическом доступе.

Нельзя:

UEFI, вопрос по аудиту (комментарий)

coreboot всё?

Так что достаточной мерой безопасности будет просто запрет грузиться с флешек

Глупость в случае с ворованым ноутом.

Правильное решение для ноута: полное шифрование диска, с выносом загливия в шифрованный /boot на загрузочной флешке. Загрузочную флешку с заглавием шиырованого диска бекапить!

Шифровать /boot необходимо для безопасности даже при использовании Integrity. А чё, никто не в курсе? Новая уязвимость линукса: BootHole (комментарий)

Secure Boot защитит и загрузчик, и все загружаемые им файлы, которые, таким образом, можно и не прятать. Хочешь - прячь, ничего плохого, но безопасность это не особо повышает.

Это никто не отрицает.

Я отрицаю.

Шифрование /boot повысит безопасность даже при использовании Integrity!

Шифровать /boot необходимо даже если включен Secure Boot, Check Signatures, …