id: Гость   вход   регистрация
текущее время 15:27 29/03/2024
Автор темы: ressa, тема открыта 29/07/2014 10:40 Печать
Категории: криптография, инфобезопасность, защита дисков, алгоритмы, операционные системы
https://www.pgpru.com/Форум/UnixLike/МаскировкаВводаПароляВCryptsetup
создать
просмотр
ссылки

Маскировка ввода пароля в cryptsetup


Форумчане, скажите, можно ли сделать в Crytpsetup затирание вывода консоли при вводе пароля на загрузку?
Как в TrueCrypt – фейковая ошибка, например "Invalid BOOT.INI file Booting from C:windows", таким образом ввести в заблуждение по поводу установленной системы и не реагировать на ввод неправильных паролей.
Спасибо


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии
— Yellow (03/11/2016 11:13, исправлен 03/11/2016 11:14)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Прекрасно сказано! :-)



Совершенно точно.


А вообще, меня здесь пугают две собственные ошибки:


1. не была сделана пошаговая проверка
2. действие, обеспечивающее безопасность (окончательная рандомизация неразмеченной поверхности флешки, т.е. не подготовительная – перед разметкой, а окончательная – перед началом использования флешки по назначению) должно было быть сделано как последнее


Эти ошибки безопасность не затронули, поскольку, ввиду понятных причин, флешка после бута всегда затиралась полностью и дважды. Т.е. безопасность была обеспечена прямой мерой. Но сам факт, что в таких простых действиях можно жутко проколоться из-за собственной тупости, просто пугает. :-)

— pgprubot (03/11/2016 19:51, исправлен 03/11/2016 19:53)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Можно было короче:


Программа перед пользователем должна иметь вид лихой и придурковатый, дабы разумением своим не смущать его

Тупыми легче управлять. Выбирайте тупые программы.



Нет, вы всё правильно сделали. Не должен разметчик диска писать непонятно что непонятно куда. Возможно, это даже баг, но проверять ваши действия у меня нет ни времени, ни мотивации. Ваша ошибка только в том, что взяли вместо предсказуемого fdisk непредсказуемый Gparted.


Эти продвинутые вещи (parted) нужны для GPT-разметки. Если у вас не GPT, а стандартная MsDOS-разбивка, зачем переусложнять вещи? То, что вы проверили неизменность неразмеченного пространства — сделали правильно. Ничему на 100% доверять нельзя.


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



В будущем их у вас будет ещё много, целый кладезь. Не расстраивайтесь, все через это проходили. Лучше поздно, чем никогда.

— Гость_ (15/11/2016 21:46)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13
Чей-то блогпост с похожими идеями: Encrypting your HDD with plausible deniability.
— Yellow (19/02/2017 14:18, исправлен 19/02/2017 14:24)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

Была небольшая проблема.



Решение простое до безобразия. Сделать второй маппинг на том же устройстве позволяет опция --shared утилиты cryptsetup.

— Гость_ (19/02/2017 16:27, исправлен 19/02/2017 16:39)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

Да. Помимо прочего, есть много глюков, которые решаются созданием дополнительного маппинга устройства через dmsetup (с обычным устройством что-то сделать нельзя, а с его идентичным маппингом – уже можно). Иногда эти сложности обходятся (когда нужно только считать некоторую область, а не записать) банальным чтением нужных шифрованных секторов в файл в /tmp – тогда не понадобится делать лишние маппинги на самом диске.



Лучше не мучиться, а сделать с Xen, как выше описано, тогда записывать инфу на флэшку придётся только в том случае, когда будете перезагружаться. Самый красивый способ – это обновлять ядро вообще без перезагрузки, что теоретически можно, но не в случае Xen. Xen грузится на "голом металле", а потом грузит хостовую ОС, поэтому эта ОС никак не может обновить код, который запущен приоритетом выше неё. В случае KVM это могло бы сработать, потому что там гипервизор – по сути, просто модуль ядра, а модули, кажется, можно обновлять, не перезагружая ядро. В целом KVM более популярен на Linux и лучше доведён до ума, но у него нет кроссплатформенности в отношении хостовой системы, как у Xen, т.е. поставить вместо неё не Linux или невозможно или крайне проблематично (текущий статус вопроса не гуглил). Гипотетически с KVM можно загрузить любое "начальное" ядро, а потом перейти на любое иное, не перезагружая систему. Допустим, вы загрузились с LiveCD, а потом перешли на ядро с шифрованного диска, а LiveCD вытащили – и всё это без перезагрузки. На 100% не уверен, но, кажется, такое делается.



