LINUX.ORG.RU

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

 , , ,


1

2

Здравствуйте.
Вопрос банальный, понимаю что решается с полпинка, но найти этот «полпинок» второй день не могу.

На ноуте Debian stretch amd64.
Установлен на полностью зашитый DM-crypt'ом /dev/sda с LVM поверх.
/boot вынесен на третий раздел флешки (/sdb3).
Keyfile от /sda зашит в initrd. Все замечательно работает, /sda при загрузке расшифровывается, подключается и стартует система.

Хочу перенести /boot (или как минимум ядро и initrd, в нем же ключ) на зашифрованный /sdb2 (grub2 же умеет luks сам вроде как).

Что сделал:
cryptsetup'ом format/open /sdb2 как /dev/mapper/crypto
Примонтировал /dev/mapper/crypto и скопировал на него полностью содержимое /boot (может и не надо было все, но на всякий случай сделал полностью: с ядром, initrd'ой, директорией grub)
В /etc/default/grub выставил GRUB_ENABLE_CRYPTODISK=y
В /etc/fstab в качестве /boot указал /dev/mapper/crypto
В /etc/crypttab описал crypto на устройстве по uuid
Сделал update-grub.

В результате /grub/grub.cfg, который лежит на шифрованном /sdb2, обновился, в нем добавились insmod'ы cryptodisk, luks, какого-то gcry_sha256, появилась строка cryptomount со ссылкой на /sdb2 по uuid'у, а также set root='cryptouuid/тут_uuid_sdb2'
Вместе с тем, при перезагрузке grub стартует initrd по-прежнему с /sdb3, а уже потом, после того как подключается /sda запрашивается пароль от /sdb2 и он монтируется в /boot (т.е. я так понимаю когда /erc/crypttab отрабатывает).
Убирание с /sdb3 всего содержимого результата не дало, грузиться отказался.
Повторный update-grub на уже загрузившейся по вышеописанной схеме системе тоже ничего не дал.

Как сделать, чтобы загрузчик при старте системы запрашивал пароль от /sdb2, открывал его, и уже из открытого раздела брал initrd? Т.е. полностью избавиться от /sdb3 (задача максимум) или хотя-бы убрать ядро с initrd в шифрованный раздел флешки (задача минимум).

P.S. Яндексил по сабжу много. Везде, где нашел, тема открытия загрузчиком grub'a шифрованного /boot либо подразумевается как само собой разумеещееся и не раскрывается в деталях, либо описывается в другом, не подходящем в рассматриваемом случае, контексте.

Положить /boot в свой LVM на sda.

anonymous ()
Ответ на: комментарий от anonymous

Не очень понял. /sda открывается не паролем а ключем. В /boot'e initrd, в который зашит этот самый ключ от /sda. Как же он загрузится?

Neuro75 ()
Ответ на: комментарий от Neuro75

Мне видится схема: загрузчик grub'a по паролю открывает /sdb2, дальше продолжает грузится с лежащих в /sdb2 ядра и initrd, с помощью которых открывает и монтирует /sda по зашитому ключу, а сам монтируется в /boot. Поправьте если я ошибаюсь и что-то не так понял.

Neuro75 ()
Ответ на: комментарий от Neuro75

Задача решилась по наитию и просто:
скопировал папку grub c /grub/grub.cfg, который update-grub ранее сгенерил на /sdb2 и который содержал вышеперечисленные плюшки с cryptodisk'ами, c /sdb2 на /sdb3, после чего с /sdb3 можно убирать все, кроме папки /grub.
Теперь все работает именно так, как и хотел: сразу при запуске появляется запрос пароля на /sdb2, после его монтирования вылазит меню груба, ну и дальше понеслось. 4 вопроса:
1. /sdb2 после ввода пароля открывается очень медленно, более минуты. При его размере 250 Мб, так и должно быть?
2. Запрос пароля к /sdb2 происходит 2 раза: сразу при включении и уже после монтирования initrd, в процессе загрузки (второй раз открывается уже быстро, см. п.1). Видел обсуждения этого вопроса, но прочитал их вскользь пока решал сабж. По-моему обсуждалка этого вопроса тут на форуме переросла в холивар и закончилась ничем. Полез яндексить, но если кто подскажет тут, буду крайне благодарен.
3. «Боевой» grub, с которого все и грузится, лежит на /sdb3, однако в качестве /boot в систему монтируется /sdb2. Получается, что update-grub и будет в дальнейшем править /grub/grub.gfg именно с /sdb2 . Как сделать так, чтобы он правил сразу правильный grub, а не копировать после каждой правки исправленный файл с /sdb2?
4. Есть ли все-же варианты засунуть и /grub в зашифрованный раздел?

Neuro75 ()
Ответ на: комментарий от Neuro75

1) В GRUB нет поддержки быстрой криптографии, у меня так же медленно для aes-xts-plain64 с хэшем sha512.

