- без отдельного /boot (просто в /root)
- / на lvm
- lvm внутри luks-контейнера
- с UEFI
- в виртуальной машине.
с secure boot(«сложна», в виртуалке вряд ли получится)
Примечательно, что зашифровано будет всё, кроме EFI system partition с единственным файлом grubx64.efi — EFI-приложением для запуска grub.
Если заинтересовались, — добро пожаловать под кат!
Сначала я настроил это всё на моём ноутбуке Lenovo X240, потом для написания статьи пользовался уже виртуальной машиной с OVMF в Proxmox.
Настройка тестового стенда:
Создаётся всё достаточно стандартно. Образом используется мой любимый арч, который можно всегда загрузить с яндекса.
Далее несколько моментов по виртуалке в Proxmox относительно UEFI. Чтобы протестировать работу стенда с UEFI(иначе не будет так интересно), нужно в свойствах виртуальной машины выставить OVMF вместо SeaBIOS:
Далее соответственно добавить UEFI-диск, чтобы получилось примерно так:
Теперь можем стартовать виртуальную машину и начинать процесс установки. В консоли виртуальной машины сразу стартуем сервис sshd, задаём пароль root и узнаём dhcp-адрес виртуальной машины:
Далее мы можем продолжить работу по ssh чтобы было удобнее.
Разметка дисков
Итак, уже подключившись по ssh мы для начала устанавливаем время, чтобы потом не оказалось, что файловые системы созданы в будущем:
timedatectl set-ntp true && timedatectl set-timezone Europe/MoscowПроверяем, что всё верно:
root@archiso ~ # timedatectl
Local time: Tue 2018-08-14 13:42:03 MSK
Universal time: Tue 2018-08-14 10:42:03 UTC
RTC time: Tue 2018-08-14 10:42:04
Time zone: Europe/Moscow (MSK, +0300)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Теперь можем приступать к разметке диска. На данном этапе у меня есть диск /dev/vda, т.к. контроллер Virtio и это просто пустой диск без таблицы разделов:
root@archiso ~ # fdisk -l /dev/vda
Disk /dev/vda: 15 GiB, 16106127360 bytes, 31457280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Разбивать его будем на 2 партиции:
- fat32 диск для UEFI приложений(EFI_system_partition)
- LUKS контейнер со всем остальным
Используем gdisk для создания GPT:
root@archiso ~ # gdisk /dev/vda
GPT fdisk (gdisk) version 1.0.4
Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y
Далее создаём первую партицию для EFI с типом EF00 (EFI System Partition):
Command (? for help): n
Partition number (1-128, default 1):
First sector (34-31457246, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-31457246, default = 31457246) or {+-}size{KMGTP}: +512M
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): <b>EF00</b>
Changed type of partition to 'EFI System'
Теперь создаём партицию для LUKS, где даже не будем заморачиваться с типом и оставим как есть:
Command (? for help): n
Partition number (2-128, default 2):
First sector (34-31457246, default = 1050624) or {+-}size{KMGTP}:
Last sector (1050624-31457246, default = 31457246) or {+-}size{KMGTP}:
<b>Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'</b>
Запишем изменения и закончим с разметкой партиций:
Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/vda.
The operation has completed successfully.
Создание LUKS-контейнера и файловых систем
C первым разделом(vda1) всё достаточно просто. Нам нужно его просто отформатировать и пока на этом всё:
root@archiso ~ # mkfs.vfat /dev/vda1
mkfs.fat 4.1 (2017-01-24)
Вторая партиция это контейнер, который нужно сначала подготовить. Форматируем партицию через cryptsetup и задаём парольную фразу:
root@archiso ~ # cryptsetup -v luksFormat /dev/vda2
WARNING!
========
This will overwrite data on /dev/vda2 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/vda2:
Verify passphrase:
Command successful.
*** я не стал заморачиваться с выбором шифров, с затиранием рандомом урандомом и прочим, а просто создал контейнер по умолчанию.
Далее открываем контейнер указывая ту же парольную фразу:
root@archiso ~ # cryptsetup luksOpen /dev/vda2 container
Enter passphrase for /dev/vda2:
Теперь у нас есть открытый контейнер, доступной через device mapper:
root@archiso ~ # ls -l /dev/mapper | grep container
lrwxrwxrwx 1 root root 7 Aug 14 14:01 container -> ../dm-0Теперь мы можем продолжить с lvm(напишу по-быстрому, так как это не сабж):
root@archiso ~ # pvcreate /dev/mapper/container
Physical volume "/dev/mapper/container" successfully created.
root@archiso ~ # vgcreate rootvg /dev/mapper/container
Volume group "rootvg" successfully created
root@archiso ~ # lvcreate -L1G -n swap rootvg
Logical volume "swap" created.
root@archiso ~ # lvcreate -L5G -n root rootvg
Logical volume "root" created.
root@archiso ~ # lvcreate -L2G -n home rootvg
Logical volume "home" created.
root@archiso ~ # lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home rootvg -wi-a----- 2.00g
root rootvg -wi-a----- 5.00g
swap rootvg -wi-a----- 1.00g
Далее создадим файловые системы на наших lv:
root@archiso ~ # mkfs.ext4 -L root /dev/mapper/rootvg-root
mke2fs 1.44.3 (10-July-2018)
...
Writing superblocks and filesystem accounting information: done
[root@archiso ~]# mkfs.ext4 -L home /dev/mapper/rootvg-home
mke2fs 1.44.3 (10-July-2018)
Creating filesystem with 524288 4k blocks and 131072 inodes
...
Writing superblocks and filesystem accounting information: done
[root@archiso ~]# mkswap -L swap /dev/mapper/rootvg-swap
...
LABEL=swap, UUID=98b0bc31-1c62-4fec-bb97-e1913d1e8cb4
Теперь это всё можно примонтировать для установки базовой системы. Точкой установки будет /mnt, где будет начинаться корень нашей будущей системы:
[root@archiso ~]# mount /dev/mapper/rootvg-root /mnt/
[root@archiso ~]# mkdir -p /mnt/{home,boot/efi}
*** /boot/efi я создаю, чтобы сам /boot остался на /dev/mapper/rootvg-root, а папка efi уже для монтирования в неё /dev/vda1(fat32 efi partition):
[root@archiso ~]# mount /dev/vda1 /mnt/boot/efi/
[root@archiso ~]# mount /dev/mapper/rootvg-home /mnt/home/
[root@archiso ~]# swapon /dev/mapper/rootvg-swap
Проверим текуoие точки монтирования(всегда полезно):
[root@archiso ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 462.5M 1 loop /run/archiso/sfs/airootfs
sr0 11:0 1 573M 0 rom /run/archiso/bootmnt
vda 254:0 0 15G 0 disk
+-vda1 254:1 0 512M 0 part /mnt/boot/efi
L-vda2 254:2 0 14.5G 0 part
L-container 253:0 0 14.5G 0 crypt
+-rootvg-swap 253:1 0 1G 0 lvm [SWAP]
+-rootvg-root 253:2 0 5G 0 lvm /mnt
L-rootvg-home 253:3 0 2G 0 lvm /mnt/homeКак мы видим, всё честно и теперь время ставить сам арч.
Установка базовой системы
Устанавливаем базовые пакеты из наборов base и base-devel используя пакет pacstrap( им можно поставить всё, что вы хотите и кроме этого):
pacstrap /mnt base base-develВсё прекрасно загрузилось, базовая система готова. Вывод я, естественно, убрал. Теперь мы можем настроить эту самую систему, чтобы она загрузилась и работала.
Из базовых вещей сразу сгенерируем fstab:
genfstab -pU /mnt >> /mnt/etc/fstab
Далее сделаем arch-chroot в эту новую систему:
[root@archiso ~]# arch-chroot /mnt
*** arch-chroot очень даже годная утилита, потому как она делает всё сама. Хотя вы всегда можете воспользоваться стандартным chroot, перед этим выполнив всё по инструкции gentoo-handbook wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base раздел «Mounting the necessary filesystems»
Cразу настроим системное время и hostname:
ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime && hwclock --systohc && echo luks-test > /etc/hostname
Зададим пароль root:
[root@archiso /]# passwd root
New password:
Retype new password:
passwd: password updated successfully
Раскомментируем нужные локали в /etc/locale.gen:
[root@archiso /]# vi /etc/locale.gen
[root@archiso /]# grep -v '^#' /etc/locale.gen
en_US ISO-8859-1
en_US.UTF-8 UTF-8
ru_RU.UTF-8 UTF-8
ru_RU ISO-8859-5Сгенерируем их:
[root@archiso /]# locale-gen
Generating locales...
en_US.ISO-8859-1... done
en_US.UTF-8... done
ru_RU.UTF-8... done
ru_RU.ISO-8859-5... done
Generation completeСразу их настроим для системы и консоли:
[root@archiso /]# echo LANG=en_US.UTF-8 > /etc/locale.conf
[root@archiso /]# echo KEYMAP=ru > /etc/vconsole.conf
[root@archiso /]# echo FOND=cyr-sun16 >> /etc/vconsole.confТеперь настроим файл /etc/mkinitcpio.conf, который у нас отвечает за опции, хуки и прочее при генерации initramfs:
vi /etc/mkinitcpio.confСамое главное здесь хуки и их порядок:
HOOKS=(base udev autodetect modconf block keymap encrypt lvm2 resume filesystems keyboard fsck)*** хук resume для загрузки системы после гибернации из swap. На виртуалке он не нужен. Скопировал его с бука.
Теперь мы можем сгенерировать initramfs:
[root@archiso /]# mkinitcpio -p linux
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
-> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 4.17.14-arch1-1-ARCH
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [keymap]
-> Running build hook: [encrypt]
-> Running build hook: [lvm2]
-> Running build hook: [resume]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful
Теперь, когда у нас есть система, нам нужно установить сам загрузчик. Мой выбор пал на grub(2), потому как он как-то роднее и достаточно легко умеет загружать ядро с зашифрованного раздела(ну или я особо не искал другие).
Установим пакет grub:
[root@archiso /]# pacman -S grub dosfstools efibootmgr mtools
Перед генерацией конфига отредактируем дефолтные опции grub:
vim /etc/default/grub
здесь нужно раскомментить одну важную строчку(без коммента, естественно):
# Uncomment to enable booting from LUKS encrypted devices
GRUB_ENABLE_CRYPTODISK=y
и добавить(там пусто по умолчанию) в GRUB_CMDLINE_LINUX:
GRUB_CMDLINE_LINUX="cryptdevice=UUID=5ad7c9ad-fb17-4839-925e-479432516c07:container"
UUID я взял из blkid:
[root@archiso /]# blkid | grep vda2
/dev/vda2: UUID="5ad7c9ad-fb17-4839-925e-479432516c07" TYPE="crypto_LUKS" PARTLABEL="Linux filesystem" PARTUUID="667a1243-17ff-4f03-952c-5afd5e3415cc"
Генерируем конфиг для grub:
[root@archiso /]# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Found linux image: /boot/vmlinuz-linux
Found initrd image: /boot/initramfs-linux.img
Found fallback initrd image(s) in /boot: initramfs-linux-fallback.img
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
done
Далее устанавливаем сам grub на диск:
[root@archiso /]# grub-install /dev/vda
Installing for x86_64-efi platform.
...
Installation finished. No error reported.
*** можно добавить --recheck --debug, указать архитектуру… но… оно ведь само и так работает)
Теперь отредактируем /etc/crypttab, чтобы сама система знала, что при загрузке надо расшифровывать LUKS раздел. Добавим строчку:
echo "container /dev/vda2 none" >> /etc/crypttab
Которая означает, что надо запрашивать пароль(none) для раздела /dev/vda2 и представлять его уже как container через device mapper.
Теперь мы готовы выйти из chroot и перезагрузить систему:
[root@archiso /]# exit
exit
[root@archiso ~]# reboot
Welcome back!Теперь обратимся к консоли виртуальной машины чтобы увидеть результат:
На данном этапе у нас запустилось EFI-приложение /boot/efi/EFI/arch/grubx64.efi с /dev/vda1, которое запрашивает у нас пароль, чтобы расшифровать наш контейнер.
Далее, после ввода пароля:
Здесь уже привычное окно grub с нашими опциями загрузки из /boot/grub/grub.cfg.
На данном этапе grub расшифровал наш контейнер и получил доступ к этом самому файлу (/boot/grub/grub.cfg), ядру и initramfs. После выбора опции по умолчанию загрузится ядро, initramfs:
Активно, ядро и дело дошло до хука encrypt, который заново спрашивает нас пароль для расшифровки контейнера( вообще влом 2 раза вводить пароль, но может быть так, что вы от излишка паранойи сделаете 2 контейнера для boot и root :)
И далее уже после полной загрузки системы:
PS: для повышения уровня шизофрении здесь не хватает только secure boot, чтобы подписать наш загрузчик grubx64.efi.
Просто положить ядро и initramfs на /dev/vda1 я счёл безыинтересным, так как 100 раз так уже делал. Другие загрузчики типа SHIM, bootctl и прочее не умеют вытворять подобного(ну и ли я не в курсе — расскажите в комментах )
Комментарии (46)
ElegantBoomerang
14.08.2018 21:45Где-то читал о красивейшем трюке — вы создайте ещё один Key для LUKS, и положите его в initramfs, и им же декодируйте диск. Тогда пароля для grub2 хватит. Если с вашим опытом получится впихнуть — будет огненно.
AlexGluck
14.08.2018 22:48Звучит как оставьте в открытом виде пароль, так удобнее будет вас взломать. Я бы лучше сканером отпечатков во втором запросе открывал.
ElegantBoomerang
14.08.2018 22:53Так нет, вы кладёте второй ключ к диску внутрь initramfs на зашифрованном разделе, который надо как-то ещё открыть. Конечно, в теории это дополнительная уязвимость, но доступ к нему ещё надо получить изнутри загруженной системы.
Я ещё видел, как прикручивают аппаратные токены к LUKS, и кажется этот этап тоже на Grub не сделаешь, он не умеет так.
tenhi_shadow Автор
15.08.2018 01:04красивейший трюк меня просили сделать на прошлой работе. Суть — найти секурный VPS, где потом настроить luks таким же образом, что и описано в системе, но зашить в initramfs мини-образ системы с сетью и ssh-демоном, что использовать ssh для того, чтобы после перезагрузки системы открыть контейнер и загрузить саму систему.
Не хватило времени и желания… пришлось уволиться)
Grief
15.08.2018 02:18У себя сделал отдельные разделы /boot и / (root) внутри luks-раздела с помощью lvm. После окончания загрузки, /boot и соответствующий ему /dev/mapper уже не нужны, и они не монтируются в системе, так что для того, чтобы вытащить luks-ключ из работающей системы требуется сперва ввести этот самый ключ для монтирования /boot-раздела. Хотя это, скорее всего, излишне. Если у кого-то есть root-доступ к работающей системе (который нужен для того, чтобы распаковать initramfs), то luks-ключ ему, в общем-то, и не нужен уже
AlexGluck
14.08.2018 22:58Жаль что resume не работает на шифрованной подкачке с включенным secureboot. Пришлось на ноуте отказаться от secureboot и шифрованных разделов.
barker
14.08.2018 23:10А как именно на это влияет secureboot? Сам по себе suspend-to-disk вполне можно использовать с LUKS же. При загрузке монтируется шифрованное устройство, поверху LVM, там своп и далее как обычно. Ну или ещё какие-то там способы на том же арчвики были другие, емнип.
AlexGluck
15.08.2018 01:32https://m.habr.com/post/308032/
Вот тут информация по причине неработоспособности гибернация. Никаких подвижек пока нет. Если я хочу сохранить полный контроль за загрузкой и использую единственную точку входа в виде граба, который даже подписанный может быть скомпрометирован, потому что конфиг то лежит рядом незашифрованый. Ну не засунуть в мой криптоконтейнер закладку, значит засунут в граб скрапер и я не замечу. Единственное решение это каждый раз подписывать ядро и все его модули, но тогда срабатывает патч запрещающий даже с зашифрованной подкачки выходить из гибернации, а каждый раз пересобирать ядро для удаления этого патча, задача неблагодарная. Патч для подписи образа восстановления тоже висит в аналах истории и никто не торопиться его вливать в апстрим. Прошло уже столько лет, а защитить Линукс ноуты с помощью secureboot до сих пор нельзя.tenhi_shadow Автор
15.08.2018 08:10Способ 1. Отключить верификацию модулей ядра
Включённая верификация модулей ядра отключает гибернацию. По умолчанию верификация модулей ядра включается вместе с Secure Boot, однако она от Secure Boot не зависит. Её можно отключить, оставив только Secure Boot.
Собственно, вижу способ, не вижу препятствий. Т.е. достаточно будет только подписать сам загрузчик, а модули ядра особо и незачем будет подписывать, потому как они лежат в криптоконтейнере и всё будет работать. Не?
Если я хочу сохранить полный контроль за загрузкой и использую единственную точку входа в виде граба, который даже подписанный может быть скомпрометирован, потому что конфиг то лежит рядом незашифрованый.
Конфиг какой? /boot/grub/grub.cfg лежит уже внутри криптоконтейнера.
Ну не засунуть в мой криптоконтейнер закладку, значит засунут в граб скрапер и я не замечу.
Ну тут я только один метод могу представить — кто-то нашёл уязвимость в самом luks, secure boot и т.д., что достаточно сложно и надо таком человеку руку пожать простоAlexGluck
15.08.2018 10:08Хм, ну вот лежит у меня бинарник в efi разделе, всё остальное зашифровано. Вопрос, какую задачу будет выполнять этот бинарник, если доступа к конфигурации у него нет? Наверно попытается все блочные устройства подключить? А если в конфиге параметр отвечающий за шифрование запрещает расшифровку?
tenhi_shadow Автор
15.08.2018 10:37ну, если быть точным, бинарник будет искать все устройства, которые имеют определённый HEADER (TYPE=«crypto_LUKS») и далее спрашивать пароль на открытие этого контейнера.
Вот у меня по статье зашифровано всё и открыт только один файл efi и всё(ну, естественно раздел тоже)
А если в конфиге параметр отвечающий за шифрование запрещает расшифровку?
а чёт как-то бессмысленно звучит. Зашифровывать раздел а потом указывать, что надо запрещать расшифровку, так-то оно да, целее будет, согласен.AlexGluck
15.08.2018 10:41А если я ССЗБ и в конфиге запретил luks? Тогда он будет игнорировать мой конфиг что-ли или не будет ничего выполнять(как он узнал до расшифровки контейнера, что в конфиге запрещено расшифровывать)?
tenhi_shadow Автор
15.08.2018 10:59что такое ССЗБ? В каком конфиге LUKS? Что значит «запрещать»?
Тогда он будет игнорировать мой конфиг что-ли или не будет ничего выполнять
Он это кто? LUKS? GRUB? Ваши вопросы меня… немного смущают. Странные они. Я лучше вместо полемики бесполезной просто расскажу, как оно, на мой взгляд, работает(как я понял)
1. UEFI запускает grubx64.efi
2. Это запущеное приложение ищет по HEAD устройство LUKS, спрашивает у вас пароль ( Grub 2.02~beta2-29 supports reading an encrypted /boot partition. option GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub )
3. Контейнер открывается для самого grub после успешного ввода пароля. Становится доступной содержимое /boot/* (у меня оно там же, где и /)
4. С открытого контейнера с опциями, параметрами загружается ядро, initramfs.
5. На этапе загрузки initramfs, а именно предварительно настроенного хука encrypt второй раз спрашивается пароль уже для системы. Контейнер заново открывается уже для самой системы и вы работаете в ней.
PS. такое ощущение, что тупо троллите.AlexGluck
15.08.2018 11:07Дискоммуникация просто. Итак после запуска граб, с какого перепуга он будет искать luks? А если у меня кейс без шифрования? А если я указал в конфиге граба GRUB_ENABLE_CRYPTODISK=n как он об этом узнает без расшифровки контейнера? Ссзб — сам себе злобный Буратино, устоявшееся выражение, означающие, что мы сами создали себе такую ситуацию, в которой у нас проблемы.
tenhi_shadow Автор
15.08.2018 11:14Лан, не вопрос, просто как-то слог сложноват для понимания.
А если у меня кейс без шифрования? А если я указал в конфиге граба GRUB_ENABLE_CRYPTODISK=n как он об этом узнает без расшифровки контейнера?
А вот тут вот самое забавное.
1. Итак, представим, что мы такие всё зашифровали и у нас сейчас в /etc/default/grub GRUB_ENABLE_CRYPTODISK=n, далее мы делаем grub-install /dev/vda и вот, что происходит, ololo.efi генерится заново и т.д.
Потом мы грузимся(пытаемся) и, так как grub не видит конфига он тупо входит в grub-rescue или как там оно называется.
2. Сразу после этого, мы с live-cd заходим, открываем контейнер, бла-бла-бла, заходим в chroot и меняем GRUB_ENABLE_CRYPTODISK=y в /etc/default/grub, далее опять делаем grub-install /dev/vda, и тут получаем уже новый ololo.efi, который уже будет пытаться найти и запросить пароль для расшифровки luks.
Как-то так. Попробуйте, оно так и есть
Т.е. как я понимаю, этот файл *.efi уже немного другой.
В efi вон люди даже тетрис запускают :)AlexGluck
15.08.2018 11:27Если вы знаете, то после переконфигурирования не переустанавливать загрузчик в начало диска, да и для efi это не нужно, оно же оперирует последовательностью загрузки из nvram, а файлы для загрузки кладутся на ефи раздел. Ну и бинарник не перекомпилируется для ефи. Суть вопроса в общем то таже, в теории мы в граб рескью свалимся, но как граб узнает можно расшифровывать или нельзя наш контейнер с конфигом для граба в котором этот параметр указан?
tenhi_shadow Автор
15.08.2018 11:44ок, давайте разложим для понимания тогда.
У нас есть 3 «инстанции», куда обращается GRUB, записывает и чем оперирует.
1. «последовательность загрузки в nvram». По сути это некая область памяти на мат. плате, где написать «шо и куда и последовательно как»
2. Начало диска — как обратная совместимость с обычной BIOS загрузкой (первые 4** байт, кто-то говорит 512, где-то написано, что до 2 мегабайт может занимать) — не суть
3. /boot/efi — раздел fat32 EFI — туда кладётся исполняемый бинарник — приложение UEFI — совместимое.
Моя догадка в том, что бинарник всё-таки меняется и, собственно он(исполняемый файл EFI, выполняясь, уже имеет инструкцию искать и предлагать расшифровать).AlexGluck
15.08.2018 11:56Ну это мы с вами гадаем, а хочется же научиться, чтобы знать точно. Подождём, может кто ответит.
tenhi_shadow Автор
15.08.2018 12:00ну, у меня после такого теста просто нет сомнений, что это действительно так:
1. Итак, представим, что мы такие всё зашифровали и у нас сейчас в /etc/default/grub GRUB_ENABLE_CRYPTODISK=n, далее мы делаем grub-install /dev/vda и вот, что происходит, ololo.efi генерится заново и т.д.
Потом мы грузимся(пытаемся) и, так как grub не видит конфига он тупо входит в grub-rescue или как там оно называется.
2. Сразу после этого, мы с live-cd заходим, открываем контейнер, бла-бла-бла, заходим в chroot и меняем GRUB_ENABLE_CRYPTODISK=y в /etc/default/grub, далее опять делаем grub-install /dev/vda, и тут получаем уже новый ololo.efi, который уже будет пытаться найти и запросить пароль для расшифровки luks.
к тому же… чего ждать, если можно тупо почитать:
www.gnu.org/software/grub/manual/grub/grub.html
‘GRUB_ENABLE_CRYPTODISK’
If set to ‘y’, grub-mkconfig and grub-install will check for encrypted disks and generate additional commands needed to access them during boot. Note that in this case unattended boot is not possible because GRUB will wait for passphrase to unlock encrypted container.
и я думаю, что нет способа «generate additional commands needed to access them during boot» без перекомпиляции этого бинарника.
barker
15.08.2018 08:32(Хорошая статья, упустил, ещё раз внимательнее покопаю позже.) Ну я там не вижу про неработоспособность. Ну да, есть проблемы, но точно это лучше чем альтернатива в виде «отказаться от secureboot и шифрованных разделов». Или я не понимаю чего-то, зачем и то и то отключать, в крайнем случае можно отключить secureboot только уж. Тем более что разделы шифруются и подавно в основном не от хакеров, а от потерь/краж или от доблестных служб.
tenhi_shadow Автор
15.08.2018 09:06а статья ведь не сильно новая, и ссылка на git, где отключен hibernate для secureboot может быть уже и не такой актуальной
tenhi_shadow Автор
15.08.2018 01:09я вот видел пару раз шифрование подкачки. Расскажите мне зачем и почему? т.е. я видел, что бывает так, что система не зашифрована, а swap — зашифрован.
Насколько я помню swap очищается при корректном выключении/перезагрузке системы. Стало быть только стоп виртуалки или выключение по питанию может сохранить данные в swap (т.е. по сути продолжение обычной памяти). Но, так как свопится зачастую всякое, скажем не такое уж и важное, то какова суть шифровать swap без шифрования рута?
PS, ещё помню, что XSPider на вёнды 2000,2003 показывал уязвимость «Неочищаемый раздел подкачки» и советовал в реестре это исправить. Кто знает как это вообще можно использовать для компроментирования удалённой системы?AlexGluck
15.08.2018 01:35Выше я дал ссылку на хорошую статью. Ну и если немного покопаться, то поймёте, что в подкачку скидывается образ восстановления для гибернации (режим suspend-to-disk). Чтобы закладку туда не пихнули и/или ключи шифрования оттуда не вытянули. А шифровать только подкачку это для извращенцев, которые так захотели.
levap
15.08.2018 10:59Я тоже с шифрованием дисков делал интересную штуку. Есть сервак в личном использовании, который содержит разную личную информацию, есть вероятность его физической кражи. Было желание обеспечить шифрование чувствительных данных, но при этом возможны перезагрузки по питанию, и сервер должен был полностью загружаться без участия человека. Вышел из ситуации следующим образом — root оставил незашифрованным (кому нужен мой линукс?), а конфиденциальные данные разместил на шифрованных разделах, которые маунтятся с помощью ключа, который забирается с другой машинки в сети по ssh, она надежно припрятана (это маленькая платка на арме). Таким образом, не зная схемы работы всего этого добра и не найдя машину с ключом, физическая кража дисков не приведет к утечке данных, при этом загрузка системы автономна и не требует ввода паролей.
tenhi_shadow Автор
15.08.2018 11:26у меня так proxmox работает — весь storage зашифрован.
Но вчера в голову пришла мысль, что избежать терморектального метода расшифровки поможет только электронное тело)levap
15.08.2018 11:33Ну, понятное дело, что от специально обученных людей так не защитишься, да это и не было целью. Скорее от случайной гопоты, обладающей некоторыми компьютерными знаниями.
dinisoft
16.08.2018 23:22Пусть и повторюсь, но для чего здесь grub? У вас в наличии уже есть systemd и ядро с efi заголовком!!! Разделы шифруете парольной фразой, stub+kernel+initrd в один подписанный файл, ключ в nvram и… Всё, кроме esp зашифровано, модификация initrd исключена, т.к. подписано ключём, который на шифрованном разделе.
В общем статья — очередной велосипед, да ещё и с квадратными колёсами.tenhi_shadow Автор
16.08.2018 23:28ну, здесь зачастую люди и делятся велосипедами. Вариант имеет место быть и ваш тоже, мне как-то привычнее и удобнее было сделать именно так.
Велосипед с квадратными колёсами едет немного с бОльшим усилием, а тут по «усилиям» — производительности, ресурсам, скорости загрузки вообще ничего не изменится.
paran01k
17.08.2018 11:09Делал подобное несколько лет назад, только целью было избежать использование данных при краже устройства (ноутбука). Ядро и рам диск не шифровал, а luks заголовок хранился отдельно на внешнем носителе (флешке). Боязно мне было хранить заголовок с мастер-ключом на том же носителе, хоть и зашифрованный паролем. Для этого пришлось поправить хук «encrypt» и прописать правило для udev.
Включил. Ожидание нужной флешки. Вставил, ввел пароль и вытащил. Удобно. Работает до сих пор.
barker
Ну вроде как почти всё по арчвики, один только вопрос — для чего здесь grub? Просто чтобы не класть «ядро и initramfs на /dev/vda1» (т.е. чтобы только часть /boot была незашифрована как у вас, а не весь с ядрами)? Есть какой-то сакральный смысл, оправдывающий использование grub-а в 2018 году в этой схеме?
з.ы. ну и жаль что secure boot упущен, это как раз непростая и местами мутная тема, а очень важная.
tenhi_shadow Автор
к тому же, если не использовать grub, а, к примеру, просто положить ядро придётся положить на открытое место и initramfs(поправьте меня, если я ошибаюсь). И как в этом варианте использовать secure boot? Ну или какой от неё будет толк, если фс открыта и будет можно подменить и ядро и initramfs?
Я примерно понял, как использовать secureboot, по сути эти подписание загрузчика (efi-исполняемого файла) в pki UIFI. Может коряво, но вроде поянил норм.
В моём варианте есть файл grubx64.efi, который мы «подпишем» и вряд ли он изменится(ну или не так часто), а вот если обновится ядро, то как-то заново надо будет secureboot настраивать или?
— До конца не разобрался как secureboot работает, возможно позже добавлю его в статью, когда настрою на ноуте. Но как мне видится, есть только один файл, который является загрузчиком и только его можно подменить, но его же можно и верифицировать через secureboot чтобы избежать подмены.
Поправьте меня, если что не так
barker
Конечно, придётся положить и ядро и initramfs в /boot (хотя повторюсь ниже — не знаю, может есть способы без груба грузить ядро с LUKS, может кто поправит). В параметрах ядра настраивается что нужно и дальше уже всё будет в точности как у вас — пароль при загрузке.
Вы немного путаетесь. Исходим из того, что grub в uefi-загрузке вообще не нужен. Для этого есть же uefi бут-менеджеры, начиная с самого тупого который включен в systemd-boot, он умеет грузить только другие efi-бинарники, например, ядро линукса (если оно efistub, а оно так и есть во многих дистрибах, в т.ч. в арче). И именно он, этот лаунчер, не меняется и подписывается. А так-то понятно уже, что можно в принципе грузить вообще без всего и даже без этого лаунчера, прямо из загрузчика на материнке сразу ядро.
barker
Ну вернее тут видимо нужно ещё уточнение, grubx64.efi это как бы и есть «uefi бут-менеджер», который на самом деле просто efi-версия груба.
tenhi_shadow Автор
ниииииит! grubx64.efi это бинарный файл, efi-приложение, которое тупо запускается, а дальше уже работает… как приложение собсно.
А вот, к примеру, efibootmgr, он чуть более крут, он ( мой любимый приём — поправьте, если не так ) efi-приложением не является, а напрямую взаимодействует с efi, позволяя поменять порядок загрузки, создать порядок и беспорядок)
barker
Под бут-менеджерами подразумевается тут UEFI boot manager, которыми являются всякие systemd-boot, rEFind, виндовый (не помню как оно там) итд, т.е. efi-приложения которые грузятся непосредственно загрузчиком мат.платы и дальше уже грузят другие efi-бинарники, утилиты всякие, ядро итд.
Ну да, efibootmgr это просто утилита, которая настраивает как раз тот самый uefi-загрузчик на мат.плате, а именно — прописываются пункты меню те которые «в биосе» (т.е. пути на эти самые UEFI boot manager на загрузочном разделе). Обычно туда лезут как раз всякие грубы чтобы прописать на себя запись. Я стараюсь на незнакомых компах это не трогать (детская травма от окирпичивания, раньше это было обычное дело если неправильно покопаться), ставлю просто по дефолтным путям, а дальше в rEFind уже настраиваешь что хочешь. Сейчас вообще просто systemd-boot без изысков.
tenhi_shadow Автор
у меня как раз /boot зашифрован. Разве нет? — доступен только /dev/sda1 fat32, на котором grub-файл и всё, дальше только по парольной фразе
barker
Да, если вы хотите ядро шифровать, то кроме grub я не знаю как ещё можно грузить, может есть какие-то uefi-лаунчеры, никогда не интересовался, т.к. повторюсь груб в uef как-то лишним кажется, потому у меня и возникает вопрос — стоит ли оно того.
LenKagamine
Не только мутная и важная, но ещё и опасная для устройства, как это выяснилось. Недавно настраивал следуя инструкциям из статьи и на следующий день обнаружил что suspend2ram (ждущий режим) у меня больше не работает.
tenhi_shadow Автор
почитайте другие комменты. там написано почему.
LenKagamine
Вы про патч в ядре, который отключает resume? Это однозначно не то. Suspend != hibernation (вечно с этим путаница).
Секурбут так и не заработал, потому что где-то во время создания ключей я допустил ошибку и просто снова его отключил. А ждущий режим так и не заработал ни на Linux, ни на Windows.