Маскировка ввода пароля в cryptsetup
Форумчане, скажите, можно ли сделать в Crytpsetup затирание вывода консоли при вводе пароля на загрузку?
Как в TrueCrypt – фейковая ошибка, например "Invalid BOOT.INI file Booting from C:windows", таким образом ввести в заблуждение по поводу установленной системы и не реагировать на ввод неправильных паролей.
Спасибо
Ага, этот терабайт данных копился лет 10, а потом «взять и за сутки скачать». Кстати, мало какой провайдер позволит на максимальной скорости выкачивать такие объёмы данных. И качать вы будете, боюсь, неделю или месяц.
Там хитрее было, но пусть unknown выскажется, мне сейчас будет трудно найти тот его пост.
комментариев: 1079 документов: 58 редакций: 59
Повторюсь, я даже гипотетически не могу представить скачку подобного объема данных. Ну пусть неделя, с нескольких компом, децентрализовано, с разбивкой на 100Гб, потом склеить. Не знаю, на сколько это технически выполнимо. Но если действительно невыполнимо – то конечно только провозить. А здесь у меня тоже возникал вопрос по поводу скрытой операционной системы и ее реализации. То есть попросят показать – ну показывайте "нужную" ОСь, а в разделе будут данные. И, на сколько я понимаю – никто не поймет, что это криптоконтейнер.
комментариев: 9796 документов: 488 редакций: 5664
Слушайте, ну дурь же. У меня месячный трафик до 50GB не дотянет. Не каждый ISP это позволит + очень долго + много гемороя + неудобно + это не вопрос жизни и смерти.
Это "бессигнатурка-хэви" [1], [2], [3], её намного тяжелее сделать чем то, что вы хотите здесь как топикстартер. Во-первых, там надо будет играться с Xen-ядром, а не просто с cryptroot, во-вторых, настроить гостевые системы, в-третьих, делать БД для dmsetup, в четвёртых, скрипты для автоматизации всего процесса.
комментариев: 9796 документов: 488 редакций: 5664
/comment81977
Доведите до ума по максимуму сначала сами, чтобы исключить упование на obscurity, затем публикуйте, если считаете, что это стоит того. Может удасться толково перевести на английский и протолкнуть идею в мэйнстрим Debian.
я так понимаю все завязано на initramfs?
Ну предположим так?
добавляем что то вроде
и
у генты свое поделие
Или просто монтируем как диск предварительно загрузившись в LiveCD/USB ставим тутда что нам надо в загрузчике прописываем что вроде этого
Или вводим вручную чтобы не палить UUID.
Примерную модель я правильно представил?
Можно еще и initramfs пересобрать и это все описано, дальше только полет фантазии...
Но суть то думаю ясна?
[/fix]
комментариев: 9796 документов: 488 редакций: 5664
UUID надо помнить наизусть что-ли? Или диск состоит не из чистого рэндома, как будто его целиком стёрли, а на нём какие-то тома с уидами торчат?
crypt_root=/dev/sda2 /dev/mapper/root
комментариев: 9796 документов: 488 редакций: 5664
На встроенные стандартные функции/скрипты initrd, если быть точнее.
Не надо там ничего специально модифицировать, это приведёт к палеву.
Можно и так, но это более трудоёмкий способ, чем воспользоваться инсталляционном диском и сразу сделать, как надо. Естественно, у нас тоже с него начинали. Примерная последовательность действий была (все тесты на Debian):
- Ставим Debian штатно как есть с криптами и т.д. на посторонний диск.
- Грузимся с постороннего диска, создаём нужный initrd, пишем его на CD-диск или ещё куда там надо (флэшка, например, — зависит от того, с чего планируете грузиться).
- Затираем целевой диск, после чего он превращается в
- Устанавливаем Debian на бессигнатурный диск: после загрузки инсталляционного диска дропаемся в шелл, создаём plain mode раздел размером на весь диск, внутри него можем создать ещё один LUKS-раздел на весь диск, который, в свою очередь, разбить на LVM-тома (которые также могут быть шифрованными или нет); после создания нужных устройств, они будут распознаны и подцеплены инсталлятором автоматически.
- Грузимся с CD с записанного initrd, в загрузчике указываем опции типа cryptopts="cipher=... hash=... size=... source=... target=...".
Предварительная установка требовалась, чтобы создать правильный initrd. Квест был пройден.тыквудиск без разделов и без сигнатур.Кроме того, ваши команды с хидером LUKS'а плохи для внешнего уровня шифрования. Мы исходим из того, что у юзера на руках не должно быть носителей с подозрительными файлами, которые должны остаться в тайне, а раз так, где вы собираетесь хранить хидеры LUKS'а? Если на том же диске через выделенную посредством device mapper область пространства, то чем вы её будете шифровать? Всё равно на каком-то уровне у вас должен быть конец ниточки, потянув за который, всё распутывается, и этот конец не должен требовать ничего кроме знания конкретных команд и пароля. Короче, я не вижу смысла в хидерах или ключевых файлах на самом внешнем шифровании.
Указывать UID'ы не требуется.
Можно, но палево будет меньше, если использовать стандартный.
OMG, я сказал, на диске нет разделов! Диск забит случайными данными.
Итак, примерная модель:
Бессигнатурка-лайт
Информации указано с избытком, на случай про запас (не всё из этого нужно знать для создания «решения», но это может оказаться полезным). Текст плохо структурирован, возможны повторения и взаимосиключающие параграфы, но для понимания общих идей этого достаточно. Это не готовая инструкция — пока что это скорее памятка с фактами для тех, кто пытается что-то аналогичное сделать самостоятельно. Общий дисклеймер — берегите мозг.
Оглавление
B. Вариант с однопроходным решением
C. Вариант с двупроходным решением
D. Загрузка с флэшки как есть
E. Загрузка с флэшки с указанием опций загрузчику на лету
Факты о загрузчиках
Все 3 загрузчика умеют грузить ядро с произвольно введенными с ком. строки опциями ⇒ grub* не необходим. В инсталляторе Debian'а предлагается выбор между grub2 и lilo, но никто не мешает потом сделать загрузчик на isolinux/syslinux. Ниже пойдёт речь исключительно о Debian, хотя это не принципиально.
Эксперимент
Инсталляция
Для первого эксперимента воспользуемся lilo (в перспективе syslinux предпочтительнее; к тому же, lilo с сидюками не дружит). Тестовая система — QEMU с KVM, загрузчик будем ставить на реальную внешнюю флэшку, которая также «подмонтирована» к виртуалке. Последовательность действий:
Однако, в нашей схеме в crypttab'е ничего нету, поэтому он просто выдает варнинги.Соответственно, initrd у нас теперь вообще ничего не знает про наш криптораздел, хотя инструменты для его подключения есть.Опции из crypttab нужны только для разделов с plain dm-crypt, а если у нас LUKS, никаких опций в initrd не будет, т.к. они сидят в самом хидере LUKS-раздела(при генерации initrd хук cryptsetup'а прописывает туда опции cryptsetup'а для всех разделов, где не LUKS, а берёт он эти опции из crypttab). 100%-гарантию дать трудно (для этого надо все скрипты просмотреть), но вроде все конфиги пишутся в conf.d внутри initrd. Содержимое можно посмотреть, распаковав initrd:Вариант с однопроходным решением
Решение в том, как на стадии инсталляции закатать на CD-диск isolinux. При Debian netinstall, конечно, всегда можно дропнуться в rescue shell, сделать chroot и по сети подгрузить/установить любой пакет (apt-get install). В этом варианте, очевидно, загрузчик в инсталляторе лучше не выбирать.
Вариант с двупроходным решением
В двухпроходном варианте сначала Debian ставится штатным образом на посторонний диск (с LUKS или plain mode). Если там LUKS, то можно сразу после его загрузки установить isolinux с тулзами для CD и записать. Если использовалась plain mode, то надо после загрузки поставить cryptsetup — это сгенерит подходящий initrd, и далее задача сведена к предыдущей. Т.е., самый важный факт в том, что для сборки подходящего initrd необходимо и достаточно наличия в системе установленного cryptsetup. Ну, или возвращаемся к однопроходному варианту, где вместо записи CD-диска в конце достаточно иметь под рукой болванку с Debian rescue Live CD той же версии, а загрузчик вовсе не ставить в инсталляторе.
Загрузка с флэшки как есть
Загрузка с флэшки с указанием опций загрузчику на лету
Указываем lilo при загрузке опции:
Значение опции lvm — название lvm без полного пути, т.е., если в системе есть /dev/vg/root, то надо указать lvm=vg-root (синтакисис: имя_VG-имя_LV). Короче, в lvm надо указать после «=» ту часть пути, которая после /dev/mapper/ [восстановить правильный вариант мысли не удалось].Мысли и вопросы общего характера
Впрочем, как оно будет дружить с обновлениями, и не рассинхронизируется ли однажды (после обновлений) совместимость — это вопрос. Самому apt-get'у на всю эту внутреннюю кухню пофиг, но на это реагируют всякие postinst-триггеры от определенных пакетов, так что при реконфигурации загрузчика могут начаться нюансы. В частности, хуком на kernel-postinst стоит переустановка lilo (в нашем тестовом случае там указано, что mbr надо пихать на реальную подмонтированную флэшку, но если её не будет, lilo просто поругается [впрочем, это можно проверить]). Можно играться с фиктивным boot'ом, но он должен будет очень сильно смахивать на натуральный: т.е. должно быть псевдоустройство, куда lilo сможет лезть (например, файл, подключенный через loop), а просто /boot как часть корневой ФС ничего не даст (подмонтированного /boot для хранения конфигов будет недостаточно). Грубо говоря, в lilo.conf прописано битым текстом «mbr писать на такое-то устройство».
комментариев: 9796 документов: 488 редакций: 5664
Можно использовать два диска. На одном открытая система для игры в пасьсянс. На другом шифрованная рабочая. Какую запускать --указывается параметрами при загрузке.
А так, как я и представлял: совсем уж чуда не будет. Слишком большой шанс в ответственный момент получить апдейт в систему, после которого поломается и будет не загрузиться. Ну т.е. откатываясь и проделывая массу ручных операций, всё конечно можно разрулить и пофиксить, но это всё такой «закат солнца вручную», которого хотелось бы избежать.
Ну а что вы хотите? Это ж пока совсем пре- пре- для лайта. Всё начинается с демонстрации принципа работы, с тестовых систем. Только потом идёт автоматизация, оптимизация и упрощение.
Апдейты можно тоже рассмотреть, оттестировать и включить в модель, но пока не до того.