Полнодисковое шифрование говорят они...

Насколько я помню, когда у меня был арч с шифрованным LLVM (а /boot был нешифрованный) неверный ввод пароля приводил к задержке в несколько секунд перед следующей попыткой. Почему здесь не так?

Подобная новость про «уязвимость» была пару лет назад: скрипты в initramfs одного из дистрибутивов после неуспешных попыток ввода пароля запускали консоль из под рута (диск так и оставался неразблокированным и пароль не раскрывался). Правда толка в этой атаке нет, потому что злоумышленник с доступом к ПК и так может загрузить своё root окружение.

Чем больше таких новостей, тем больше убеждаюсь в справедливости мнения, что в ИБ идёт вал новичков, которые попросту выдумывают уязвимости.

Это зависит от того, какой initrd и как настроены скрипты. В арче я сначала использовал mkinitcpio, в нём вроде была опция получить доступ к консоли, если возникали ошибки при загрузке, правда это поведение не по умолчанию. Потом стал использовать dracut - он тоже может дать доступ. В других дистрибутивах может быть по-другому.

Почему нельзя просто запустить ту же утилиту с лайвсиди?

ключи для разблокировки хранятся в TPM

ну тоесть без TPM проблемы нет

TPM. Не сойдется контрольная сумма конфигурации и TPM не выдаст ключ.

А ещё может быть отключена загрузка с флешек и пароль на BIOS. На ноутбуках вытаскивание батарейки не поможет - nvram легко может быть в виде флешпамяти и энергонезависим.

А при чём здесь luks?

ЯННП, в чём уязвимость-то?

На монитор приклеили бумажку с паролем.

Опять какие-то убунто-проблемы. У меня, например, вместо emergency shell есть только сообщение root account is locked и предложение сделать ребут.

Это все долго и дорого.

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

когда у меня был арч с шифрованным LLVM … Почему здесь не так?

(и MagicMirror)

Потому что здесь совершенно другая область применения.

Подобные конфигурации […] в TPM обычно применяются, когда необходимо обеспечить шифрование дисков на удалённых серверах, на которых нет возможности после каждой перезагрузки вручную вводить пароль для разблокировки зашифрованных дисков.

Вынужденно понадобилось некоторое удобство. А каждое удобство - угроза безопасности.

То есть, дыра в TPM, а виновата убанта. Всё ясно-понятно!

У меня как раз с tpm. Но никакие ошибки не приводят к рутовому шеллу.

При чём тут tpm, если кто-то просто даёт тебе рутовый шелл?

Шифрование, не использующее TPM (дефолт во всех дистрах?) не затрагивает?

Но никакие ошибки не приводят к рутовому шеллу.

Тогда картинка при описанном в статье случае была бы следующей:

1. удалённый reboot
2. что-то пошло не так (бывает)
3. failed to auto-unlock encrypted volume
4. «вместо emergency shell есть только сообщение root account is locked и предложение сделать ребут.»
5. удалённый reboot
6. failed to auto-unlock encrypted volume
7. «вместо emergency shell есть только сообщение root account is locked и предложение сделать ребут.»
8. переходим на пункт 5.

И как бэ что? Ну получил кто-то шел в rd и используя настроенную отдельно возможность востановления ключа к разделу, востановил его? Походу мама не учила кого-то что на TPM тоже было бы не плохо PIN использовать.

bastet:~ # cryptsetup luksDump /dev/root_nvme/lv_root 
LUKS header information for /dev/root_nvme/lv_root

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha256
Payload offset:	4096
MK bits:       	512
MK digest:     	a4 c9 d0 a2 b9 46 ac 56 34 20 c6 e1 8d 31 04 8a 21 f1 c1 5b 
MK salt:       	0f fe d8 fa 83 98 31 3c 77 94 33 8c f3 d0 df c1 
               	da 42 67 30 65 4d c7 05 bb ac ad 95 95 02 aa 75 
MK iterations: 	151879
UUID:          	6e158669-4094-4196-97c7-52735fd99be1

Key Slot 0: ENABLED
	Iterations:         	2444232
	Salt:               	bc a6 db 76 0a 75 3b f5 7a d3 dc 5b 68 2a f0 ef 
	                      	f7 75 7a 0a f1 78 49 31 fa 5b 7a eb 68 12 41 f8 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Да и автор статьи в качестве фикса предлагает добавить опцию ядра rd.shell=0 rd.emergency=reboot, т.е. подразумевается что загрузчик защищён от модификации этих опций?

Да уж, гугловик есть, умовика не надо (С)

на TPM тоже было бы не плохо PIN использовать.

Но тогда отвалится авто-разблокировка при перезагрузке.

Да и поддерживал ли Red Hat в энтерпрайзе год-два назад такой метод? Тут сначала речь шла о том, что интерес только обсуждается, а только вот год назад, якобы, появилась поддержка.

У редхат да, когда я ещё условно был их «адептом», они предлагали Tang с кастомизациями, о TPM речи не было, да и разговор был по большей части о серверах а не пользовательских лаптопах.

Чего-то я тупой что ли, но до меня не доходит немного.

