Full disk transparent encryption

Возможно ли зашифровать диск полностью, включая /boot раздел и нужно ли?

Да.

зашифровать диск полностью, включая /boot

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

Пока что конфигурация c шифрованием всего предполагает доверие к аппаратной части ПК.
Сомнительно, что это лучше незашифрованного загрузочного раздела.

Смысл иметь зашифрованный boot есть разве что когда загрузчик защищён UEFI Secure Boot.
Но тут требуется снова верить железке.

Возможно ли зашифровать диск полностью

Да

поделитесь минусами незашифрованного boot

Младший брат может подменить содержимое /boot

Младший брат может подменить содержимое /boot

Что помешает младшему брату подменить зашифрованный /boot целиком? Тут надо верификацию бута по цифровой подписи делать. А чтобы делать нужно опять же, доверие к железке, которая реализует функцию проверки подписи перед исполнением.

В случае с нешифрованым бутом можно подменить тот же initrd. При шифрованом буте править придется stage1,2 grub'а. Братишке придется повышать свой уровень. Но в конечном итоге да, есть возможность подмены кода. Вопрос только в сложности замены.

Младший брат может подменить

Очередной параноик решил ЛОР'авцам лапшу на уши навестить.

В конфиге grub'а параметры

GRUB_ENABLE_CRYPTODISK=y

и

GRUB_CMDLINE_LINUX=«cryptdevice=UUID=*твой UUID*:container»

указаны?

первый параметр да, во втором ядру немного другое передавал, там там был адрес блочного устройства вместо UUID

При шифрованом буте править придется stage1,2 grub'а

Достаточно подменить весь GRUB в ESP. Но Secure Boot не даст :)

ага, но ТС, похоже, MBR пользует. С одним-то физическим разделом.

Grub не умеет luks2, только luks1.

Полное ATA шифрование встроено в большинство дисков, никакой LUKS не нужен. На дешманских SSD есть OPAL.

Никто не запрещает использовать luks1 для /boot, а luks2 — для остального. Не аккуратненько, но.

Полное ATA шифрование встроено в большинство дисков, никакой LUKS не нужен.

Встал и вышел из моего /security/.

initrd можно встроить в ядро (CONFIG_INITRAMFS_SOURCE). Алсо, груб не нужен, параметры загрузки тоже можно указать в конфиге ядра, и получается один efi-файл, который например можно загружать с флешки, а винты зашифровать в ноль, включая таблицу разделов (а заголовки LUKS спрятать в initramfs)

Да, уже почти год как поддержка LUKS2 в GRUB2 всё ещё отсутствует. Поэтому в Debian завели баг и написали статью, как провести соответствующую установку с LUKS1/boot и LUKS2/root.

Использую такую схему уже много лет.

И я к тому, что у ТС grub не видит раздел именно поэтому. Он не говорит никому ничего про версии luks, он просто его не видит от слова «совсем».

В арче в ауре есть grub-luks-keyfile, патченый grub, который умеет грузиться с чистого dmcrypt-a или люкса. Только luks нахер не нужен, так же как и lvm. Накатываешь на флешку такой вот grub при установке арча. На ней будет загрузчик + файл ключа. Винт чистый dmcrypt+файловая система на нём. Элегантно и просто. Если к тебе приходят, флешку либо сжираешь, либо смываешь в унитаз.

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

Причины шифровать swap, home и root для меня очевидны, поделитесь минусами незашифрованного boot.

Сложнее сделать, остаётся незашифрованный /boot. Шифруй все.

GRUB 2.04 официально, а GRUB 2.02 с патчами, которые есть в Ubuntu и Fedora как минимум, поддерживает доверенную загрузку с использованием TPM. Если у вас есть TPM, вы можете настроить в GRUB его использование и пароль на загрузку.

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

Но Secure Boot не даст :)

Если не отзывать ключи Microsoft — даст. Secure Boot призван защитить от незаметной подмены загрузчика удалённо, когда у атакующего нет физического доступа.

https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk

А где вообще можно взять TPM? На десктопных платах обычно только гребёнка для подключения.

Его «эмуляция» (Firmware TPM, может называться PTT) встроена почти во все современные процессоры Intel среднего и высокого класса, у AMD, если не ошибаюсь, тоже что-то такое есть.

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

А вот это интересно, спасибо за информацию. А точно в процессорах (десктопных)? На ark.intel.com нет ничего в характеристиках. Только про NUC.

Оказалось, что не в процессорах, а в чипсетах.

Да, похоже, в чипсетах, где ME выполняется.

Если у вас есть TPM, вы можете настроить в GRUB его использование и пароль на загрузку

Доверия этим штукам - никакого, равно как и «встроенному» в SSD шифрованию.

При шифрованом буте править придется stage1,2 grub'а.

Libreboot с GRUB payload, прошитым в чип? Вроде бы там есть возможность сверки GPG подписи того, что грузится дальше?

Тебе технологиями Libreboot/secureboot/tboot надо защитить только GRUB core.img который содержит крыптографию для расшифровки /boot, публичный GPG ключ и крыптографию для верификации всего остального с /boot включено с ядром и инитрд.

Вроде бы там есть возможность сверки GPG подписи того, что грузится дальше?

https://www.gnu.org/software/grub/manual/grub/grub.html#Using-digital-signatures

ТС: если у тебя при загрузке не расшифровывается /boot то проблема в создании и установку GRUB core.img . Какими командами ты его создаешь и устагавливаешь, необходимые модули GRUB для шифрования как параметр указал?

Суть не в конкретных технологиях, а в ответе на вопрос «зачем» и степени паранойи. В любом случае будет механизм, который будет расшифровывать криптоконтейнер. Вопрос в степени доверия к этому механизму и сложности модификации его. Нешифрованый /boot модифицируется с помощью знаний sh и cpio. Шифрованый /boot потребует лезть в stage1,2. Далее фирмварь, аппаратные криптомодули. Доступ к расшифровщику усложняется, но не становится невозможным. Если защищаешься от условного брата-линуксоида, хватит шифрованого бута. Если от Службы Галактической Разведки, то не хватит и всех TPM'ов с Libreboot вместе взятых.

ответе на вопрос «зачем»

/boot должен шифроваться для защиты ядра, инитрд и своих настроек.

Если используете GRUB, то GPG верификация необходима для гарантии целостности системы на участке от MBR и до init.

И можно и нужно. И включить секуре боот. Некоторые системы умеют так ставиться сами (POP_OS!). При этом, биос должен быть опенсурсным (гуглите проект под свою модель) и МЕ должен быть крякнут. Иначе это не имеет смысла.