Bug 45803

Summary: При создании initrd.img на незашифрованном / в него может попадать ключевой файл luks, расположенный на зашифрованном разделе
Product: Sisyphus Reporter: Alexander <alxste>
Component: make-initrdAssignee: Alexey Gladkov <legion>
Status: NEW --- QA Contact: qa-sisyphus
Severity: normal    
Priority: P5 CC: aen, glebfm, ldv, legion, placeholder, rider
Version: unstable   
Hardware: x86_64   
OS: Linux   

Description Alexander 2023-04-10 14:07:56 MSK 
Описание схемы:
Настроил в системе шифрованный раздел 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.Нужна опция которая явно будет отключать такое копирование ключей. По умолчанию наверное правильнее  отключить этот функционал
Comment 1 Alexander 2023-04-10 14:41:36 MSK 
Вот еще разница - на "старом" ноутбуке я изначально устанавливал систему с созданием шифрованного раздела под /home, на "новом" я при установке системы просто оставил часть диска не размеченным, и потом уже создал там шифрованный раздел и перенес на него /home
Comment 2 Alexander 2023-04-10 23:15:16 MSK 
Вот если в этом файле:
/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


Но просто так их комментировать было бы неправильно - оно для чего то было сделано так специально. Но вот добавить куда-то какой-то параметр чтобы этим можно было бы управлять - было бы очень полезно
Comment 3 Alexander 2023-04-12 11:07:59 MSK 
Вот есть еще во 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 с шифрованных носителей считаю небезопасной