Я поковырялся немного в скриптах initramfs и приблизительно понял, почему автоматическая загрузка у многих людей не работает. Сами стартовые скрипты в /boot просты для понимания – их при желании можно написать самому под конкретную систему или пропатчить существующие, там не много строк и не сложная логика. Они создаются shell-скриптом update-initramfs, который сложнее, но ещё осязаем. Последний запускает shell-скрипты из initramfs-tools, которые слишком сложны, полны костылей и подпорок. Если включить отладкy set -x во всех используемых системных скриптах, лог займёт около 6000 строк. Разобрать их трудно. В initramfs-tools-скриптах то и дело ссылаются на разные багрепорты и затычки, у них тяжёлая миссия – сделать так, чтобы всё правильно создавалось на бесчисленном множестве конфигураций, плохо совместимых друг с другом. Короче говоря, почему так происходит, и в чём логика – я не понял, но факт налицо: если вы посмотрите crypttab и сравните его с создаваемым на initramfs файлом cryptroot (который фактически есть переписанный crypttab с чуть другим синтаксисом), то увидите, что системный раздел (соответствующий ему маппинг) всегда идёт дополнительно первой строкой, т.е. указывается дважды.


Парсинг cryptroot (можно включить в grub отладку – опцию debug для ядра – и тогда в /run/initramfs/initramfs.debug появится лог, котрый в initramfs-шелле можно прочитать) прост до безобразия: он проверяет каждую строку последовательно, с первой по последнюю. Если предыдущий маппинг создать не удалось, дальнейшие строки cryptroot-файла не проверяются вообще. В бессигнатурном LVM-диске или более сложных конфигурациях первый маппинг – это никогда не маппинг раздела с корневой файловой системой, но подключать маппинги он начинает именно с него. Естественно, ничего не выходит, и по таймауту (который отключаем через rootdelay) он вываливается в initramfs-шелл.


Фикс элементарен – нужно, чтобы маппинг корневого раздела, зацепляемого через fstab на /, не указывался дважды, первый раз из которых – первой строкой. Достаточно удалить первую строку. Можно попробовать вручную: распаковываете initramfs (cd dir; gunzip -c /boot/IMAGE | cpio -id), убираете первую строку в cryptroot, запаковываете снова и пишете на флешку (find . | cpio -H newc -o | gzip -9 > /boot/IMAGE). При загрузке rootdelay стоит указать секунд 7-10, потому что диски он детектит не моментально, и если не успеет, вывалится в initramfs-шелл. Если успевает продетектить, пароль на вшешний слой и на все последующие запрашиваются автоматически, и если он введён неправильно, то будет перезапрошен (можете поиграться с параметрами crypttab, опция check).


Есть вопрос, можно ли сделать проще. Как я понял логику скриптов, crypptab переписывается в cryptroot, но ещё дополнительно проверяется fstab, и нужный для него маппинг для корневой файловой системы дополнительно записывается в cryptroot первой строкой.


Если закомментировать строку /etc/crypttab для rootfs, загрузка виснет, пароль не запрашивается. Если закомментировать rootfs-строку в /etc/fstab, лишней строки в cryptroot не будет, система загрузится, но корневая система не будет проверена fsck во время старта системы. Если закомментировать rootfs в /etc/fstab только временно (на момент апдейта системы и выполнения initramfs-update), roots будет проверена fsck, но не сразу и не в том месте, где ожидают этого загрузочные скрипты, т.е. будут писаться предупреждения типа "no such device". Короче, патчить руками initramfs – самый надёжный и простой способ. Стоило бы написать баг-репорт.


Что касается темы топика "Маскировка ввода пароля в cryptsetup", в initramfs-tools-скриптах не трудно найти строки, ответственные за вывод и запрос пароля, их можно поменять на любые свои, но большого смысла в этом не вижу.



