LINUX.ORG.RU
решено Форум — Security  

Keyslot 0 (luks2) open failed with -22

 , ,


0

1

Приобрел на днях девайс, и решил накатить Gentoo с шифрованным корневым разделом. Итого:

/dev/nvme0n1p1 - /boot/efi (vfat)
/dev/nvme0n1p2 - /boot (ext4)
/dev/nvme0n1p3 - раздел с luks2 с /

Я решил не использовать LVM в качестве дополнительной прослойки - грубо говоря скопипастил отсюда: https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LUK...

В итоге в чруте все работает, cryptsetup luksOpen /dev/nvme0n1p3 rootfs отлично отрабатывает, запрашивает пароль, затем монтируется. Туда навернул ядро, собрал. После n-ых попыток все-таки правильно сконфигурил граб, собрал initrd (dracut):

dracut -a crypt --lz4 --hostonly '' 4.19.57-gentoo-build-1 --force

В итоге я загружаюсь, вижу предложение ввести пароль, и после ввода оно мне говорит wrong password (хотя с livecd с systemrescuecd все «ок»). Версии одинаковы в установленной системе и той, с которой гружусь. Если запустить в вывалившемся initrd команду cryptsetup с дебагом, то там видно что-то вроде

# dm status rootfs [ opencount noflush ]  [16384] (*1)
# Keyslot 0 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0
# Keyslot 0 (luks2) open failed with -22

Если запускать с livecd, последняя строчка вычитывает адрес:

# Reading keyslot area [0x8000]

и открывает устройство. Может коллективный разум ЛОРа подскажет, как чинить?

P.S. как я понял, luks1 и luks2 форматы разные, такое впечатление. что оно не может вычитать luks2 формат

★★★★★

Последнее исправление: leg0las (всего исправлений: 3)

Сам запостил, сам решил

cryptsetup был собран без флага argon2 - как я понимаю просто применялись другие алгоритмы к хешированию пароля. luks1_default можно выпилить (т.е. работать только с luks2). lvm собран с флагом device-mapper-only - т.е. собственно без LVM (а он мне и не нужен), хотя пишут, что на свой страх и риск, ансаппортед.

И самое главное - dracut в initrd почему-то не включал либу 

/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libgcc_s.so.1

с флагом -I и этой либой собрался корректный initrd и все заработало

Может кому-то пригодится, кто налетит на мои грабли по тюнингу и оптимизации, гг.

leg0las ★★★★★
() автор топика
Ответ на: комментарий от leg0las

Почему не использовал стандартные инструкции для Gentoo и стандартные инструменты для создания initrd?

В официальной документации все написано.

Надо также шифровать /boot

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

Да:

grub-install --pubkey ключ --modules='gcry_rsa' /dev/...

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

Необходимо шифровать и /boot и / так вектор атаки сужается только до core.img и MBR которые защищаемого TPM.

Если шифровать только /home то тебе руткит с кейлогером в / запишут и украдут ключи/пароли для расшифровки /home и сделают это даже удаленно.

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

Надо также шифровать /boot

А расшифровывать как?

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

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

Ага. только если у меня комп включен, то все партишены и так расшифрованы.

А если комп попал в руки уже супостату, то он и так что-нибудь придумает.

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

Если /boot и / шифрованы, то за остальным можно присмотреть даже без tboot, secureboot, TPM:

https://www.opennet.ru/openforum/vsluhforumID3/117844.html#100

Как на GRUB cmd, написать проверку от буткитов? Пробывал опять, не получилось. Все нужное почти есть:

Получение информации: cmosdump, lspci, usb, pcidump, vbeinfo, net_ls_cards,...

Верификация: verify_detached, hashsum --hash ...

Стандартный синтаксис bash: if, else, fi, ...

Мне не хватает '>' или '|'.

Может предложешь что или таки надо патчить этот GRUB cmd?

https://www.opennet.ru/openforum/vsluhforumID3/117844.html#78

Шифровать /boot необходимо в любом случае, ибо он содержит важнейшие для безопасности системы файлы! Да, при отсутствии SecureBoot или TBoot, есть возможность атаки на GRUB core.img.

Но это все равно сильно затрудняет взлом, а если применяется простенький «антибуткит», проверяющий криптографическую целостность MBR/core.img и лежащий в шифрованом /boot, то о вторжении становится известным ещё до расшифровки раздела / и по этому есть возможность гарантировать целостность и секретность / !!! Надо просто выключить комп и загружаться с другого, чистого загрузчика, например LiveCD/DVD, затереть скомпроментированый MBR, core.img вместе с не гарантированным /boot и установить чистые старые.

https://www.opennet.ru/openforum/vsluhforumID3/117844.html#101

Т.е. вы беретесь «на глаз» различить, действительно ли был запущен ваш антибуткит или это фейковый вывод подставного загрузчика? o_O

Фейковый загрузчик при первой загрузке не будет знать что в шифрованом /boot, только пароль/ключ для его расшифровки успеет украсть.

На grub cmd пытаюсь навалять простенький скрипт, с проверкой. Если проверка не прошла, то вывод сообщения и команда halt. При первой загрузке зловредный буткит ничего не знает о проверке, сообщении и команде halt.

Но как это сможет гарантировать целостность и секретность / ?

Криптографическая целостность / гарантируется применяемыми алгоритмами шифрования для /, а гарантии секретности данных в / сохраняются потому что не был введён пароль для их расшифровки. (Если только ключ для расшифровки / не хранится в /boot)

Скомпроментироваными можно считать все что есть до / в процессе загрузки.

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

ipsec/l2tp доступы в /etc, хомяк (да, можно отдельно)

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