id: Гость   вход   регистрация
текущее время 23:38 28/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 След.
Комментарии
— Гость (30/07/2014 13:14)   <#>

Ага, этот терабайт данных копился лет 10, а потом «взять и за сутки скачать». Кстати, мало какой провайдер позволит на максимальной скорости выкачивать такие объёмы данных. И качать вы будете, боюсь, неделю или месяц.


Там хитрее было, но пусть unknown выскажется, мне сейчас будет трудно найти тот его пост.
— ressa (30/07/2014 13:45)   профиль/связь   <#>
комментариев: 1079   документов: 58   редакций: 59
«взять и за сутки скачать»

Повторюсь, я даже гипотетически не могу представить скачку подобного объема данных. Ну пусть неделя, с нескольких компом, децентрализовано, с разбивкой на 100Гб, потом склеить. Не знаю, на сколько это технически выполнимо. Но если действительно невыполнимо – то конечно только провозить. А здесь у меня тоже возникал вопрос по поводу скрытой операционной системы и ее реализации. То есть попросят показать – ну показывайте "нужную" ОСь, а в разделе будут данные. И, на сколько я понимаю – никто не поймет, что это криптоконтейнер.
— unknown (30/07/2014 13:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
/comment76322.
— Гость (31/07/2014 23:27)   <#>

Слушайте, ну дурь же. У меня месячный трафик до 50GB не дотянет. Не каждый ISP это позволит + очень долго + много гемороя + неудобно + это не вопрос жизни и смерти.


Это "бессигнатурка-хэви" [1], [2], [3], её намного тяжелее сделать чем то, что вы хотите здесь как топикстартер. Во-первых, там надо будет играться с Xen-ядром, а не просто с cryptroot, во-вторых, настроить гостевые системы, в-третьих, делать БД для dmsetup, в четвёртых, скрипты для автоматизации всего процесса.
— unknown (01/08/2014 10:00, исправлен 01/08/2014 10:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

/comment81977


Доведите до ума по максимуму сначала сами, чтобы исключить упование на obscurity, затем публикуйте, если считаете, что это стоит того. Может удасться толково перевести на английский и протолкнуть идею в мэйнстрим Debian.

— Гость (01/08/2014 14:49)   <#>

я так понимаю все завязано на initramfs?
Ну предположим так?
добавляем что то вроде
и
у генты свое поделие
Или просто монтируем как диск предварительно загрузившись в LiveCD/USB ставим тутда что нам надо в загрузчике прописываем что вроде этого


Или вводим вручную чтобы не палить UUID.
Примерную модель я правильно представил?
Можно еще и initramfs пересобрать и это все описано, дальше только полет фантазии...
— Гость (01/08/2014 14:53)   <#>
[fix]
Но суть то думаю ясна?

[/fix]
— unknown (01/08/2014 15:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

UUID надо помнить наизусть что-ли? Или диск состоит не из чистого рэндома, как будто его целиком стёрли, а на нём какие-то тома с уидами торчат?
— Гость (01/08/2014 15:57)   <#>

crypt_root=/dev/sda2 /dev/mapper/root
— unknown (01/08/2014 16:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Понятно. Внутри sda2 м.б. физический том и все логические сами распознаются если надо, когда он откроется паролем. Только при перепаковке рамдиска автоматом при обновлениях логические уиды из sda2 могут в него утечь и остаться запакованными, если я не путаю.
— Гость (01/08/2014 17:28)   <#>
все зависит от того как это пересобираться
— Гость (04/08/2014 06:30)   <#>

На встроенные стандартные функции/скрипты initrd, если быть точнее.


Не надо там ничего специально модифицировать, это приведёт к палеву.


Можно и так, но это более трудоёмкий способ, чем воспользоваться инсталляционном диском и сразу сделать, как надо. Естественно, у нас тоже с него начинали. Примерная последовательность действий была (все тесты на Debian):
  1. Ставим Debian штатно как есть с криптами и т.д. на посторонний диск.
  2. Грузимся с постороннего диска, создаём нужный initrd, пишем его на CD-диск или ещё куда там надо (флэшка, например, — зависит от того, с чего планируете грузиться).
  3. Затираем целевой диск, после чего он превращается в тыкву диск без разделов и без сигнатур.
  4. Устанавливаем Debian на бессигнатурный диск: после загрузки инсталляционного диска дропаемся в шелл, создаём plain mode раздел размером на весь диск, внутри него можем создать ещё один LUKS-раздел на весь диск, который, в свою очередь, разбить на LVM-тома (которые также могут быть шифрованными или нет); после создания нужных устройств, они будут распознаны и подцеплены инсталлятором автоматически.
  5. Грузимся с CD с записанного initrd, в загрузчике указываем опции типа cryptopts="cipher=... hash=... size=... source=... target=...".
Предварительная установка требовалась, чтобы создать правильный initrd. Квест был пройден.

Кроме того, ваши команды с хидером LUKS'а плохи для внешнего уровня шифрования. Мы исходим из того, что у юзера на руках не должно быть носителей с подозрительными файлами, которые должны остаться в тайне, а раз так, где вы собираетесь хранить хидеры LUKS'а? Если на том же диске через выделенную посредством device mapper область пространства, то чем вы её будете шифровать? Всё равно на каком-то уровне у вас должен быть конец ниточки, потянув за который, всё распутывается, и этот конец не должен требовать ничего кроме знания конкретных команд и пароля. Короче, я не вижу смысла в хидерах или ключевых файлах на самом внешнем шифровании.


Указывать UID'ы не требуется.


Можно, но палево будет меньше, если использовать стандартный.


OMG, я сказал, на диске нет разделов! Диск забит случайными данными.
— Гость (04/08/2014 10:02)   <#>

Итак, примерная модель:


Бессигнатурка-лайт


Информации указано с избытком, на случай про запас (не всё из этого нужно знать для создания «решения», но это может оказаться полезным). Текст плохо структурирован, возможны повторения и взаимосиключающие параграфы, но для понимания общих идей этого достаточно. Это не готовая инструкция — пока что это скорее памятка с фактами для тех, кто пытается что-то аналогичное сделать самостоятельно. Общий дисклеймер — берегите мозг.

Оглавление


  1. Факты о загрузчиках
  2. Эксперимент
  3. Мысли и вопросы общего характера

Факты о загрузчиках


  1. grub (deprecated) и grub2 (трахотень) — это без комментариев.

  1. lilo — классика, но всё ещё живая и поддерживаемая. Прост в настройке, но требуется реинсталляция на каждое изменение конфигурации. Дружит с любой ФС, в принципе, но с FAT его вроде не используют особо...

  1. Семейство syslinux: isolinux ставится на CD, syslinux — на FAT, extlinux — на ext*. Загрузчики просты настройке, не требуется реинсталляция при смене конфига [если из текстового редактора на другой системе поменять конфиг, то lilo работать не будет, а syslinux (и все его разновидности) будут].

Все 3 загрузчика умеют грузить ядро с произвольно введенными с ком. строки опциями ⇒ grub* не необходим. В инсталляторе Debian'а предлагается выбор между grub2 и lilo, но никто не мешает потом сделать загрузчик на isolinux/syslinux. Ниже пойдёт речь исключительно о Debian, хотя это не принципиально.

Эксперимент

Инсталляция


Для первого эксперимента воспользуемся lilo (в перспективе syslinux предпочтительнее; к тому же, lilo с сидюками не дружит). Тестовая система — QEMU с KVM, загрузчик будем ставить на реальную внешнюю флэшку, которая также «подмонтирована» к виртуалке. Последовательность действий:

  1. Грузим инсталлер в expert mode.

  1. Когда инсталлер предлагает свои компоненты, обязательно выбрать rescue shell и криптомодули.

  1. Перед детектом дисков (в меню есть такой пункт) переключаемся в rescue shell, создаем привязку без LUKS — что-то типа:
    # cryptsetup --use-random -c aes-xts-plain64 -s 512 -h sha512 \
    create PRIVYAZKA /dev/sda
    LVM делать руками в rescue shell не надо — интерфейс инсталлятора Debian'а прекрасно сам с этим справится.

  1. Дальше Debian увидит криптораздел (/dev/mapper/PRIVYAZKA) и исходный (/dev/sda). На исходный лезть не надо, а на крипторазделе создаём таблицу разделов вида loop (этот вариант соответствует случаю «нет никакой таблицы, т.е. таблица разделов на устройстве не нужна»; ничего не выбирать в инсталляторе нельзя — он требует какой-то вариант).

  1. Через инсталлятор на крипторазделе создаём физ. тома для LVM и идём далее по стандартной схеме конфигурации. Короче, всё это делается юзер-френдли, кроме самого первого вызова cryptsetup.

  1. Если делать таким макаром, то Debian не догадывается, что нужно поставить cryptsetup. Следовательно, в initrd его не будет. Чтобы такого не вышло, надо перед finish install зайти в консоль и сделать следующее:
    # chroot /target
    (это переключение в поставленную FS)
    # apt-get install cryptsetup
    Т.е. того, что мы выбрали crypto tools на самой первой стадии, ему недостаточно. Итак, после этого initrd само перегенерится и запишется куда надо (поэтому boot во время инсталляции тоже должен быть подмонтирован куда надо — на ту самую подмонтированную флэшку, см. выше).

  1. initrd генерится с использованием хуков cryptsetup. Логика у него, видимо, такая: проверяется /etc/crypttab на предмет наличия криптораздела (ему хочется записать дефолтные опции cryptsetup'а для раздела в initrd). Однако, в нашей схеме в crypttab'е ничего нету, поэтому он просто выдает варнинги. Соответственно, initrd у нас теперь вообще ничего не знает про наш криптораздел, хотя инструменты для его подключения есть. Опции из crypttab нужны только для разделов с plain dm-crypt, а если у нас LUKS, никаких опций в initrd не будет, т.к. они сидят в самом хидере LUKS-раздела (при генерации initrd хук cryptsetup'а прописывает туда опции cryptsetup'а для всех разделов, где не LUKS, а берёт он эти опции из crypttab). 100%-гарантию дать трудно (для этого надо все скрипты просмотреть), но вроде все конфиги пишутся в conf.d внутри initrd. Содержимое можно посмотреть, распаковав initrd:
    # mkdir some_dir; cd some_dir; zcat /boot/initrd_... | cpio -ivd
    (смотрим в файл conf/conf.d и в resume в conf.d). Чтобы ничего лишнего не утекало в initrd (могут утечь, в том числе, UUID'ы), нужно: не включать своп (в обсуждавшемся варианте в resume может утекать имя логического тома со свопом, хоть и без UUID'а, типа RESUME=/dev/mapper/vg-swap). Итог: если делать вариант plain mode → LVM, и без свопа, то initrd будет чистым. В общем, включается ли cryptsetup+скрипты в initrd, определяется только одним — стоит ли пакет cryptsetup, а стоит ли пакет — зависит от того, включили ли мы криптотома в Debian'овском инсталляторе. Поскольку мы всё делали вручную, то по дефолту он не стоит.

  1. В результате экспериментов initrd выходит совершенно штатный, но вот сам набор файлов на диске — нет [будет видно, что его изменяли спецом(?)]. Может быть вариант, что по отсутствию опций можно будет догадаться, что использовалась нестандартная схема шифрования (по отсутствию опций и наличию cryptsetup'а). Впрочем, не сказать, что это уж так нестандартно: достаточно иметь нешифрованный корень и cryptsetup в какой-то обычной системе при обычной инсталляции (к примеру, он может быть нужен для где-то имеющегося шифрованного /home/ — возможно, даже на ином диске) — для такой конфигурации initrd получился бы ровно таким, как у нас сейчас.

  1. Диск с загрузчиком без параметра root тоже очень подозрительный — лучше указывать обманку «root=...». Это касается собственных загрузчиков. Что же касается штатных, то в типичных Live CD и в Rescue CD используются другие initrd (в них просто тупо написано root=root-fs, и всё). Короче, статикой можно зашить root=/dev/sda1 — достаточно того, чтобы при загрузке можно было стереть/переписать эту опцию. Кстати, параметр root надо указывать (не обязательно статически) при загрузке в любом случае — параметра lvm недостаточно. Если грузимся с сидюка, то там, как правило, будет isolinux, и его можно легко редактировать.

  1. Тут есть ещё один нюанс: lilo передает ядру параметр root=путь_к_lvm_тому_с_рутом, что тоже утечка), но никто не мешает поправить lilo.conf и перезаписать lilo так, чтобы root руками указывался при загрузке. Впрочем, в перспективе весь этот носитель с lilo не нужен, а в новом загрузчике можно в конфиге прописывать всё, что угодно (или ничего). Вообще, lilo хорош тем, что там все проблемы правятся в одну строчку и с предсказуемыми результатами (это так во всех олдовых загрузчиках и даже, кажиесь, в grub1).

  1. lilo очень умный — параметры дописывать умеет при загрузке, а отрезать — нет. Впрочем, если в командной строке загрузчика указать несколько опций root=..., то будет использована последняя. Таким образом, схема с «root=обманка» будет работать и с lilo — просто надо будет еще один root=... указать, который перекроет исходный.

  1. isolinux плотно не тестировался.

  1. Загрузка со штатного Debian rescue CD ещё не тестировалась, но поидее (в силу озвученных в тексте аргументов) должна работать.

Вариант с однопроходным решением


Решение в том, как на стадии инсталляции закатать на 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 той же версии, а загрузчик вовсе не ставить в инсталляторе.

Загрузка с флэшки как есть


  1. Если загрузчику не указываем никаких опций, он ругается на то, что root fs не найдена, и вываливается шелл (запуск шелла, если root fs не обнаружена — абсолютно штатное поведение).

  1. В шелле руками подключаем криптораздел, запускаем LVM и активируем тома (из всех LVM-тулзов в initrd присутствует только сам lvm, поэтому запускаем команду lvm и оттуда подаем команды типа vgscan и lvchange).

  1. Выходим из шелла, после чего загрузка идёт штатным образом. Простейший квест пройден.

Загрузка с флэшки с указанием опций загрузчику на лету


Указываем lilo при загрузке опции:
cryptopts=source=/dev/sda,cipher=...,hash=..,size=...,lvm=1
и всё работает. Главное — обязательно указать lvm, иначе не взлетит. Система загружается штатно, пассфраза запрашивается. Значение опции lvm — название lvm без полного пути, т.е., если в системе есть /dev/vg/root, то надо указать lvm=vg-root (синтакисис: имя_VG-имя_LV). Короче, в lvm надо указать после «=» ту часть пути, которая после /dev/mapper/ [восстановить правильный вариант мысли не удалось].

Мысли и вопросы общего характера


  1. Надо ли делать plain mode → LUKS → LVM, или достаточно plain mode → LVM? Пароль на plain mode будет несменяемый, зато пароль для LUKS можно всегда сменить, поэтому, если первый в неудачный момент утекёт атакующему, максимум, что потеряем — отрицаемость (атакующий доберётся до внутреннего LUKS-раздела на весь диск, но не сможет его открыть). С другой стороны, LUKS-хидер критичен к bad block'ам, поэтому желательно сделать его бэкап и где-то хранить, но где, если весь диск им зашифрован? Только на ином диске с аналогичной системой шифрования. Возможно, такие трудности того не стоят? В любом случае, внутри всё равно будет LVM, и каждый LVM-раздел при надобности можно дополнительно пошифровать LUKS'ом.

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

  1. Минимальные требования к загрузочному носителю: нам даже iso'шка не нужна, достаточно иметь копию boot-раздела на ФС и любой вменяемый загрузчик (в смысле поставленного пакета) [lilo, extlinux/syslinux/isolinux (если болванку не жалко) и даже grub (если не лень)] на Live CD/USB. Заметим, что в Debian rescue Live CD есть и lilo и syslinux, и даже grub1. В Debian'е стабле ядра меняются редко, и может быть такое счастье, что версия ядра+initrd на Debian rescue livecd (штатная штука, предоставляется на сайте официально) подойдет для нашей системы.

    Впрочем, как оно будет дружить с обновлениями, и не рассинхронизируется ли однажды (после обновлений) совместимость — это вопрос. Самому apt-get'у на всю эту внутреннюю кухню пофиг, но на это реагируют всякие postinst-триггеры от определенных пакетов, так что при реконфигурации загрузчика могут начаться нюансы. В частности, хуком на kernel-postinst стоит переустановка lilo (в нашем тестовом случае там указано, что mbr надо пихать на реальную подмонтированную флэшку, но если её не будет, lilo просто поругается [впрочем, это можно проверить]). Можно играться с фиктивным boot'ом, но он должен будет очень сильно смахивать на натуральный: т.е. должно быть псевдоустройство, куда lilo сможет лезть (например, файл, подключенный через loop), а просто /boot как часть корневой ФС ничего не даст (подмонтированного /boot для хранения конфигов будет недостаточно). Грубо говоря, в lilo.conf прописано битым текстом «mbr писать на такое-то устройство».

  1. Использование lilo в XXI-ом веке уже само по себе подозрительно — isolinux на CD смотрится куда естественнее.
— unknown (04/08/2014 10:36)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
isolinux вполне органично смотрится на usb-флэшках, т.е. он, а принципе ставится не только на CD. Его чаще исользуют, чем syslinux, т.к. у него больше всяких фич, в частности в работе с рамдисками.


Можно использовать два диска. На одном открытая система для игры в пасьсянс. На другом шифрованная рабочая. Какую запускать --указывается параметрами при загрузке.

А так, как я и представлял: совсем уж чуда не будет. Слишком большой шанс в ответственный момент получить апдейт в систему, после которого поломается и будет не загрузиться. Ну т.е. откатываясь и проделывая массу ручных операций, всё конечно можно разрулить и пофиксить, но это всё такой «закат солнца вручную», которого хотелось бы избежать.
— Гость (04/08/2014 11:04)   <#>

Ну а что вы хотите? Это ж пока совсем пре- пре- для лайта. Всё начинается с демонстрации принципа работы, с тестовых систем. Только потом идёт автоматизация, оптимизация и упрощение.


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