Описание схемы: Настроил в системе шифрованный раздел swap в дополнение к шифрованному /home в заголовки luks для раздела swap прописал текстовый пароль и файл-ключ, файл ключ лежит в шифрованном /home (это важно!!) соответственно в /etc/crypttab для swap прописан путь к ключу как /home/имя_файла.key: И в fstab и в crypttab сначала прописаны настройки для /home, ниже (после) для раздела swap. В параметре ядра resume для grub прописан UUID раздела шифрованного swap. Ожидаемое поведение: при загрузке система спрашивает пароль от /home, считывает из файла (из шифрованного /home) ключ для разблокировки swap, разблокирует и монтирует swap. При просыпании из hibernate спрашивается пароль от раздела swap, swap расшифровывается и система благополучно просыпается.. в обоих случаях пароль спрашивается один раз. такая схема у меня на "старом" ноутбуке успешно реализована и уже пару месяцев стабильно работает. Проблема: когда настроил точно так-же на новом ноутбуке, столкнулся со странностью - при "просыпании" из hibernate пароль от раздела swap не запрашивается. "Копания" привели к тому что "виноват" скорее всего make-initrd Вот такая последовательность: #переименовать файл ключа #make-initrd --kernel=uname -r #grub-mkconfig -o /boot/grub/grub.cfg #переименовать файл ключа обратно ситуацию временно "пролечивает". "Пролечивает" - означает что ключ в initrd не копируется, порядок запроса пароля при загрузке/просыпании соответствует ожидаемому. На "новом" ноутбуке воспроизводится с любым ядром. На "старом" стабильно не воспроизводится. Причем и там и там установлена workstation-k, обе системы обновлены до актуального p10. Разница: -старый - дистрибутив workstation-k 10.1, /home на ext4 поверх luks -новый - дистрибутив workstation-k 10.2B2, /home на btrfs поверх luks,на / настроены subvolumes для совместимости с timrshift. Может отличаться состав установленных пакетов но не сильно. Причина: Файл с ключом попадает в образ initrd: # initrd-ls /boot/initrd-6.1.21-un-def-alt1.img | grep home 2 drwxr-xr-x 2 0 0 0 Jan 01 03:00:00 1970 ./home 2 drwxr-xr-x 2 0 0 0 Jan 01 03:00:00 1970 ./home/root 2 -r-------- 1 0 0 4096 Jan 01 03:00:00 1970 ./home/.my-luks.key Потенциальная уязвимость: непрозрачно для пользователя, по умолчанию, ключ с зашифрованного носителя в каких-то ситуациях может копироваться в открытый initrd и становиться потенциально публично доступным.. Предлагаемый метод исправления: 1.При копировании файлов ключей в initrd писать об этом большими буквами в консоль 2.Нужна опция которая явно будет отключать такое копирование ключей. По умолчанию наверное правильнее отключить этот функционал
Вот еще разница - на "старом" ноутбуке я изначально устанавливал систему с созданием шифрованного раздела под /home, на "новом" я при установке системы просто оставил часть диска не размеченным, и потом уже создал там шифрованный раздел и перенес на него /home
Вот если в этом файле: /usr/share/make-initrd/features/luks/bin/get-dat закомментировать вот эти строки (начиная с 74 строки): # if [ -z "$keydev" ] && [ -f "$keyfile" ]; then # mkdir -p -- "$DIR/${keyfile%/*}" # cp -- "$keyfile" "$DIR/$keyfile" # fi То поведение становится ожидаемым - один запрос пароля при загрузке, один при просыпании и ключика уже нет в initrd: # initrd-ls /boot/initrd-6.1.21-un-def-alt1.img | grep home 2 drwxr-xr-x 2 0 0 0 Jan 01 03:00:00 1970 ./home 2 drwxr-xr-x 2 0 0 0 Jan 01 03:00:00 1970 ./home/root Но просто так их комментировать было бы неправильно - оно для чего то было сделано так специально. Но вот добавить куда-то какой-то параметр чтобы этим можно было бы управлять - было бы очень полезно
Вот есть еще во feature luks вот такой файлик: /usr/share/make-initrd/features/luks/guess/device там оно ищет uuid относящиеся к luks-устройствам, потом в /usr/share/make-initrd/features/luks/bin/get-data сравнивает эти uid-ы и найденные в crypttab.. Таким образом наименее "костыльным" способом обхода копирования ключей в открытый iintrd, является запись в crypttab исключающая uuid, например так: luks-swap /dev/nvme0n1p3vm ./home/.my-luks.key luks,discard В общем у меня, при такой записи ключик в initrd перестал копироваться. Но саму ситуацию копирования ключей в initrd с шифрованных носителей считаю небезопасной
