Маскировка ввода пароля в cryptsetup
Форумчане, скажите, можно ли сделать в Crytpsetup затирание вывода консоли при вводе пароля на загрузку?
Как в TrueCrypt – фейковая ошибка, например "Invalid BOOT.INI file Booting from C:windows", таким образом ввести в заблуждение по поводу установленной системы и не реагировать на ввод неправильных паролей.
Спасибо
комментариев: 64 документов: 0 редакций: 4
Прекрасно сказано! :-)
Совершенно точно.
А вообще, меня здесь пугают две собственные ошибки:
1. не была сделана пошаговая проверка
2. действие, обеспечивающее безопасность (окончательная рандомизация неразмеченной поверхности флешки, т.е. не подготовительная – перед разметкой, а окончательная – перед началом использования флешки по назначению) должно было быть сделано как последнее
Эти ошибки безопасность не затронули, поскольку, ввиду понятных причин, флешка после бута всегда затиралась полностью и дважды. Т.е. безопасность была обеспечена прямой мерой. Но сам факт, что в таких простых действиях можно жутко проколоться из-за собственной тупости, просто пугает. :-)
комментариев: 511 документов: 2 редакций: 70
Можно было короче:
Тупыми легче управлять. Выбирайте тупые программы.
Нет, вы всё правильно сделали. Не должен разметчик диска писать непонятно что непонятно куда. Возможно, это даже баг, но проверять ваши действия у меня нет ни времени, ни мотивации. Ваша ошибка только в том, что взяли вместо предсказуемого fdisk непредсказуемый Gparted.
Эти продвинутые вещи (parted) нужны для GPT-разметки. Если у вас не GPT, а стандартная MsDOS-разбивка, зачем переусложнять вещи? То, что вы проверили неизменность неразмеченного пространства — сделали правильно. Ничему на 100% доверять нельзя.
По правде сказать, я бы на вашем месте, если б использовал fdisk, даже не делал бы таких проверок, потому что сама идея, что fdisk будет писать не пойми чего в конец диска, противоречит всем моим представлениям, да и проверка неизменности неразмеченного дискового пространства для больших дисков может занять много часов.
В будущем их у вас будет ещё много, целый кладезь. Не расстраивайтесь, все через это проходили. Лучше поздно, чем никогда.
комментариев: 450 документов: 10 редакций: 13
комментариев: 64 документов: 0 редакций: 4
Была небольшая проблема.
Решение простое до безобразия. Сделать второй маппинг на том же устройстве позволяет опция --shared утилиты cryptsetup.
комментариев: 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.
комментариев: 450 документов: 10 редакций: 13
Нет. Можно и так и так. Нешифрованным будет каталог grub. Шифрованным – весь остальной boot с initramfs и ядрами. Меню граба будет выведено без пароля. Пароль будет запршен позже при попытке открыть раздел, указанный в конфигурации выбранной строки в граб-меню. На уровне хауту это описано в хакере (Способ там формально рабочий, но кривой, потому что нужно руками вносить опции в конфиг граба. update-grub нужные опции перезапишет при первом же обновлении. Правильно – писать свои хуки с кодогенератором конфига, которые будут читаться при каждом update-grub).
Стандартный grub поддерживает часть функционала cryptsetup (LUKS) через собственные модули. Там нет полной совместимости. Нельзя указать хидер для LUKS и нельзя использовать plain mode – только обычное LUKS-устройство с встроенным хидером. Некоторые предлагают ступенчатую загрузку, когда один grub грузит другой grub с шифрованного раздела, но смысл затеи непонятен.
Есть проект grub-DeLUKS, который устраняет эти недостатки, но в апстрим его не приняли. Если его установить, выйдет, что загрузчик использует специальный софт для отрицаемости, и эта отрицаемость потеряется. Аналогичная история с обычным cryptsetup – cryptsetup-DeLUKS.
комментариев: 64 документов: 0 редакций: 4
Схема системы: раздел /boot на флешке, вся остальная система лежит на бессигнатурно шифрованном харде, после бута отмонтировывается /boot и флешка затирается.
Я обновляю систему исключительно после свежего бута. Поскольку в таком состоянии не требуется предварительное подмонтирование раздела /boot. Следующим шагом является запись нового содержимого флешки на отдельный носитель и ее затирание.
Думается, что после очередного обновления я забыл записать новое содержимое флешки на отдельный носитель. Поэтому на нем осталось старое старое содержимое. И когда я записал его на флешку для очередного запуска системы, система нормально запустилась, но перестала читать ФС одного из дисков, который используется под свалку устаревших пользовательских данных. Этот диск я всегда расшифровывал и монтировал вручную. А теперь, при попытке примонтирования, ОС говорит, что не может найти ФС данного диска. Причем, с этим диском все абсолютно ОК, я тщательно проверял из-под лайва.
Как безопасно убедиться, что мое предположение правильно, и как исправить эту фигню?