Такой способ тоже работает. Чтобы закидывать файл в initramfs, нужно написать отдельный хук как здесь или выполнять свой кастомный скрипт, который перепакует initramfs вручную с нужным хидер-файлом и путём к нему в cryptroot. Системный crypttab в этом случае можно не трогать. Отрицаемость загрузочного носителя с хидерами будет хуже, чем без них – если никакие специфические параметры дисков не указываются в скриптах принудительно, пароль будет запрошен на любой диск, который опознан как, например, /dev/sda, но правильный пароль от неправильного всегда будет отличим: ошибки "неверный пароль на LUKS" и "не обнаружена файловая система или иные сигнатуры на диске, открытом с помощью такого хидера" – разные. Плюсом является то, что все пароли, включая самый внешний пароль на диск, в такой конфигурации сменяемые. Казалось бы, проблему потери отрицамеости можно решить шифрованием самого grub, но это только кажется.


Действительно, есть широко распиаренное мнение (но очень мало хауту под такой случай), что /boot теперь тоже можно шифровать. Однако, это означает не то, что раздел /boot на загрузочном носителе теперь будет дополнительно шифроваться cryptsetup-ом, а то, что /boot можно вернуть на шифрованную корневую файловую систему, и grub сам запросит пароль на эту ФС. Но как он запросит этот пароль, если нужные хидеры тоже находятся там внутри? А если не внутри, то в чём смысл? Юзеру всё равно, кто запросит пароль на диски и корневые ФС: grub или initramfs. Наверно, гипотетически, можно сделать трёхступенчатую систему загрузки: сначала grub запрашивает пароль для plain mode, чтобы подцепить бессигнатурный /boot откуда-то, а потом из /boot грузится initramfs и цепляет всё остальное, как раньше. Количество вводимых паролей увеличится, сложность конфигурации сильно увеличится, а преимущества не так велики по сравнению со случаем, когда хидеров нет вообще. Вероятно, я ошибаюсь, но пока не вижу простых выходов, как улучшить схему за счёт шифрования в grub.

— Гость_ (19/09/2017 14:40, исправлен 19/09/2017 14:53)   профиль/связь   <#>
комментариев: 450   документов: 10   редакций: 13

Нет. Можно и так и так. Нешифрованным будет каталог grub. Шифрованным – весь остальной boot с initramfs и ядрами. Меню граба будет выведено без пароля. Пароль будет запршен позже при попытке открыть раздел, указанный в конфигурации выбранной строки в граб-меню. На уровне хауту это описано в хакере (Способ там формально рабочий, но кривой, потому что нужно руками вносить опции в конфиг граба. update-grub нужные опции перезапишет при первом же обновлении. Правильно – писать свои хуки с кодогенератором конфига, которые будут читаться при каждом update-grub).



Стандартный grub поддерживает часть функционала cryptsetup (LUKS) через собственные модули. Там нет полной совместимости. Нельзя указать хидер для LUKS и нельзя использовать plain mode – только обычное LUKS-устройство с встроенным хидером. Некоторые предлагают ступенчатую загрузку, когда один grub грузит другой grub с шифрованного раздела, но смысл затеи непонятен.


Есть проект grub-DeLUKS, который устраняет эти недостатки, но в апстрим его не приняли. Если его установить, выйдет, что загрузчик использует специальный софт для отрицаемости, и эта отрицаемость потеряется. Аналогичная история с обычным cryptsetup – cryptsetup-DeLUKS.

— Yellow (25/01/2018 21:45)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4
Будьте добры, нужна помощь. Боюсь расковырять все до полностью нерабочего состояния.

Схема системы: раздел /boot на флешке, вся остальная система лежит на бессигнатурно шифрованном харде, после бута отмонтировывается /boot и флешка затирается.

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

Думается, что после очередного обновления я забыл записать новое содержимое флешки на отдельный носитель. Поэтому на нем осталось старое старое содержимое. И когда я записал его на флешку для очередного запуска системы, система нормально запустилась, но перестала читать ФС одного из дисков, который используется под свалку устаревших пользовательских данных. Этот диск я всегда расшифровывал и монтировал вручную. А теперь, при попытке примонтирования, ОС говорит, что не может найти ФС данного диска. Причем, с этим диском все абсолютно ОК, я тщательно проверял из-под лайва.

Как безопасно убедиться, что мое предположение правильно, и как исправить эту фигню?
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3