2) Читай в документации cryptsetup (/usr/share/doc/cryptsetup/README.initramfs или типа того) про правильное хранение ключей в initramfs. У меня пароль спрашивается один раз, а initramfs использует уже ключ.

4) ХЗ, у меня не зашифрован только EFI-бинарник GRUB, который лежит в ESP. Каталог с конфигурационной лапшой лежит в /boot, который в /, который в dm-crypt.

anonymous ()
Ответ на: комментарий от Neuro75

2. Решено добавлением еще одного кейслота с кейфайлом и прописыванием в crypttab открытие ключем. Теперь пароль запрашивает один раз - при запуске. В самой системе открывает кейфайлом.
3. Решено символьной ссылкой в /boot на каталог grub в /sdb3 (/sdb3 предварительно примонтирована во fstab'e в произвольную директорию).
4. Я не использую EFI, у меня на MBR все. Выходит нет вариантов :(
По поводу 1: я тоже использую -xts-plain64 на самом винте, т.к. benchmark cryptsetup'a на моей машине показывает его четырехкратное превышение скорости над cbc-essiv. Но по паре фраз на которые наткнулся пока искал инфу, возможно именно применительно к ситуации с открытием grub'ом раздела на флешке essiv будет быстрее. Попозже попробую, пусть вновь установленная система хотя бы несколько дней поживет :-) Пока 30 секунд на открытие раздела на флешке и 1 мин. 30 сек. вся загрузка в целом. Нервирует, но жить можно.

Neuro75 ()
Ответ на: комментарий от Neuro75

Где-то ты перемудрил.

NAME     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda        8:0    0 111.8G  0 disk  
├─sda1     8:1    0     8M  0 part  /boot/efi
├─sda2     8:3    0   108G  0 part  
│ └─root 254:0    0   108G  0 crypt /
└─sda3     8:4    0   3.5G  0 part  
  └─swap 254:1    0   3.5G  0 crypt [SWAP]
По идее, с MBR будет то же самое, только без sda1.

Использовать CBC-ESSIV ради экономии нескольких секунд я бы не стал.

anonymous ()
Ответ на: комментарий от Neuro75

Попробуй grub-install ещё раз сделать

anonymous ()

Я как-то пытался сделать шифрованный /boot: включал GRUB_ENABLE_CRYPTODISK и т. п. Действительно появились cryptomount, gcry_sha256, модули luks и cryptomount, однако груб не грузился (при выполнении cryptomount вылезала ошибка - неправильный LUKs заголовок или что-то подобное).

После поиска в гугле нашёл инфу, что в грубе реализована поддержка LUKs, и то частичная (как оно там с LUKs - не знаю, меня интересовал plain dm-crypt). На одном форуме объяснили, что необходимые для загрузки plain dm-crypt патчи есть, они отправлены в ветку груба, но не одобрены. Предлагали сходить и проголосовать за патчи:) В итоге оказалось, что под «груб поддерживает загрузку с шифрованных разделов» понималось скачивание каких-то (не факт, что работающих) патчей и компиляция груба. Мне для моих целей (перенести vmlinux и initrd с нешифрованного EFI раздела в шифрованный) это было влом.

mxfm ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.