Эта уязвимость является уязвимостью в случае удаленной загрузки И знания атакующим пароля root?

Хотя дошло. В emergency mode пароль root не спрашивается, но по идее такой режим должен быть только локально c консоли, а он оказался доступен удаленно.

При чём тут tpm, если кто-то просто даёт тебе рутовый шелл?

Рутовый шелл в initrd. Это считай аналогично загрузке с флешки.

Но тогда отвалится авто-разблокировка при перезагрузке.

А зачем в этом случае вообще полнодисковое шифрование? От чего именно оно защищает? От того, что спёрли только диски, но не сам сервер с TPM? Я что-то слабо представляю себе модель угроз, при которой можно хранить ключ считай в открытом виде рядом с самими данными.

Да, именно так. В чём проблема?

А TPM при чём тут?

При том, что выдаёт ключ к диску без аутентификации. Если ты ещё не понял, на этапе рутовой консоли данные не расшифрованы и доступа к содержимому диска ещё нет.

Я знаю что и как делает TPM. Как ты растянул рутовый шелл в initrd до «дыры в TPM» - не знаю.

Ты хочешь чтобы тебе объяснили? Потому что получение рутового шелла при физическом доступе – это не rocket science.

А в TPM то дыра где?

Чем больше таких новостей, тем больше убеждаюсь в справедливости мнения, что в ИБ идёт вал новичков, которые попросту выдумывают уязвимости.

Всюду идёт вал новичков. Почему ИБ должна быть особенной?

TPM сам по себе дыра. Примерно вот тут.

Ясно, детская истерика от религиозно-неприятной технологии.

Systemd, получив управление после неудачных попыток ручной разблокировки, не сможет получить доступ к файловым системам на зашифрованных дисках, предложит перейти в режим восстановления после сбоя и предоставит доступ к командной оболочке с правами root в окружении загрузочного ram-диска.

Ну то есть уязвимость в systemd, который должен был бы спросить пароль рута, но не спросил. А причём тут шифрование?

Наконец-то, на 4-м десятке комментариев кто-то увидел systemd.

У тебя в штанах истерика. Проблема с TPM в том, что у него проприетарный блоб внутри. В котором могут быть дыры, и единственный способ их залатать – обновление прошивки через обновление бивиса мат.платы. Знаешь, как долго производители плат выпускают обновления? Хорошо если год-два после начала продаж, а потом иди лесом, мальчик.

Делать эту говнину основой безопасности своих данных – безумно тупая идея.

Даже если спросит, то атака сведётся к подбору рутового пароля, который обычно короче и параллелится на порядки проще чем KDF криптотома. Тоже нехорошо.

Ну так это можно и безо всяких имитаций нажатия enter сделать, просто загрузившись в консоль восстановления.

Тоже нехорошо.

А шо делать, если хочется полнодискового шифрования и пароль не вводить.

if it uses RedHat’s Clevis and dracut software to implement unattended unlocking for LUKS full disk encryption. This configuration is desirable when a computer needs to have disk encryption but still allow remote reboots without having someone manually unlock it afterwards

Т.е. это спец конфиг с какими-то тулзами, которые и ослабляют защиту. Штатная инсталляция убунты уже не подвержена уязвимости, как я понял.

просто загрузившись в консоль восстановления.

Если как-то поменять конфигурацию загрузки (cmdline другой), то PCRы не сойдутся. Ну, если правильно настроено.

Наконец-то, на 4-м десятке комментариев кто-то увидел systemd.

Неправда, я увидел его сразу же, но скромно промолчал, решил сначала ответы почитать. :)

А комментарии… мне кажется некоторые перед тем как оставить комментарий прочитали только заголовок, пропустив и цитату из ОП и перевод на опеннет и оригинал, и то, что тема изначально создана в толксах.

А шо делать, если хочется полнодискового шифрования и пароль не вводить.

Буквально и на х*& сесть, и девственницей остаться.

Андроид почему-то может

нет, не может. Почитай как шифрование в андроиде устроено. С LUKS там ничего общего.

Да какая разница как именно оно сделано и есть ли там что-то общее с LUKS. Юзердата хранится зашифрованной вне зависимости от установленных паролей, не обращая внимания на мнение экспертов с опеннета лора.

/boot шифровать не нужно, говорили они :-D

Юзердата хранится зашифрованной вне зависимости от установленных паролей

Если бы, она зависит от установленного pin-кода.

Нет. Пинкодом защищается получение мастеркея (одного из)

Юзердата хранится зашифрованной вне зависимости от установленных паролей, не обращая внимания на мнение экспертов сопеннеталора.

Вот именно. А теперь сравни это с полнодисковым шифрованием и получением ключа без пользовательского ввода вообще. Где в описанном в ТС сценарии ввод пинкода или отпечатка пальца? Нету его.

Как по твоему происходит загрузка без установленного пинкода? Что происходит с данными, защищенными учётными данными устройства, а не юзера? Это что касается Андроида.

А что до ТС - Кто сказал, что секреты для юзерской учётки и для FDE - одинаковые?