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


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

Комментарии
— unknown (29/07/2014 11:48)   
Можно пересобрать рамдиск так, чтобы он обходил вызов cryptsetup при полнодисковом шифровании. Будет что-то вроде "partition not found" или «том не найден», или вообще загрузка посторонней системы. А можно вставить в скрипты рамдиска какую-то свою команду, которая бы вызывала кусок скрипта с нормальным cryptsetup только при определённых условиях — нажатии комбинации клавиш, хотя бы малоприметный read с таймаутом.

Но это чисто внешняя защита: грамотный противник, способный провести экспертизу, разберёт и рамдиск построчно, и подозрительные разделы заметит.
— ressa (29/07/2014 13:17)   
Да мне собственно внешняя защита и интересна. Так сказать "от дурака". Зачастую в моей модели угрозы нет никаких спецов, кроме продажных студентов "Юго-Запада Москвы".. Если m0fx64 в своем AcodeMorse реализует – посмотрю готовый вариант. Я так понял, если ты говоришь о плясках с ramdisk, то упомянутый мной TrueCrytp не в тему, потому, что он эту опцию видимо только на винде и поддерживал..(
А постороннюю систему загружать – это в духе:

В общем смысла, если правде в глаза смотреть, с этой "внешней" защиты – как с козла молока, правильно я понял?
А как еще можно сделать скрытую OS, кроме средств TrueCrypt? Ну т.е. тупо написать скрипт, который будет дешифровывать криптоконтейнер, распаковывать к примеру тот же AcodeMorse, подгружать его в виртуалку и после работы – обратно упаковывать?
— Гость (29/07/2014 17:15)   

Да, можно, но я не готов сейчас об этом говорить. Идея в том, что вы можете указать опции загрузки ядру на лету (в загрузчике). Вы также можете грузиться с бессигнатурно шифрованного диска (нужен только загрузчик; рекомендуется lilo или syslinux). Вы можете даже сразу установить на бессигнатурно шифрованный диск Debian, прям во время инсталла создать дополнительный нейтральный iso или образ для флэшки и сразу начать грузиться, как надо. Также можно грузиться с нейтрального LiveCD или LiveUSB.

Всё это уже оттестировано и работает, но, повторюсь, я не готов сейчас об этом говорить. Как я понял, есть скрипт cryptroot в рамдиске, он очень умный, ему можно подсовывать даже те шифрованные cryptsetup'ом разделы, которые в plain mode. Ядру надо будет указать что-то типа cryptopts="cipher=... hash=... size=... source=... target=...". Конечно, там не так всё просто, и если сейчас начинать это описывать, нужно создавать огромный документ с объяснением матчасти, внутренней кухни рамдиска и его создания, а также всех подводных камней... Если что, в самом рамдиске не будет ничего такого, что напрямую указывало бы на "специальность задач, для которых его используют".

P.S. Unknown'а не слушайте, в данном случае он просто не в теме. :-)
— unknown (29/07/2014 17:27)   

Согласен, я не любитель таких извратов.
В принципе конечно можно каждый раз в GRUB входить и редактировать по памяти, что передавать ядру, и для cryptsetup помнить все режимы, оффсеты и пр. Если это у кого-то отлажено, работает и удобно организовано, то я рад, но действительно не в теме :)
— ressa (29/07/2014 18:24)   
Гость (29/07/2014 17:15), супер! Это то, что нужно. Правда для меня пока не подъемно. Буду по мере возможности изучать.
— Гость (29/07/2014 20:40)   

Да, как-то так. Там не много команд, достаточно указывать опции каждый раз, и всё.


Да, в рамках рабочей группы я проинформирован, что решение уже есть и работает. У меня есть большая часть сырого материала, но готовых инструкций пока нет.

Перые методики шли с вываливанием в single mode, откуда вы цепляете plain mode шифрование и LVM внутри него, а потом переходите в многопользовательский режим, и всё ОК. Позже было оттестирован способ с указанием опций ядру на лету. Ещё позже — тестирование разных загрузочных медиа, как стандартных, так и специально созданных. Наконец, последний шаг — как это сделать сразу при установке Debian: установить его на бессигнатурный полностью шифрованный диск и заодно тут же приготовить загрузочный диск/USB. Этот квест тоже был пройден. Может быть, есть ещё какие-то подводные непройденные камни, я так навскидку не скажу.

Это бессигнатурка-лайт. Полная будет включать в себя паравиртуалку и сокрытие в неспользуемых местах диска. Для загрузки лучше всего подойдёт, пожалуй, А вообще, есть об этом смысл тут писать? Просто есть разные мнения, и опасения высказывались разными людьми и здесь и в других местах. Оно, конечно, достаточно хорошо защищено от полного раскрытия всех деталей "как и каким образом это делается", но всё же надо понимать, что это bleeding edge в security-технологиях, они разрабатываются специалистами для решения специальных задач. Вы не прочитаете нигде в открытых источниках о том, как это сделать, даже в английских. И в рассылке Debian вам тоже никто не блюдечке не преподнесёт инструкцию, как получить weaponized Debian.
— Гость (29/07/2014 21:08)   

Если шифрованный диск подключен и загрузчик смог с него загрузить ОС, то всё ОК, всё прозрачно для ОС читается и пишется на диск. Вопрос "после работы" тут как бы неуместен. Как и положено, при журналируемых ФС система должна быть устойчива даже к резету. Конечно, я сомневаюсь, что система сможет всё правильно определить и отмонтировать диски, но если в самом конце работы (штатное завершение, shutdown -p now) будет писаться какой-нибудь малозначимый ворнинг на этот счёт, то не думаю, что это сколь-нибудь страшно.


В том-то и дело, что cryptroot в рамдиске довольно умён, самому ничего изобретать не надо. Если вы не укажите опции в ручную, он ничего не найдёт и напишет ошибку загрузки. Если укажете правильные опции, он запросит пароль, и если этот пароль правильный, то загрузка пойдёт как по маслу.

С созданием рамдиска там тоже весело: например, если LUKS не установлен, cryptroot не будет положен в рамдиск при его создании, т.е. вы полностью останетесь без автоматики подключения шифрованного дискового пространства. Если установлен, туда могут утечь UID'ы ваших разделов и путь/имя root-устройства (какой-нибудь /dev/VG-NAME/root), что тоже плохо. Однако, там есть варианты конфигурации, при которых всё более-менее ОК.

Можно, конечно, не париться, и вообще создать внешний загрузчик, где всё будет уже указано и без лишних команд грузиться искоробки, но тогда, если такой загрузчик у вас найдут, будет то же самое, как будто его не было (впрочем, для переноса информации через границу годится — загрузочный диск можно с собой не возить). Конечно, лучше, в любом случае, использовать какой-нибудь стандартный загрузчик, которому руками указывать всё: и путь к руту, и опции cryptsetup.


Конечно, поэтому никто и не рекомендует так делать. :-)
— ressa (29/07/2014 23:36)   
Спасибо большое за ответы. Надеюсь, что у меня получится поднять знания до этого уровня. В любом случае – очень признателен.
— unknown (30/07/2014 09:59)   

Через границу банановой республики — да. А через серьёзные страны лучше возить только чистые носители или с системой, в которой нет никакого рэндома.
— Гость (30/07/2014 10:55)   

Лучше-то оно лучше, но тут речь о другом: либо вы везёте забитый рандомом диск без сигнатур (утверждается: да, было, но всё затёр, там ничего нет, диск пуст), либо диски с LUKS-заголовками и следами их использования, т.е. у вас могут спросить пароль. Как по мне, то первое лучше второго.
— ressa (30/07/2014 11:21)   
А почему в "серьезные" страны нельзя не возить информацию? Ну т.е. зачем рисковать, если можно залить в зашифрованном виде на свой сервер, а потом на месте скачать? Меньше рисков, вопросов в аэропортах и тд. Или я не правильно Вас понимаю, господа?
— unknown (30/07/2014 11:34, исправлен 30/07/2014 11:35)   

Правдободное отрицание, такое правдободное… Это прокатит при честном судебном расследовании. При въезде в страну вас могут просто не пустить, сбэкапить весь ваш диск на всякий случай и попросить спецслужбы повнимательнее приглядеть за вашим трафиком (времена и места выхода в сеть, объём скачанного), поставить на слежку все ваши перемещения, контакты и пр.



Именно так и советуют делать в EFF:
Defending Privacy at the U.S. Border: A Guide for Travelers Carrying Digital Devices[link1].

— Гость (30/07/2014 12:24)   

Ну, такова жизнь, значит.


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


Это они всегда могут сделать и по любому поводу — например, из-за посещения linuxjournal.com.


Скачать сколько? Терабайт данных? Ага, ага. Я имел в виду случай, когда нужно вести. Случай, когда без этого можно обойтись, очевиден. Там по ссылке, кстати, в таких случаях советуют позже высылать шифрованный диск по почте. Это плюс в том плане, что это не повиляет на пропуск на границе столь непосредственно, но минус в том смысле, что вы не будете знать, досматривали ли его (правда, unknown где-то кидал ссылку на то, что можно так покрасить его блёстками, что вскрыть, не оставляя следов, будет невозможно).
— Гость (30/07/2014 12:26)   

У меня есть часть дисков, которые не используются. Я их очищу, допустим, рандомом. Потом надо будет их везти с собой. Мне их что, принципиально потом ещё раз нулями перезаписывать, всем назло?
— ressa (30/07/2014 12:34)   
(правда, unknown где-то кидал ссылку на то, что можно так покрасить его блёстками, что вскрыть, не оставляя следов, будет невозможно).

В таком случае есть safe-packages[link2], если, опять таки, я правильно понял.
На счет терабайта данных я не подумал, для меня это немыслимый объем. Но, опять таки, в зависимости от цели и ценности этих данных. Если риск большой – уж лучше потратить сутки, и даже более – на скачивание их, нежели рискуя провозить. По поводу почты – снова, ну даже если в сейф-пакет упаковать – придет он распечатанный, забэкапят данные – кому претензии предъявлять и, главное, зачем уже?) Поздно ведь, отчасти личность скомпрометирована.
— Гость (30/07/2014 13:14)   

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


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

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

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


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

/comment81977[link7]


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

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

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


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

[/fix]
— unknown (01/08/2014 15:45)   

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

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

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


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


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

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


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


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


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

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

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


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

Оглавление


  1. Факты о загрузчиках
  2. Эксперимент
    A. Инсталляция
    B. Вариант с однопроходным решением
    C. Вариант с двупроходным решением
    D. Загрузка с флэшки как есть
    E. Загрузка с флэшки с указанием опций загрузчику на лету
  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)   
isolinux вполне органично смотрится на usb-флэшках, т.е. он, а принципе ставится не только на CD. Его чаще исользуют, чем syslinux, т.к. у него больше всяких фич, в частности в работе с рамдисками.


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

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

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


Апдейты можно тоже рассмотреть, оттестировать и включить в модель, но пока не до того.
— unknown (04/08/2014 12:13)   
Зарегтесь на сайте и создайте вики-страничку под этот документ, пусть для начала даже с черновыми и нерекомендуемыми к практическому использованию вариантами. Будет проще её исправлять по мере коментирования, возвращаться с новыми идеями, чем терять разрозненные посты в форуме.
— Гость (05/08/2014 20:24)   

Для вики-странички желательна хоть какая-то завершаемость, а для этого нужен хотя бы прототип инструкции. Инструкции нет. Тест пока что опирался на самодельный загрузчик — это плохо, но это просто эксперименты, нужные, чтобы достичь понимания принципов (cистему всегда надо строить от простого к сложному). В итоговом тексте 80% того поста было бы попросту ненужным информационным мусором. Наконец, у меня столько сырых недоведённых до ума страниц и идей, что я уже не рискую, не видя почти готового варианта, серьёзно браться за что-то новое.
— Гость (17/08/2014 22:02)   

Только без --use-random — оно к plain mode неприменимо (что вполне логично).
— Гость (24/01/2015 03:32)   

Кощеева смерть



Самостоятельно попроходил квест. Инсталлятор Debian'а понятен почти всюду, но в двух местах пришлось тыкать на угад. Первое уже забыл (что-то с разбиениями и конфигурацией дисков), а второе — conversion (uuid'ов?) перед самым finish install в районе записи загрузчика (взял lilo) на внешний носитель.

Извратился и сделал такую схему:
|-----------------------------------------------------------------|
| Plain cryptsetup (для бессигнатурности всего диска)             |
| |-------------------------------------------------------------| |
| |* LUKS (для возможности 1) менять пароль на весь диск и *****| |
| |* 2) быстро его весь затерирать) ****************************| |
| |*|---------------------------------------------------------|*| |
| |*|                                                         |*| |
| |*|  LVM Volume Group (чтобы уметь стирать системные        |*| |
| |*|  разделы при их загрязнении: всех их и только их)       |*| |
| |*|                                                         |*| |
| |*|  |---------------------------------------------------|  |*| |
| |*|  | Logical Volume root                     | Other   |  |*| |
| |*|  | --------------------------------------| | Logical |  |*| |
| |*|  | |*LUKS (он шифрует всё системное) ****| | Volumes |  |*| |
| |*|  | |*|---------------------------------|*| |         |  |*| |
| |*|  | |*|  LVM Volume Group "root"        |*| |         |  |*| |
| |*|  | |*| |-----------------------------| |*| |         |  |*| |
| |*|  | |*| | Logical | Logical |(etc) ...| |*| |         |  |*| |
| |*|  | |*| | Volume  | Volume  |...      | |*| |         |  |*| |
| |*|  | |*| | for     | for     |         | |*| |         |  |*| |
| |*|  | |*| | /root   | /       |         | |*| |         |  |*| |
| |*|  | |*| |-----------------------------| |*| |         |  |*| |
| |*|  | |*|---------------------------------|*| |         |  |*| |
| |*|  | |*************************************| |         |  |*| |
| |*|  | --------------------------------------- |         |  |*| |
| |*|  |-----------------------------------------|---------|  |*| |
| |*|                                                         |*| |
| |*|---------------------------------------------------------|*| |
| |*************************************************************| |
| |-------------------------------------------------------------| |
|-----------------------------------------------------------------|
Больше это для теста автоматики. Загручику lilo плохеет, он вываливается в командную строку, но если там всё пдключить, то через некоторое время он-таки добирается до нужных разделов и ОС запускается(!). Есть впечатление, что на одни и те же крипторазделы LUKS он запрашивает пароль по-нескольку раз, ибо тупой, причём на тот момент они уже подключены. Вроде даже если жать Enter вместо ввода пароля, то всё правильно отработает.

В Wheezy версия ядра 3.2. Надо хотя бы 3.5. Такого выбора нет, но есть jessie-β-2, там аж 3.16. Установка проходит штатно, но поддержка графики так и недостестировалась: после apt-get update и apt-get upgrade ядро так обновилось, что больше ОС не загрузилась. При старте системы на ранних стадиях загрузки ядро стабильно падает в панику, и ничего не помогает. Видимо, от идеи выполнять apt-get upgrade придётся отказаться на свой страх и риск до выхода 8.0. :-(

systemd выпиливался указанием опции к загрузчику инсталлятора[link14], но насколько этот метод был успешным, судить не берусь. sysvinit вроде установился.

В jessie новый cryptsetup, там теперь можно так монтировать:
# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 plainOpen DEVICE NAME
вместо старого
# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 create NAME DEVICE
(этот вариант тоже пока поддерживается, но считается устаревшим).
— unknown (24/01/2015 13:17, исправлен 24/01/2015 13:19)   

Разбиение на диски и крипторазделы там всегда было отвратным. Там есть возможность выйти в консоль и сделать всё вручную, но раз в несколько лет плевался и как-то методом тыка добивался нужного от обычного инсталлятора.


Кстати, LILO может плохо понимать навороты с томами, он для минимализма в духе старых систем, безо всяких (крипто)томов. Конечно, всё решает рамдиск, но в него из grub.conf передаются какие-то UID'ы.

— Гость (25/01/2015 01:09)   

Оно нормальное, но недокументированное, до всего надо доходить самому, даже если понимаешь, как это всё внутри должно быть устроено. Общая схема такая: идёшь по пунктам:
/dev/sdb
/dev/sda
И др. Сначала надо выбрать их и указать, как будем их использовать (LVM, LUKS или ещё что). Если выбран LUKS или LVM, то надо вернуться в верх окна и выбрать «сконфигурировать», чтобы он собственно создал новые логические тома или LUKS-устройства, запросил пассфразы и т.д., только после этого новые устройства появятся в списке наряду с
/dev/sdb
/dev/sda
и можно будет аналогичным образом разбираться с ними (новыми устройствами). Ещё нельзя в aes-xts-plain64 задать ключ 512. Эта тема ранее немного обсуждалась, см. 7 пунктов[link15].


Не уверен. Но если вы правы, то, по моим представляениям, это надо сделать до захода в меню detect disks. В частности, этим макаром добиваются того, что инсталлятор увидит /dev/mapper/NAME, который самый внешний и бессигнатурный, позволив уже его разбивать через LVM/LUKS и т.д.

Мне кажется, что он может не захотить распознавать ранее созданные LVM-тома в консоли.

Ещё заметка про софт: в конфигурирование пакетного менеджера зайти стоит, а в install software — нет, т.к. там даже если не выбирать ничего, он наставит всякого дерьма всё равно. Он говорит, что есть base system на CD, а ещё можно поставить «более полную» base system с сети. Так вот, более полную, похоже — это уловка, не надо поддаваться, т.к. там много сомнительного.

Можно попробовать с grub'ом сдеать. Он grub-1 не предлагает уже? В любом случае, тут важно одно: лишь бы работало. Загрузчик всё равно будет кастомный так или иначе, поскольку загрузку гипервизора ни один стандартный LiveCD не умеет. Следовательно, лучше не вытягивать самого себя за волосы из болота подстроек под типичный загрузчик, а подходить, как уже было предложено: нейтральным LiveCD/LiveUSB записывается загрузчик на носитель разово на одну загрузку; потом после загрузки загрузочный носитель затирается (см. пункты 5-8[link4]).

P.S. Кстати, миграция через mount union [п. 6[link4]] ненужна: initrd/initramfs достаточно умный (комнадная строка загрузчика), там все необходимые тулзы есть. Достаточно будет оттуда вручную подцепить блочное устройство, состоящее из скрытого места на диске, через dmsetup с его БД, и дальше загрузка пойдёт штатным образом.
— Гость (25/01/2015 13:23)   
Во время инсталляции base system инсталлятор предлагает на выбор 2 ядра: linux-image-3.16-2-amd64 и linux-image-amd64. Чем они отличаются? Судя по логам, как я понял, при выборе второго пакет для первого тоже ставится.


Когда нужно сделать некоторое созданное блочное устройство LUKS-контейнером, вы выбираете его в общем списке и говорите use as physical volume for encryption. Он при этом спросит, как его шифровать и всё такое. После выхода из меню блочное устройство будет помечено справа в списке как not active. После этого нужно вверху окна выбрать configure encrypted volumes (ну, чтобы оно запросило пассфразу и сделало его active, после чего данное блочное устройство можно сувать дальше: сделать на нём ФС, разметить под LVM или ещё что). Однако, когда вы заходите в configure encrypted volumes, он вам предлагает на выбор два варианта: create encrypted volumes и finish. В чём логика? Казалось бы, да, вы хотите его создать, но не столько создать, сколько активировать уже созданный. Это путает. Короче, надо выбирать finish (абсолютно нелогично), и тогда на следующем шаге он запрашивает пассфразу для not active устройства. После оно будет помечено как active.

Если же выбрать create encrypted volumes, он запрашивает, какое из доступных блочных устройств шифровать. Можно снова выбрать то, которое not active в основном списке, но что будет дальше, я не пробовал.

Ещё одна нелогичность: после того, как загрузили компоненты с CD посредством соответствующего пункта меню и выбрали, что загружать, cryptsetup уже должен появиться в консоли. Однако, это не так. Надо ещё включить сеть и сконфигурировать её. Настройка сети ничего с сети не загружает, но после этого cryptsetup в консоли появляется, и туда можно лезть выполнять ручную работу. В чём логика, и что это за фазы Луны, я так и не понял.


Ставлю ОС в конфигурации как тут[link16], на последней стадии возникают какие-то неисправимые траблы с установкой загрузчика на внешний носитель. Приходится всё прерывать и делать инсталляцию снова, а это опять ждать, пока установится base system (минут 15-20 занимает) и опять кучу ручной работы делать. Но ладно, я терпелив, проходим квест снова. Всё устанавливается, всё грузится, корневую ФС загрузчик не находит и, как положено, вываливается в шелл initramfs. Всё бы ничего, но cryptsetup'а там нет. Думаю, дай поставлю шифрованный своп, хотя не хотел — вроде по вышеприведённой инструкции это в обяз должно добавить туда cryptsetup. Заново всё делать не хочется, поэтому, казалось бы, достаточно загрузиться, всё подмонтировать, а потом выполнить только установку загрузчика. Но это тоже не так. Если install base system не выполняется, инсталлятор не видит носителя с /boot (а потому выбор grub-пункта в меню инсталлятора возвращает ошибку). Если зайти в консоль и сделать chroot /target, то видно, что никаких /dev/sdX-устройств там нет и в помине.

Что ж, значит снова делаем всю инсталляцию с начала и до конца. Сделали. Не грузится. Вообще никак. Чёрный экран, даже меню граба не вылазит. Руками при этом носитель монтируется, /boot там, всё ОК. Скопировал через dd на другой носитель, пробую. С него тоже не грузится. Блин, значит, надо сделать как-то grub-install снова, но как? Можно так же пройти заново всю инсталляцию, а загрузчик так и не начнёт работать, можно ли схитрить и сделать быстрее? ОК, похоже, можно сделать grub-install из-под другой системы.

Грузимся, но там новая засада: нам же надо сделать grub-install для новой системы с новым ядром и не в конвенциональное место записать /boot, да не испохабить ничего на последней работающей системе. Вроде это делается через chroot. Отлично, но после chroot /target ни одно из /dev/sdX устройств не видно. Как тогда он сделает update-grub? Надо бы ему объяснить... Опять лезем в гугл и находим инструкцию/скрипты с mount --bind, которые в чрут пробрасывают деревья /proc, /sys, /dev и т.п.

Сделали, grub-install выполнился. Грузимся снова, проверяем: о, чудо! Оно работает! Попадаем в initramfs-шелл, сейчас, думаю, наконец-то всё подключу, но... да ты ж ё*й ты н*уй!!! Нет там cryptsetup'а. Я уже в полном расстройстве. Как это так?!

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

I[link17] have therefore modified cryptsetup initramfs hooks to only include cryptsetup in the initramfs when necessary. I have tested multiple combinations (конечно же, такие вещи не стоит документировать — пусть все выясняют правду методом проб и ошибок) and here is a small summary:

No cryptsetup in initramfs, when:

  • no encrypted devices present
  • non-rootfs filesystems are encrypted (e.g. /var/lib is encrypted)
  • swap is encrypted with random key file (i.e. non-persistent encrypted swap)

cryptsetup is in initramfs, when:

  • rootfs is encrypted ( '/' )
  • swap is encrypted with a passphrase / key-file (i.e. can unlock & resume from hibernate)
  • CRYPTSETUP='y' option is specified in /etc/initramfs-tools/initramfs.conf

The last provision is for the case where one wants to generate an initrd on this machine, which will then be transferred to boot something else.

Чудесно, просто опупеть, как чудесно. Не трудно видеть, что в этой[link16] конфигурации, по такой логике, cryptsetup в initramfs ну вообще не нужен! Кто же такой умный? А там и пояснение в конце:
cryptsetup (2:1.4.3-4ubuntu4) saucy; urgency=low
 
  * debian/initramfs/cryptroot-hook:
    - Do not unconditionally include cryptsetup utils in the initramfs.
    - Do not include any modules or utils in the initramfs, unless
      rootfs/resume devices are encrypted or CRYPTSETUP is set to 'y' in
      the initramfs.conf configuration file.
 -- Dmitrijs Ledkovs Mon, 10 Jun 2013 16:25:46 +0100
Как видим, в 2013-ом году у одного гада зачесались лапки и он-таки полез туда, куда его совсем не просили. Интересно, Dmitrijs Ledkovs готов бы был мне оплатить потеряный день времени?

Судя по гуглу, grub-update/install не пересоздают initramfs, для этого надо то ли dpkg-reconfigure linux-image-... сделать, то ли update-initramfs -u -v перед собственно grub-install. Кстати, вместо извращений с распаковкой initrd для проверки, есть удобная тулза lsinitramfs. Можно пробовать. Я только одно не понял: почему в случае с lilo так нужный cryptsetup всё-таки попал в initramfs.

Продолжение следует.
— Гость (25/01/2015 13:29)   

Да, правы. Во всяком случае, меню инсталлятора всё показывает, хотя LVM- и LUKS-разделы были созданы ранее вручную. Правда, до конца не ясно, скажется ли это на чём-то, когда он захочет сгенерить initramfs [т.е. всё равно ли инсталлятору, как создавались разделы/устройства (в консоли или через меню) или нет, обращает ли он на это внимание при генерации содержимого /boot?].
— Гость (25/01/2015 13:37)   

Нет, всё не так. Собственно, эта страница по ссылке и есть данного автора — он только задекларировал имеющийся статус-кво, а вот кто его таким сделал — этот вопрос остаётся открытым.
— Гость (26/01/2015 04:52)   

Не помогает, как ни извращайся: ни 'y', ни y, ни Y. Пришлось похачить систему, явно её обманывая — указать, что своп шифруется якобы LUKS'ом, да ещё и статическим ключом: в /etc/crypttab вместо имеющегося



прописывается



После этого надо подключить этот «swap», чтобы в /dev/mapper появилось устройство — initramfs при создании лезет туда и проверяет, какие у него параметры и что (какие криптомодули) нужно положить к себе в initramfs.

Ещё бесит номенклатура: такое впечатление, что у загрузчика есть конечная глубина проверок, и имена конструируются в виде VolumeGroup-LogicalVolume_crypt, хотя можно адресовать напрямую (такое имя — симлинк). Соответственно, когда уровней вложенности много (LUKS в LVM в другом LUKS ещё в одном LVM), все эти чёрточки и подчёркивания перестают однозначно указывать на то, где искать нужное устройство, и из-за этого лезут глюки. Может быть, я всё неправильно понял, но впечатления таковы.

Короче, после этого всё взлетает и грузится, хотя сделано грязно, надо как-то иначе. Перед тем, как выпасть в шелл, initramfs очень долго шарится по дискам и опрашивает их, пытаясь найти устройство для root-ФС. Интересно, можно ли его проинструктировать не заниматься этим?


Теперь всё прошло нормально, даже Xen установился и гипревизор грузится, dom-0 работает.

С графикой что-то странное. xdm стартует прекрасно, но только на одном дисплее. Запустить два xdm'а не получается никак: если Xservers отредактировать, добавив ещё одну строку, не запускается ни один (хорошо, что хоть система при этом намертво не завешивается). Однако, если запускаем один xdm, он легко запускается на любом дисплее.

Тем не менее, несмотря на такие глюки, вручную через xinit с текстовой консоли дополнительные X-сервера на других дисплеях запускаются без проблем. Интересно, можно ли xdm так же принудительно запустить с консоли на других дисплеях? Как ни экспериментировал, не получилось. В старых ОС на точно таких же конфигах всё работает наура.


systemd тоже. ☺ Можно, наверно, его удалить, в других ссылках были инструкции на эту тему (смена загрузки с systemd на System V). Какая загрузка используется по умолчанию — непонятно. /etc/init.d/xdm start работает, /etc/rc?.d/ в системе тоже присутствуют.
— Гость (27/01/2015 17:04)   

Вспомнил, что на старой системе на таком же железе было так: с Xen'ом не запускалось никак, а без него запускалось только с nomodeset, передаваемом ядру. Думаю, дай проверю, как теперь тут, на новом ядре. Итоги: с nomodeset графика с Xen вообще не запускается; без Xen запускается, но больше одного xdm'а по-прежнему не запустить, и принудительный старт графики на иных дисплеях через xinit продолжает работать.


Можно, хак найден: дописать rootdelay=0 к опциям загрузки. Он тогда практически моментально выбрасывается в шелл, что нам и нужно (всё равно автоматикой там ничего толком не цепляется).


Хак грязный, хотелось бы почистить.

Для начала поэкспериментировал с указанием опции загрузчику на лету. Так, чтобы после указания всё начинало цепляться автоматически, не происходит. Однако, самый верхний уровень шифрования действительно можно сделать автоматикой — для этого дописываем
cryptopts=source=/dev/sdX,cipher=aes-xts-plain64,size=512,hash=sha512
к опциям загрузки ядра. Там же можно указать через ещё одну запятую
lvm=VolumeGroup/LogicalVolume
или lvm=1, но это ни на что уже не сказывается. После указания такого cryptopts он подключает самый внешний бессигнатурный слой шифрования, создавая устройство /dev/mapper/cryptroot, но догадаться запросить LUKS-пароль уже на сам /dev/mapper/cryptroot не может. В общем-то, в командной строке с автодополнением набирать команды намного проще, чем в grub2-меню в загрузчике, так что лучше cryptopts ядру (т.е. на лету) не указывать вообще никакой.

Это всё меня натолкнуло на мысли создать правильный crypttab — вдруг после этого всё заработает вообще автоматически? Структура, как выше сказано, такая:

plainOpen[LUKS{VG1( LV1,1( LUKS[VG2( LV2,1(root), LV2,2(usr), ... )] , ... ))}]

Зелёным помечено то, что, похоже, initramfs способен понять из коробки. Всё остальное — только через кастомные скрипты, если кто-то готов их писать. Казалось бы, если он готов раскручивать LVM, когда встречает его внутри «матрёшки», то всё должно отрабатывать, но этого почему-то не происходит, причины неизвестны. Тестировался вот такой crypttab:
cryptroot /dev/sdX none cipher=aes-xts-plain64,size=512,hash=sha512,initramfs
cryptroot_crypt /dev/mapper/cryptroot none luks,initramfs
LV_crypt /dev/VG/LV none luks,initramfs
где VG сидит на /dev/mapper/cryptroot_crypt. Пробовал убрать всюду initramfs — эффект тот же, ни одного пароля не запрашивается, даже на сам /dev/sdX. В принципе, crypttab достаточно умный, там есть много опций на этот счёт, и всё должно разруливаться, но сидеть и разбираться с этим пришлось бы долго, поэтому забил.

Фиктивный swap убрал c /etc/fstab и даже убил соответствующее LUKS- и LV-устройство принудительно, однако, после
# dpkg-reconfigure linux-image-<версия>
упоминание о нём оказалось выпилено не везде. По крайней мере, теперь он на него пароль не запрашивает, и это уже хорошо. Интересно, откуда initramfs черпает эту swap-специфичную информацию, если в crypptab и fstab её уже нету? Опирается на ранние версии содержимого initramfs?

Кстати, до сих пор не пойму, почему Debian всегда якобы 2 разных ядра ставит, в /boot 2 разных initrd и т.д.

Хорошая новость в том, что тесты убедительно показывают: initramfs'у совершенно пофигу на то, в какие глубины матрёшки запрятана соответствующая VG с рутовой ФС. Пока вы до неё добираетесь, можно назначать любые имена LVM'ам и LUKS-устройствам, это ни на что не повлияет. Чтобы не бояться обновлений, проделал на этой основе способ создания бэкапа: создаём такую же точно структуру на другом диске, но внутренний LUKS, содержащий VG с системой, побайтово копируем туда через dd if=/dev/VG/LV of=/dev/VG2/LV2 (LV2 перед этим создаём точно такого же размера). И всё работает, грузится и взлетает. Можно было бы сделать и через копирование файловых систем, но не хочется разруливать конфликты с несовпадающими UUID'ами, именами volume groups, logical volumes и т.д.

С отсутствием cryptsetup'а в initramfs можно бороться на лету. Если хуки или критерии не срабатывают (сделали update-initramfs -k all -u), тут же редактируем всё снова — lsinitramfs /boot/initrd-... | grep cryptsetup показывает, попал он туда или нет.
— Гость (27/01/2015 17:06)   

Не знаю, кстати, были ли она там когда-то или нет, но в моей версии man initramfs.conf опции CRYPTSETUP не числится.
— unknown (27/01/2015 21:01)   
Когда-то разбирал initrd, вроде туда можно положить что угодно. В дебьяне нельзя ничего делать по общелинуксовому (можно и так, но не рекомендуется), а нужно делать по-дебьяновски. Т.е., если вы вручную распакуете initrd, поправите, запакуете и положите на место, то оно сработает, но предполагается, что за такое кто-то должен бить по рукам, например, очередной апдейт к вашей системе.

Есть /etc/initramfs-tools. Там нужно в подкаталоги в соответствии с их структурой поместить всё, что нужно, поправить там конфиги. Разумеется, на изучение всего этого и на эксперименты нужно потратить достаточно времени, зато потом всё будет работать как часы и можно забыть этот напильник на многие годы.

Затем командой update-initramfs -u все обновления попадут в initrd. И так будет происходить при соответствующих апдейтах системы автоматически.

Может ещё где-то что-то нужно конфигурировать для поддержания initrd, сходу не помню.
— Гость (27/01/2015 22:08)   

Можно попросить туда положить загрузчик TrueCrypt?
— Гость (27/01/2015 22:29)   
Можно, просите.
— Гость (27/01/2015 23:20)   

И дасться?
— Гость (28/01/2015 20:20)   

Вам удалось? Вы на среднем уровне вникали в то, как собирать initrd под себя из говна и палок? Я пока таким похвастаться не могу. :-(


Не знаю, оно меня удивляет, я эту автоматику не понял. Бывает, всё обновил, и вроде ОК, ничего не работает. А после следующего апдейта вдруг лезут какие-то артефакты типа лишних запросов паролей с шифрованной ФС, до каких он до этого не догадывался. Кастомный crypttab вот тоже не взлетел, а почему — непонятно. Были бы знания, можно было б распаковать initrd и проанализировать её содержимое, чтоб понять, почему некоторая автоматика не отрабатывает. Впрочем, даже если б были знания и время, как часто бывает в таких случаях, при более плотном разбирательстве с системой вдруг оказывается, что там элементарно баги. Они везде, где ни копни. :-(


Была идея перенести старую ОС в бессигнатурно шифрованный диск. Теоретически всё делается просто: переносим загрузочный /dev/sdX с /boot'ом и grub'ом на другой носитель, а LUKS с системной volume group запихиваем куда хотим — потом в командной строке initamfs его так же можно будет подцепить.

Однако, перенести загрузчик на внешний диск мне так и не удалось. :-( Создал там раздел загрузочный, перенёс файлы, сделал dpkg-reconfigure ядра, сделал update-grub, update-initramfs тоже делался, но всё бесполезно. Сначала grub выпадал в rescue-mode — дескать ему нужен не просто загрузочный раздел, а раздел именно с заданными UUID'ом. Прошерстил его конфиги грепом, нашёл load.cfg, там этот UUID прописан (кстати, в моей самой новейшей версии grub'а таких файлов вообще нет). Откуда он его черпал при всех обновлениях — без понятия. В fstab всё прописал, как должно быть — не помогает. Заменил UUID на правильный — то же самое. В итоге руками перезаписал UUID в load.cfg. Потом потестил на обновлениях граба и остального — вроде самовольно UUID он не менял. После этого я каждый раз при загрузке попадал прямиком в командную строку grub'а — никаких менюшек или ещё чего-то. Попытка выехать за счёт хаков на лету типа chainloader +1 тоже ничего не дала. Главно, было написано, что это grub 1.99x. Как так, если в той ОС по дефолту стоял именно второй граб? Понятно, что все настройки по переносу старой ОС осуществлялись после стандартной загрузки в эту ОС.

Короче, плюнул на всё это дело и решил рискнуть воспользоваться новым загрузчиком для старой ОС. Указал на лету иной root=/path/to и подключил руками нужные разделы в ком. строке initramfs. Оно взлетело. Получается, система на новом ядре, но всё остальное старое. Затестил, как себя поведут в этом случае иксы. С Xen-ядром они даже не запускаются, как и раньше, а с обычным ядром запускаются, но тут же намертво вешают систему после своего запуска — помогает только reset (не важно xdm там или ручной старт). Короче, жить можно, но только в текстовой консоли.

Есть интересная инфа про загрузчики. Взял стандартный Debian LiveCD/LiveUSB, инсталляционный Debian'овский и Gentoo'шный resuce CD. Итог:
  1. Gentoo Rescue CD оказалось негибридным и поэтому с флешки не грузится, надо колодовать с isohybrid. XXI-ый век на дворе, ага. Кого сейчас заинтересушь гибридными CD? Флешки появятся только через 10 лет у людей. Про то, что большинство современных ноутов уже поставляются без CD-приводов, авторы не подозревают.
  2. Официальный Debian LiveCD меня умилил и я опять вспоминал /comment53852[link18]. Линукс как был петушьём на фоне BSD, так и им и остался. Что курят пидорасы, у которых в 200 MB iso (lxd) влазит графика, десктоп, фреймбуфер с наворотами и масса прочей дичи, но при этом в системе нет LVM. Если это не ахуй, то что такое ахуй? cryptsetup-таки есть да. На самом деле, это не предел, я видел жёстче: это когда на хостинг устаналивают Gentoo с ядром, в котором не работает iptables, потому то сборщики-дистростроители решили, что conntrack в ядре нахуй не нужен.
  3. Инсталляционный LiveCD примерно такой же, как Live — сексуальная ориентация от смены CD не меняется. Номинально можно выбрать, какие tools подгрузить с CD в инсталляторе и попасть потом в rescue-шелл, где всё должно работать. cryptsetup там есть, номинально запускается и даже запрашивает пароль. Казалось бы, уже нет места для подставы, что ещё можно придумать? А вот шах вам и мат: можно. После ввода пароля он говорит, что модуля device mapper'а я в ядре нет! Не знаю уж, как там с LVM обстоят дела, но факт остаётся фактом: оффлайновый инсталляционный Debian CD бесполезен и не содержит возможностей cryptsetup. Как же тогда работает, спросите вы? А очень просто: перед этим можно опционально выйти в детекцию сетевых настроек, а потом настроить саму сеть. Никаких предупреждений на счёт того, что после этого что-то подгружается из сети нет! Но нужные модули у ядра откуда-то появляются. Короче, инсталлятор с «содержимым тулзов на CD» — просто наибалово. Эти тулзы реально не грузятся с CD. В лоб файерволлом не тестил, но уверен в этом на 90%, т.к. не вижу никаких иных объяснений.

Вот так и живём, господа. В XXI-ом веке LiveCD с шеллом, где есть LVM и cryptsetup — роскошь. Моя кастомная ramfs размером в 60MB, оказывается, намного полезней для восстановлений при сбоях и всём остальном, чем все эти популярные инсталляционные и LiveCD-диски, распространяемые миллионами. По крайней мере, cryptsetup, LVM и dd там работают, а это уже достаточный минимум для отката системы к предыдущей версии. Если б не необходимость иметь нейтральный загрузочный носитель, можно было б не мучиться. Может быть авторы удаляют всё из ядра, чтобы оно грузилось на калькуляторах? Памяти не хватает? А для plymouth-место таки нашлось? Нет, всё-таки просто пидорасы, нет других объяснений.

В BSD не бывает такого сорта проблем. Любая BSD содержит необходимый минимум. Чтобы его оттуда выпилить, надо очень сильно постараться, и за это не приято гладить по головке. Там концепция полноты и самодостаточности системы настолько глубока, что базовая система содержит даже косольный браузер.

В initramfs-шелле не хватает man'ов. Неужели они так много весят? Во времена, когда найти флэш-память размером меньше, чем на гигабайт — это проблема, в чём смысл не класть man'ы? И ком. строки grub'а это тоже касается.

Сейчас пишу с бессигнатурки. Здесь на форуме уверяли, что такое невозможно. Судя по всему, никакого «заката Солнца в ручную» нет и близко, всё работает как и раньше. Канитель:
  1. В загрузчике (конфиг grub) указываем rootdelay=0
  2. В initramfs выполняем штук 5 команад.
  3. Делаем exit и система грузится, как ни в чём ни бывало.
Системе вообще пофигу откуда она грузится. /boot перед apt-get updgade монтируется стандартно, апдейты тоже идут стандартно. Можно было бы, конечно, всё автоматизировать, чтоб не вводить лишние команды в initramfs при загрузке, но мне это некритично.
— unknown (28/01/2015 21:47)   

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


Придёться палиться своими конфигами, ну мне терять нечего. У меня какая-то старая записка в файле есть по этому делу:



Ещё лежят образцы device.map, grub.cfg, ещё помню, что uuid берется с ext2fs, вот комент про это:



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


Вы не поняли дух Debian, там всё есть, но сделано так, чтобы потыкались и решили, что ничего нет, что Debian — УГ и ушли на свою Убунту. :) По памяти не помню, но в Debian специально, чтобы никто непосвящённый в эти обряды не догадался, где-то в дремучих глубинах сайта есть какой-то правильный Live-cd, то-ли professional, то ли rescue, то ли как-то так, там все профессиональные утилиты, вплоть до всякой полуфорензиковой экзотики. с него и инсталлиться можно. А инсталлиться надо выбрав все пакеты вручную, поставив в систему только минимум и apt, а затем аптом выбрать всё, что нужно.

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

С Debian так: долго помучался, но разобрался, сделал и забыл на несколько лет. Он же стабильный.


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

На будущее, там и ядро самоскомпилённое нельзя ставить через make install, надо собрать из него кастомный пакет и прописать в apt. И grub.cfg править нельзя: надо править конфиг, который предназначен для правки grub.cfg, который лежит в другом месте. Я половину этих штук не знаю и делаю криво и неправильно, но считаю, что это разработчики имеют право быть дартаньянами, а не я.
— Гость (28/01/2015 22:47)   

Ну вот вам понятно, почему update-initramfs не цепляет crypttab? Куда рыть, что смотреть?


Ага, я тут один идиотствую из проекта. Больше никто не палится. Все умные, один я дурак.


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

Честно говоря, не то, чтоб мне это так сильно надо было, просто как PoC было бы красиво. Наверно, в гугле есть относительно внятные инструкции, как переносить /boot на иной носитель для современных версий ОС.


Общее понимание остаётся, что там и как работает, что с чем связано. Проблема — не подглядеть в скрипт/man, проблема — понять схему работы всей конструкции в целом и связь её частей.


На основной странице сайта проекта есть ссылки на всё, что у них имеется, я там многократно лазил. Содержимое серверов с iso-шками напрямую я тоже анализировал, хоть и поверхностно. Ни на что такое не наткнулся ни разу. Если кто-то где-то под себя из принципа что-то собирает, это ещё ничего не говорит о проекте в целом. Этот LiveCD официальный? Покажите ссылку. И описание его на сайте тоже покажите, без этого просто не о чем говорить.


Вы за оффлайновую инсталляцию? Может быть, она и даёт больше безопасности, но не так значительно — всё равно ж с сетью работать компьютер будет и софт тянуть оттуда тоже. Раз инсталляционный CD проверяет подписи на пакетах, то что ещё нужно? Разве что файерволл.


Ручной перенос системы, если нет под это знаний — жесть полная. Даже в самых простых BSD это не такая простая процедура, и по затратам мозг-время часто проще не клонировать, а поставить заново. На клонинг идут тогда, когда это окупается (ну, например, не надо обновлять ОС до более новой версии, и там уже есть весь необходимый софт — требуется просто копия системы). Я несколько раз в жизни проходил через клонинг, но все разы мне помогали более опытные в этом деле товарищи.


Сейчас такое железо делают, что может и года не проработать, а новое железо — это новые пляски с ОС, новые «не поддерживается» и т.д.


Это я-то не разобрался?! А что я, как юзер, по-вашему, должен? Полностью изучить за разрабов всю их внутренню кухню, вычитать всю рассылку, учесть все явно упомянутые и неупомянутые костыли, все сделать правильно назло всем, а потом вежливо намекнуть «УМВР, но разрабы могли бы сделать чуть лучше»? Добро пожаловать в реальный мир тогда. Как в таких случаях бывает, начальство жмёт руки и говорит «спасибо вам за то, что вы у нас работали».

Я — потребитель, и во многом судья со стороны. К тому же, у меня есть опыт и возможность сравнивать, что где и как работает. И меня абсолютно не волнует исходя из каких соображений ребята породили говно. Мне достаточно факта.


Без новояза объяснить не получается?


Я в курсе, но это как бы хорошо известно и всем понятно.


Знаю, поэтому делал всё через автоматику, но она почему-то тоже делает не то, что должна, а почему?


А я уже мальца подустал от дартаньянства «слишком умных». Меня незнанием матчасти всю жизнь тыкали, но вроде уже давно наступил момент, когда мне можно потыкать этим других. Знаете ли, я делал намного более сложные вещи чем эти ваши ядра и инсталляторы, и знаю, какой бардак там творится: и очковтирательство и бред и всё остальное (Это там, где люди реально несут ответственность, делают не for fun и стараются вылизать каждый кусок своей работы). А если глянуть глубже, там такой ужас, что я не представляю, как всё до сих пор не рухнуло.

Эти горе-программисты просто порождают говно как Константин Клягин, и все, кому надо, это прекрасно понимают. Можно искать, как оправдать любую дичь, но дичью это быть не перестаёт. Не делайте, одним словом, из разработчиков небожителей. Сидят там такие же придурки, как и во всех остальных местах (и у нас, в том числе) и ваяют говно. Но если в коммерции из-за косяка встанет процесс или рухнет инфраструктура, баготворителя могут выставить за дверь, и он об этом знает. А если баг в опенсырце, который for fun, то можно натворить любые косяки, а потом надменно комментировать их в рассылке как «ну и что, подумаешь, ерунда; у меня всё работает».
— unknown (28/01/2015 23:04, исправлен 28/01/2015 23:12)   

При любых обновлениях ядра вам на флэшку надо будет скопировать только system.map, initrd, vmlinuz и config. Сам grub обновляется редко. При его обновлении надо будет пересоздать флэшку заново по этому черновику, так что править там конфиг всё-равно придёться заново, благо одна строчка, а если иметь его бэкап, то всё ещё проще — часто после обновления grub diff'ом можно сравнить бэкапы, выдернутые в разное время из /boot и убедиться, что там ничего не поменялось.



Там всё ещё хуже. Обратитесь по дорогой платной корпоративной техподдержке к кому-нибудь типа Оракла, MS, Intel, IBM и пр. с вопросом чуть сложнее, чем «не туда ткнул мышкой». А если ещё с какой-то нестандартной штукой, которую 99.99% пользователей не настраивает, то будет вообще цирк.



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

— Гость (28/01/2015 23:11)   
С техподдержкой везде так — на том конце провода соединяют с клушами, а до специалистов надо ещё добраться.

Серьёзные косяки — это, например, аварии на магистралке, когда огромная страна остаётся без Интернета. Ну, или из-за головотяпства какой-нибудт ютуб оказывается заблочен на всю страну. И эти вопросы требуют решения за минуты, т.к. иски за простой могут быть колоссальными.
— unknown (28/01/2015 23:24, исправлен 28/01/2015 23:25)   

Специалисты тоже могут нихрена не решить проблемы с дорогущим оборудованием, можно собачиться с компанией, а можно плюнуть и найти решение почти как в опенсорсе, а не ждать пока там компания включит это в свою официальную документацию.

— Гость (29/01/2015 00:44)   
Вы больше напираете на пример компания-клиент, хотя я изначально имел в виду вопросы кода для нужд внутри компании. И оправдываться, почему оно не работает, придётся не перед заказиками извне, а перед собственным руководством, которое тебе задачу поставило, а ты её или не выполнил или выполнил криво.
— unknown (29/01/2015 09:34, исправлен 29/01/2015 09:50)   

Там масса примеров такого же абсурда, внутренней бюрократии, плохой организации, наказания невиновных и награждения непричастных. И такие вещи некорректно сравнивать. Вы с поставщиками дистра — не одна компания, вы же пользователь, а не разработчик.


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

— Гость (29/01/2015 14:02)   
Это всё хорошо, и можно понять, но как это касается вполне конкретной вещи — исключения dm_mod из загрузочного ядра? Загрузчочное ядро же наоборот стараются делать как можно более GENREIC, чтобы не испытать проблем ни с поддержкой железа, ни с недостатком фич. В крайнем случае, можно было бы давать несколько ядер на выбор — полное и, если с полным проблемы, усечённое.

Можно ещё руками попробовать сделать в шелле modprobe dm_mod или поискать соответствующий файл на диске; если найдётся, то insmod /path/to/module_file должно спасать. Но вроде модули обычно подгружаются при надобности автоматически, так что вряд ли это поможет.
— Гость (29/01/2015 14:32)   
У все продвинутых мелкий шрифт, а у меня крупный. Почему?
— Гость (29/01/2015 14:47)   
Потому[link19].
— Гость (03/02/2015 12:51)   

Вспомнился комментарий

П[link21]о теме есть устаревший материал: Uwe Hermann: Towards a moderately paranoid Debian laptop setup[link22].

Автор там пишет:

Disconnect your laptop from any kinds of networks. Pull all ethernet cables. Disable WLAN (via hardware killswitch). Disable Bluetooth. Disable/remove Firewire, USB, serial, whatever.

Get the most recent Debian-installer ISO image (currently etch-beta3), as well as the MD5SUMS and MD5SUMS.sign files:
wget http://cdimage.debian.org/cdim.....ng-i386-binary-1.iso[link23]

Он ставит Debian именно оффлайново, но не с netinst CD. В принципе, само название netinst как бы подразумевает, что это «network installation», поэтому неудивительно, если чего-то базового и важного там не предусмотрено. А ставить с другого типа CD — значит, устанавливать в систему множество всякой софтовой бредятины, которую потому замечаешься вычищать. ☹
— Гость (08/03/2015 18:35)   

Был неправ. Инсталляционный диск (netinst для jessie) таки содержит всё необходимое, подключение к сети ненужно. Чтобы появился полноценный рабочий cryptsetup, нужно зайти в «detect network devices» (не спрашивайте, в чём логика; это Debian-инсталлятор, и этим всё сказано). В следующий пункт (конфигурирование сети) можно не тыкать. После этого отлично работает dmsetup и LVM-тулзы в rescue shell'е (туда даже не надо заходить — проще переключиться через Ctrl+Alt+F2 или Ctrl+Alt+F3 в другой терминал и там будет rescue shell безотносительно того, что рисуется на curses инсталлятором на F1-дисплее).

Но тут возникает одна очень тонкая подстава. :-) Мы не можем подмонтировать файловую систему, он будет писать invalid argument. Видимо, нужные модули ядра (файловых систем) на этой стадии ещё не подгружены. Чтобы решить проблему, тыкаем сначала в «detect disks», а потом в конфигурирование дисков. В последнем случае спросят, что выбрать — manual, guided или ещё что. Можно ничего не выбирать, а сразу перейти через Ctrl+Alt+F2 в другой терминал, и, вуаля, теперь всё успешно монтируется. Я так смог сделать себе бэкап всего системного раздела, а также восстановить загрузочный носитель с бессигнатурно шифрованного диска. Всё работает. Немного геморойно, конечно, по этим пунктам пробираться, но если перезагружаешься не часто, можно привыкнуть.

В общем, мораль басни: в качестве «загрузочного» носителя инсталляционный netinst-диск (USB-флешка) достаточен. С его помощью можно считать откуда угодно загрузочный образ, записать его на другую флэшку, а потом с неё загрузиться. Когда загрузился, её можно снова зачистить рандомом. И пока система загружена, ничего нет кроме бессигнатурно полностью шифрованного диска и инсталляционной флэшки.

P.S. Была идея вместо тыкания в меню инсталлятора сразу дать в rescue shell команду, чтобы подгрузить нужные модули ядра, но пройти этот квест не удалось.
— Гость (08/03/2015 18:40)   

Потому, что вы не продвинутый. К.О.
— Гость (21/03/2015 07:13)   
Перечитал тред и сам ужаснулся. Теперь не верится, что через всё это когда-то пришлось пройти... Я даже уже успел забыть, что однопроходного решения вроде так и не было найдено, и если всё повторять заново, похоже, хак с реинсталляцией загрузчика из-под другой системы всё равно понадобится.
— unknown (21/03/2015 14:02, исправлен 23/03/2015 09:51)   

Здесь был гипероффтоп[link24]. Пусть он будет там[link25].

— unknown (21/03/2015 14:51)   

Вы хотите бессигнатурно шифровать, делать множество нетривиальных вложений томов и т.д. В Debian был баг-репорт, что при даже не самом навороченном вложении шфированных томов некая матрёшечная конструкция некорректно отмонтировалась при poweroff и накапливались ошибки. Тогда что-то пофиксили. Если вы городите что-то очень своё, то есть шанс поиметь проблемы с потерей доступа к данным после очередного выключения, обновления и т.д. Не говоря уже об общей оценке затрат сложности персонального поддержания на некоторые самопальные неискоробочные решения.
— Гость (21/03/2015 17:20)   

Даже при стандартном полнодисковом шифровании он не мог корректно всё отмонтировать и удалить ключи из памяти, а при таком — тем более, поэтому, по-хорошему, всё критическое надо перед выключением отмонтировать самостоятельно (а также удалять ключи из памяти). В идеале — зачищать оперативную память перед выключением, как это можно сделать при желании из настроек Tails.


К счастью, журналирование в ФС есть, это сильно спасает дело, но и бэкапы никто не отменял, естественно.


Угрозы со временем только растут, атаки становятся только сильнее, поэтому, чтобы сохранять паритет с противником и быть хотя бы на один шаг впереди, нужно развиваться и совершенствовать защиту.
— ressa (07/04/2015 17:11)   
Господа, подскажите, можно ли сделать загрузку OS по ключевому файлу и паролю с флешки?
Ну, к примеру сделать openssl rand -base64 16384, записать его на флешку и при включении компьютера система будет требовать его и ввод пароля?
— SATtva (07/04/2015 17:39)   
При полнодисковом шифровании так и делается, только openssl явно ни к чему. Как это сделать, зависит от конкретного дистрибутива, в Gentoo опции для сборки initrd можно определить с помощью genkernel.
— ressa (07/04/2015 17:41)   
SATtva, ну мне, как ламеру – что-то дебианоубунтуобразное. А почему openssl ни к чему? Так то по сути – плевать, что будет исполнять роль ключевого файла, правильно? Хоть тот же gpg-ключ или "семейная фотография".
— Гость (07/04/2015 18:05)   

Обычно всё же нет. Во-первых, /boot, как правило, на том же диске, который и шифруется, а не на внешнем носителе, а, во-вторых, cryptsetup обычно работает без каких-либо ключевых файлов. Конечно, всё это можно наворотить при желании самому.
— SATtva (07/04/2015 18:08)   
Ок, скажем так, это достаточно распространённый подход.
— unknown (07/04/2015 18:19)   

См. /usr/share/doc/cryptsetup/examples.
— Гость (08/04/2015 02:29)   

Просто штатное полнодисковое шифрование — оно не для параноиков, посторонний внешний носитель для загрузки ещё таскать — неудобно, поэтому вот так. ☺


Только хотел сказать, что --key-file — это не произвольный файл, а файл для пассфразы, поэтому для двухфакторной аутентификации, видимо, понадобятся костыли (в отличие от того же cgd, где это по умолчанию делается всегда и штатно). Собственно, да, в examples приведён пример костыля. ☺ Кстати, тут это уже обсуждалось[link26].
— Гость (28/04/2015 17:03)   

Патчи к пунктам[link4] про общую (неупрощённую) схему бессигнатурки



Плохой вариант. Обманка, в которой ничего не шифруется, позволяет проследить каждый шаг пользователя, выполненный в обманке: когда систему грузили, что делали, откуда что скачивали и т.д. и т.п. Следов будет полный воз, и по ним точно можно сказать, что система фиктивная. Кроме того, какие бы нейтральные вещи под ней ни делались, это всё равно будет утечкой информации.

Вместо этого в качестве обманки можно взять какой-нибудь Live-USB и записать его на диск подобно этой[link27] инструкции. Брать Tails — значит, подчёркивать осведомлённость в некоторых технологиях, но можно взять какой-нибудь нейтральный Live-образ. В принципе, его можно создать даже самому под свои нужды. Ничего такого туда устанавливать не надо, но в довесок можно (по аналогии всё с той же инструкцией) сделать для обманки отрицаемый скрытый раздел, из которого после запуска системы можно каждый раз доустанавливать нужный софт (Tor, macchanger или ещё что-то специфичное) и подключать какие-то нейтральные данные. Если отрицаемый скрытый раздел не подключается, будет обычная нормальная рабочая Live-система с ограниченными возможностями. К ней можно даже сделать обманный нешифрованный раздел с нейтральными данными, но он, в принципе, будет вреден: будет видна частота изменения данных, когда последний раз монтировали систему и т.д.

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


openssl не нужен, как уже выше, кажется, отмечалось. Достаточно бессигнатурного cryptsetup'а с адресацией нужных блоков, а внутри него сделанной ФС с данными. Это делается проще, из коробки, и в целом оно более безопасно/надёжно.


Как ясно из этого треда и вышеприведённых обсуждений, «live» тут не нужен. Скрытая система — полноценная система, установленная куда-то там внутрь матрёшки[link16] из LVM'ов и cryptsetup'ов. Системе всё равно, куда она установлена, лишь бы был правильный загрузочник и /etc/fstab.


Ввиду вышесказанного патча к п. 2, посторонние LiveCD/LiveUSB не нужны — вместо них можно воспользоваться обманкой, раз она тоже будет Live-системой. Основное требование к обманке — то, что по ней не должно быть возможным сказать, сколько раз её грузили, как долго в ней работали, какие сайты открывали и т.д.


Как уже было выше сказано, ничего из этого не нужно. Достаточно просто штатно грузануться с карточки/флэшки или что там используется, в командной строке initramfs'а подключить нужные LVM и cryptsetup'ы, а потом набрать exit — загрузка пройдёт.


У флэш и прочих карточек есть интерфейсы низкоуровневого доступа, которые принудительно записывают нули во все ячейки [1][link28], [2][link29]. Это делается намного быстрее, чем полное заполнение флэш-носителя какими-то данными через стандартные интерфейсы взаимодействия с ним. В общем, можно как-то комбинировать эти методы.


Посторонная Live-систеима не нужна, как выше уже было отмечено (разве что для подстраховки).


На загрузочнике скрытой ОС стоит просто /boot, а в нём есть и гипервизор со всеми вытекающими. Live-система тут уже ни при чём.

P.S. Если в матрёшке[link16] какие-то LUKS-разделы нужны только для возможности быстрого удаления, на них можно ставить пустые или простые пароли.
— pgprubot (22/05/2015 19:39, исправлен 22/05/2015 19:42)   

Раз загрузочный носитель всё равно затирается:


Снова подсоединяем MicroSD-карточку. Затираем её.

можно на него помещать как скрипты для автоматического монтирования дисков, так и LUKS-заголовки к ним:


... П[link30]роще хранить заголовок LUKS'а в каком-то третьем устройстве в файле, тогда бессигнатурность будет иметься изначально и штатно, а подключаться такие тома будут одной простой командой.

Т.е. аутентичный режим plain mode нужен только при шифровании образа загрузчика. Этот образ нужно будет при каждой загрузке расшифровывать вручную из-под того или иного LiveUSB и записывать на флэшку/карточку.

— pgprubot (27/05/2015 02:51, исправлен 27/05/2015 02:54)   

Но:


З[link16]агручику lilo плохеет, он вываливается в командную строку, но если там всё пдключить, то через некоторое время он-таки добирается до нужных разделов и ОС запускается(!).

Установка проходит штатно, но поддержка графики так и недостестировалась: после apt-get update и apt-get upgrade ядро так обновилось, что больше ОС не загрузилась. При старте системы на ранних стадиях загрузки ядро стабильно падает в панику, и ничего не помогает.

Т.е., похоже, всё было не так. С lilo загрузчик установился сразу, всё работало, но система не пережила upgrade. С grub2 загрузчик штатно нормально не поставился, понадобились ручные фиксы, но зато после этого система стала нормально штатно апгрейдиться/апдейтиться.


Можно было бы тщательней поковырять вариант с lilo, но непонятно, насколько он считается штатным и поддерживаемым в Debian. К примеру, правильно ли он фиксится/апдейтится (как grub2) при установке гипервизора Xen и dom0-ядер Linux?

— Yellow (06/07/2015 12:47)   
Пожалуйста, уточните архитектуру бессигнатурки с grub2. Я так понимаю, что на HDD есть бессигнатурное шифрование, и отдельно имеется носитель с Live-OS. Для загрузки скрытой ОСи, в этом случае, используется grub с live-носителя?
— pgprubot (06/07/2015 16:15, исправлен 06/07/2015 16:19)   

Каждый городит пример в меру своей испорченности...



Это как один из вариантов.



В таком случае нужной отрицаемости не получится, потому что сложно сделать универсальный grub для загрузки всего.


С Live-OS грузится только Live-OS. После её загрузки надо вытянуть загрузочный boot-образ (с настоящим grub2 для скрытой ОС) с бессигнатурно шифрованного носителя и записать его на какой-то третий носитель. После этого Live-OS выключается, вы грузитесь в скрытую ОС с этого третьего носителя. Затем вы этот третий носитель отмонтируете и затираете (из-под той же скрытой ОС). Примерно так это выглядит.

— pgprubot (09/07/2015 22:16, исправлен 09/07/2015 22:22)   

Справедливо ещё более сильное утверждение: на VG тоже ничего не заязано. Можно взять корневую ФС, как-то иначе переразбить на отдельные ФС, каждую ФС зацепить на своё LUKS-устройство с иным именем, потом перегенерировать initrd, и всё будет работать.


update-initramfs -u (или ещё с -t, если нужно) с последующим update-grub достаточно умно, чтобы понять, каков стал новый root=/path/to и прописать его в настройках. Однако, ожидаемо, при этом cryptsetup в initramfs не попадёт, требуются хаки.



Похоже, он полностью игнорирует эту опцию из-за каких-то ошибок в скриптах. Вместо того, чтобы разбираться с сотнями строк скриптов, можно применить следующий хак: в /usr/share/initramfs-tools/hooks/cryptroot закомментить проверку условия (строки с if и fi) в

if [ -n "$CRYPTSETUP" ] && [ "$CRYPTSETUP" != "n" ]; then
    setup="yes"
fi
После этого cryptsetup устойчиво попадает в initramfs неазависимо от конфигурации системы. Можно ещё для гарантии в /usr/share/initramfs-tools/conf-hooks.d/cryptsetup прописать CRYPTSETUP=y, но, скорей всего, это ни на что не влияет.



Очевидно, из /etc/initramfs-tools/conf.d/resume. Этот файл можно отредактировать или оставить вообще пустым. Вообще, resume («восстановление») — файл с настройками для свопа, откуда система будет «просыпаться». Если hibernate/suspend не используются, про него можно забыть.



Если без initramfs, то первые две строки не работают. Последняя и другие ей подобные работают, если соответствующий раздел также указан в /etc/fstab.


Не уверен в правильности понимания логики работы этих скриптов, но, по всей видимости, оно работает как-то так: то, что без initamfs, не будет автоматически запрошено на стадии загрузчика. После подмонтирования корневой ФС он смотрит в /etc/fstab и пытается смонтировать ФС'ы оттуда. Если непосредственно это сделать нельзя, он заглядывает в /etc/crypttab на предмет того, можно ли найти нужный раздел, открыв какой-нибудь LUKS-том. Т.е. fstab первичен по отношению к crypttab. Если нечто указано только во втором, запрос на открытие LUKS-тома не поступит. Это ещё видно из того, что он запрашивает пароли по мере загрузки и необходимости (не все сразу).

— pgprubot (10/07/2015 00:19, исправлен 10/07/2015 00:23)   

Точнее, там так: берём /etc/crypttab наподобие такого:

cryptroot /dev/sdX none cipher=aes-xts-plain64,size=512,hash=sha512,initramfs
cryptroot_crypt /dev/mapper/cryptroot none luks,initramfs
rootfs_crypt /dev/VolumeGroup/rootfs none luks,initramfs
var_crypt /dev/VolumeGroup/var none luks,initramfs
NAME1_crypt /dev/VolumeGroup/NAME1 none luks
NAME2_crypt /dev/VolumeGroup/NAME2 none luks
Делаем update-initramfs -u и update-grub. Внешний слой бессигнатурный, внутри него LUKS, внутри LUKS'а — LVM (группа томов VolumeGroup). Логический том VolumeGroup/rootfs — LUKS, внутри которого корневая ФС, а VolumeGroup/var — LUKS, внутри которого ФС для /var.


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

cryptsetup -c aes-xts-plain64 -s 512 -h sha512 plainOpen /dev/sdX cryptroot
то пароли на все остальные будут запршены автоматически(!). Казалось бы, тогда можно элементарно автоматизировать вообще весь процесс, дописав к опции GRUB_CMDLINE_LINUX_DEFAULT в /etc/default/grub что-то типа 
cryptopts=source=/dev/sdX,cipher=aes-xts-plain64,size=512,hash=sha512,lvm=1
и сделав update-grub. Т.е. раз последующие слои матрёшки ловятся автоматически, первый можно внести руками через cryptopts. Однако, на практике оно работает ещё хуже: пароль на самый верхний слой действительно будет запршен автоматически, устройство будет подключено правильно, но пароль на следующие два запрошен будет, их придётся подключать руками (cryptroot_crypt и rootfs_crypt). И только после их подключения загрузка пойдёт автоматически вместе с автозапросами пассфраз на остальные тома. Т.е. в итоге вручную придётся писать две команды вместо одной.

— pgprubot (10/07/2015 19:51, исправлен 10/07/2015 20:11)   

Правда, легко это сделать удаётся не всегда, тут много факторов.


Сделал бэкап системных разделов в tar-файл, потом решил проверить загружаемость, склонировав систему. Создал внешний бессигнатурный слой, внутри LUKS, в нём VG, в её LV, прикрыв LUKS'ом, положил всю корневую ФС. Воссоздавать структуру всех LV не стал, всё кинул в корень; вместо этого отредактировал /etc/{fstab,crypttab}. Первая загрузка шла, естественно, со старым загрузчиком.


Результаты: видимо, всё надёжно встроилось в initramfs, поэтому системе стало пофиг на параметр root=/path/to, передаваемый ядру. Теперь загрузка требует, чтобы имя (target) для внешенего бессигнатурного раздела было тем же (cryptroot1), имя внутреннего LUKS тоже тем же (cryptroot_crypt), это же справедливо и для названия VG (VolumeGroup). В общем, требует, чтобы всё было по-максимуму таким же.


В initramfs-шелле, к счастью, можно переименовать VG. С недостающими, но так нужными initramfs'у иными LV прокатывает такой трюк: их можно прямо в initramfs-шелле создать, отформатировать под LUKS, но ничего туда не класть. Загрузчику достаточно галочки, что устройство найдено и пароль на него запрошен.2 Дальше он передаёт загрузку init'у, где эти фейковые LV всё равно не используются. После успешной загрузки можно сделать update-initramfs -u, update-grub, и всё начинает работать автоматически для новой конфигурации.3


По-видимому, указание опции initramfs в /etc/crypttab — это такой сильный enforcement. С одной стороны, удобно, когда все пароли запрашиваются сразу пачкой, а не размазаны по всему процессу загрузки ОС, но, с другой стороны, подключение initramfs-маунтов будет, что случись, не обойти. Даже если они ему не нужны фактически, он всё равно будет требовать видеть те устройства и пароли на них (к счастью, разруливается фейками).


P.S. Общая динамика процесса положительная: бессигнатурку можно менять, переразбивать, переименовывать, переносить между системами, клонировать, бэкапить, и всё это не так сложно, если приноровиться к ряду глюков и заранее учитывать особенности процесса.


1 cryptroot — это вроде имя по умолчанию, которое присваивается загрузчиком самому внешнему подключаемому криптоустройству, если его параметр не указан дополнительной опцией (т.е. это не мои предпочтения, а умолчания initramfs). Название шифрованного устройства name после расшифрования обычно в руководствах называют name_crypt, хотя это не обязательно. Непонятно, насколько это конвенционально, но мне встречалось много где.
2 Уже не помню, нужно ли нарезать на них ФС. Если нужно, то это в дефолтном initramfs не сделаешь, нужных тулзов там нет, понадобится вторая рабочая система.
3 Вручную в initramfs достаточно будет вводить только одну команду на открытие внешнего бессигнатурного слоя, остальное будет запршено автоматически после exit.

— Yellow (19/07/2015 14:42)   

Спасибо. А вручную задать опции загрузки в стандартном GRUB2 в этом варианте не получится?

Мои, разумеется, поверхностные и дилетантские вопросы связаны с попыткой определиться, в какую сторону копать подробно и тщательно.
— pgprubot (20/07/2015 18:30, исправлен 20/07/2015 18:32)   

Дело же не только в grub2 самом по себе. Кстати, какую-то часть grub'а можно даже пошифровать, но сути это не меняет. Grub должен загрузить ядро Linux и initramfs-шелл, и ядро и initramfs лежат как файлы в /boot. Эти файлы часто обновляются при обновлении системы, т.к. в ядре то и дело находят какие-то ошибки и проблемы с безопасностью. Ядро нельзя загрузить постфактум после загрузки ОС (хотя что-то такое разрабатывали, пытались сделать, но не знаю в каком статусе эти работы), т.е. система работает на том ядре, которое взято из /boot. Если загрузочный носитель статический и никогда не меняется (а каталог /boot находится именно на нём), значит, придётся работать на системе со старым ядром. Это чревато проблемами. Т.е. даже если бы на постороннем LiveCD или ещё где был подходящий загрузчик с подходящим ядром, это всё равно не решало бы всех проблем.


Загрузка происходит как: grub находит ядро и initramfs с /boot, которые лежат на том же носителе, грузит их в память, загружается ядро и потом шелл с утлитами (initramfs). В этом шелле уже можно подмонтировать любой раздел/том с любого носителя, где лежат корневая файловая система и остальные нужные ФС.



На самом деле всё, что обсуждается в этом треде — безумно сложно. Штатно ничего из перечисленного не поддерживается. Со сменой релиза или ОС любая часть инструкции, как это делать, может внезапно перестать работать. Многое определяется экспериментально, потому что если отбросить пафос, очень мало людей настолько хорошо знают загрузку ОС, чтобы вручную её исправить под нужный случай с максимальными гарантиями, что ничто внезапно не отвалится. Linux вообще слишком сложный, слишком overengineered[link34], и каждая часть, которая участвует в загрузке, такая же (grub2, к примеру). По каждой такой части есть мануалы на сотни страниц, отдельные сайты, этому посвящённые, это сотни, а то и тысячи опций, и если в это глубоко влезать, вы моментально попадаете в режимы, которые существуют номинально, но реально их никто не тестировал, т.е. много функций из явно заявленных попросту не будут работать. Вы погрязенете в разбирательстве, в поиске причин, в написании баг-репортов, в вычитывании рассылки... Короче, эта волынка надолго.


Много лет назад был шум по поводу m-o-o-t [1][link35], [2][link36], там хотели нечто подобное сделать. Разработчики пошумели, но так ничего и не сделали (видимо, потому, что это действительно непросто).

— Yellow (28/07/2015 18:59)   
pgprubot,
спасибо за подробное объяснение. Уже ковыряюсь.
— pgprubot (28/07/2015 20:08, исправлен 28/07/2015 20:14)   

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



Шифрование /boot на уровне grub2 здесь когда-то обсуждали [1][link37], [2][link38]. В сети есть мануалы на этот счёт, которые можно поосмыслять [3][link39], [4][link40], [5][link41]. В принципе, эта фича полезная, т.к. ни в какой момент не возникает носителя с незашифрованным ядром и конфигом загрузки, такой штукой стоило бы пользоваться.



Это так называемый Kexec[link42], в новых ядрах он уже должен работать.


Смысл ответа всё же сохраняется: вряд ли есть какой-то более-менее стандартный/распространённый Live-образ, поддерживающий как шифрованние в grub'е, так и последующее выполнение kexec,* чтобы использовать сторонний носитель для загрузки скрытой ОС напрямую.** Тем не менее, в будущем всё может поменяться. Возможно, я чего-то просто не знаю / не понимаю, поэтому сильно зарекаться не буду.


* Хотя я не знаю, что именно нужно для kexec.
** А не готовить загрузочный носитель каждый раз самому, записывая туда образ, а потом затирая его.

— Yellow (29/07/2015 09:43, исправлен 29/07/2015 09:53)   

Пока-что, пройден базовый левел – отработан алгоритм установки системы на неразмеченный хард с бессигнатурным шифрованием с GRUB2 на флешке. Это запускается нормально.


Теперь переходим на второй левел – LUKS внутри бессигнатурного шифрования. Здесь возникла проблема с запуском.


Возьмем crypttab без опций initramfs



Указываем загрузчику опции на лету



Система запрашивает пароль на внешний слой, после чего загрузка останавливается.


Если в crcrypttab указать опции initramfs, то не работают опции, заданные загрузчику на лету. Initramfs долго жует и вываливается в шелл с объяснением, что не может найти /dev/mapper/cryptname. Указание в этом месте каких-либо опций в шелл не помогает.


Использование умолчательного имени cryptroot (с/без опции target=) тоже не решает вопроса.


Будьте добры, где искать затык что делаю не так?

— pgprubot (29/07/2015 16:37, исправлен 29/07/2015 16:59)   

Я такой способ не тестировал, но по отзывам от других, всё так и есть. Если внутри бессигнатурного слоя сразу идёт LVM, то запрос пароля можно сделать полностью автоматическим.



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



Раз это LUKS, шифр и режим уже указаны в заголовке LUKS-тома (в отличие от бессигнатурки), поэтому напишите cryptname_crypt /dev/mapper/cryptname none luks. Дописывать там опции шифра просто бессмысленно.



Так и должно быть. Вы оказываетесь в initramfs-шелле. В нём вы можете сначала проверить, правильно ли вы указали пароль:

cryptsetup luksDump /dev/mapper/cryptname
Если не пишет, что это не LUKS, а возвращает слоты, значит, всё верно.4 Далее подключаете вручную LUKS:
cryptsetup luksOpen /dev/mapper/cryptname cryptname_crypt
Что у вас внутри него? Сразу файловая система с корнем? Тогда набираете exit, и загрузка пойдёт автоматически. Если внутри LVM, делаете
lvchange -ay NAME_OF_YOUR_VOLUME_GROUP
Если корневая ФС внутри LUKS на LVM, то подключите потом и её:
crypsetup luksOpen /dev/NAME_OF_YOUR_VOLUME_GROUP/NAME_OF_ROOT_LV LUKS_ROOT_NAME
а только потом набирайте exit (дальше загрузка пойдёт автоматически). Обратите внимание на опцию root= в grub — она пишет, где находится корневая ФС.


Я бы посоветовал вам написать так в crypttab:

cryptname /dev/sda none cipher=aes-xts-plain64,size=512,hash=sha512,initramfs
cryptname_crypt /dev/mapper/cryptname none luks,initramfs
Потом дописать rootdelay=0 в /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="rootdelay=0 quiet ipv6.disable=1"
чтобы не писать rootdelay=0 каждый раз руками. Потом делаете 
# update-initramfs -u
# update-grub
Загрузочная флешка при выполнении этих команд должна быть подмонтирована в /boot. Команды могут писать некоторые нефатальные ошибки. После этого при перезагрузке система сразу вывалится в шелл из-за rootdelay=0 (эта опция де факто означает «не пытаться искать корневую файловую систему») — нам это и нужно, поскольку автоматически загрузка всё равно не пройдёт, а мы только время потеряем на том, пока автоматика grub'а будет шариться по дискам.


В initramfs-шелле загрузчика вы выполняете вручную (если у вас последний Debian):

cryptsetup -c aes-xts-plain64 -s 512 -h sha512 plainOpen /dev/sda cryptname
и набираете exit. Пароль на внутренний LUKS должен быть запрошен автоматически. Если этого не происходит, при последующей загрузке вместо exit вручную подключаете там же LUKS:
cryptsetup luksOpen /dev/mapper/cryptname cryptname_crypt
и всё остальное, если нужно (LVM, другие внутренние LUKS), а только потом набираете exit. Все LUKS-тома с системными разделами должны быть указаны в /etc/crypttab, чтобы загрузка шла автоматически после выполнения первой команды вручную.


Когда вы дописываете cryptopts=target=... на лету, вы, во-первых, пишете больше букв, чем в команде

cryptsetup -c aes-xts-plain64 -s 512 -h sha512 plainOpen /dev/sda cryptname
потому что там работает какое-никакое автодополнение команд и путей по нажатию Tab, а в редакторе grub'а — нет. Во-вторых, после этого пароль на внутренний(-е) LUKS('ы) не будет запршен('ы). Т.е. вы загрузитесь, подключая всё остальное руками, но объём ручной работы возрастёт, поэтому нет смысла так делать в случае, когда внутри бессигнатурки используется LUKS. Автоматического запроса пароля на всё в этой конфигурации мне не удалось добиться — бессигнатурный слой вы всё равно будете подключать каждый раз руками, причём из initramfs-шелла указанной командой, а не дописывать его опцией загрузчику на лету.



Странно, что оно связано. В принципе, можете опустить initramfs в crypttab для первой строчки, где бессигнатурное шифрование, благо оно всё равно автоматически не подключается, но для последующего LUKS (и других LUKS'ов), если хотите добиться автоматики, указывать опцию initramfs нужно. Если готовы всё и всегда подключать вручную, можете initramfs не писать нигде, но я не вижу смысла так делать.



Как вы его назовёте — это ни на что не влияет. Главное — чтоб было консистентно: одни и те же имена в fstab, в crypttab, в конфиге grub'а и в командной строке initramfs'а.


4 В принципе, это действие избыточно: если внутри не LUKS, т.е. пароль задан неверно, то последующая команда luksOpen вернёт ошибку. В этом случае можете сделать cryptsetup remove cryptname и повторить команду подключения бессигнатурного слоя.

— Yellow (01/08/2015 09:56, исправлен 01/08/2015 10:01)   

Спасибо Вам, разобрался. Теперь работает схема: бессигнатурное шифрование->LUKS->LVM. Параметры внешнего слоя задаются руками в шелле, пароль на LUKS запрашивается автоматом.



А на какой способ Вы указывали[link33]? Моя испорченность толкает меня в плохом направлении?



Какая может быть наиболее эфективная логическая форма для такого затираемого носителя с учетом проделываемых манипуляций?

— pgprubot (02/08/2015 05:29, исправлен 02/08/2015 06:36)   

Поздравляю! У меня к вам тоже вопрос: при инсталляции вы создавали загрузочный носитель с /boot на нём, так? Т.е. указывали в инсталляторе, что сделать загрузочным /dev/sdb какой-нибудь. Система начала сразу с него грузиться? Или вам понадобилось сначала каким-то образом искуственно загрузиться во вновь инсталлированную ОС, чтобы сделать update-grub, реинсталлировать mbr и т.д., что требует полноценного chroot'а с пробросом всех девайсов и системных ФС?



Я имел в виду, что LUKS внутри бессигнатурного шифрования в моих экспериментах был всегда. Внутри LUKS, понятное дело, всегда был LVM. Более простые схемы, на мой взгляд, не удовлетворяют минимальным необходимым требованиям, поэтому я их даже не тестировал, хотя знакомился с результатами других людей. Точнее говоря, более простые схемы я тестировал, но то был не Linux, и там вообще отдельный разговор.



Вам виднее. Когда человек делает явные ошибки в настройке — например, неосознанно ослабляет безопасность (на своём техническом уровне заморочек и неудобств), на это можно указать. Однако, есть более тонкий случай, когда нечто вносится или выносится в/за рамки модели угрозы. Это можно быть, на мой субъективный взгляд, как обоснованно, так и неоправданно. Обычно по мере повышения осведомлённости о том, как легко получить доступ к системе, человек старается учесть как можно больше моделей угроз, даже если нет иных причин считать себя ставшим более лакомой целью для атакующих.


Мне, например, неинтересно копировать то, что уже сделано другими. Куда более интересно (да и актуально) попытаться сделать защиту от того, от чего ещё никто (во всяком случае, массово) не делал. Я стараюсь внести в модель угрозы cold boot и иные способы получения информации с работающего компьютера. До этой новости[link45] и последующих улучшений[link46] атаки об этом мало кто задумывался, но сейчас вопросы типа таких[link47] — скорее, норма (кстати, Tails это умеет [1][link48], [2][link49]).


Обычно для защиты от cold boot предлагаются разные красные кнопки, физическая охрана помещений и сейфы с детектором вскрытия. Всё это хорошо, но, во-первых, сильно завязано на человеческий фактор, а, во-вторых, крайне неудобно. Для работы с информацией требуется отдельное помещение с контролем входящих, специально оборудованное рабочее место, бункер, что в современном мобильном мире ноутбуков и планшетов обычно реализовать невозможно.


Главное осознание — то, что полнодисковое шифрование само по себе по сути ни от чего не защищает. Точнее, оно хорошо защищает от конкретной угрозы: расшифрования диска, отключенного от компьютера и лежащего в шкафу. Бессигнатурность такого диска даёт некоторую отрицаемость, если ею правильно пользоваться. А бессигнатурность диска, с которого вы постоянно работаете — совсем другое. Ключи на его расшифрование постоянно загружены в оперативную память, да ещё и в развёрнутом виде, который устойчив к потери памятью напряжения и к частичному искажению данных.


Большинство специалистов скажут, что проблема нерешаема: либо вы смиряетесь со сложившимся положением дел, либо строите бункер создаёте охраняемое помещение со всеми нужными атрибутами физической безопасности (заодно и защиту от TEMPEST'а можно предусмотреть). Тем не менее, кое-что бюджетное сделать можно, если вспомнить, что


  1. Мастер-ключи в оперативную память можно как загружать, так и удалять.
  2. Для надёжного удаления информации с LUKS-раздела достаточно сделать luksKillSlot [и затереть заголовок (опционально)].

Идея простая: мы все файловые системы (ФС) делим на несколько классов:


  1. Те, которые неизбежно должны оставаться подключенными, если компьютер работает.
  2. Те, которые нужны почти всегда, но не необходимы для работы компьютера и выполнения административных действий (например, юзерский $HOME).
  3. Те, которые нужны только иногда (ФС с теми или иными данными).
  4. Те, которые нужны крайне редко или требуют особых мер предосторожности.

Каждая файловая система должна быть привязана к своему LUKS. Типичная работающая система содержит подключенными все ФС класса А, класса B и несколько ФС класса C.


  • Класс A — это системные ФС (корень, /var и т.п.).
  • Класс B — $HOME юзер(а,ов), под которым(и) вы обычно что-то делаете.
  • Класс C — ФС с данными, которые могут быть как нужны, так и не нужны — это файлы по работе, музыка, видео, почта, IM, т.е. всё, что угодно. Например, если в данные часы вам нет необходимости проверять или читать почту, зачем держать LUKS-том с почтой подмонтированным? Вы его отключаете, делая luksClose. В случае атаки на зугруженную систему злоумышленник не сможет получить доступ к вашей почте, если только он не узнал ваш пароль каким-то иным способом (TEMPEST, видеокамеры, утечки по акустическим и др. каналам).
  • Класс D — это, например, ФС с бэкапами или с приватными PGP-ключами (речь о главных ключах, а не подключах).

Какие принимаются меры для противодействия утечкам? Первая и очевидная — это, конечно, не подключать больше ФС, чем вам нужно в данный момент. Вторая — не подключать ФС, требующие повышенной безопасности, в тех публичных местах, где всё совсем плохо с физической безопасностью компьютера. Третья — время от времени очищать ФС от старых данных. Четвёртая — систематическая зачистка тех ФС, которые являются буферными, и где постоянно возникают непредвиденные данные. На последних двух мерах стоит остановиться подробнее.


Как очистить ФС от старых данных? Представим, что всё хранится на одной ФС: система, $HOME и всё остальное, размер может идти на сотни гигабайт. Чтобы её очистить, надо удалить ненужные данные, отредактировать требующие того файлы, а потом перенести всё оставшееся куда-то на временный раздел. Потом надо сделать luksKillSlot на исходном LUKS, не нём же сделать luksFormat, снова создать ФС и вернуть все данные обратно на место. Нетрудно догадаться, что процедура будет небыстрой. А если конкретный LUKS к этой ФС вообще не привязан, то вместо luksKillSlot придётся перезаписывать весь логический том LVM случайными данными.


Однако, если разобраться, у вас обычно возникает желание подчистить ФС только в каких-то конкретных директориях. Например, это может быть /var, где много всего сохраняется в /var/log, а не весь корень. Мы выносим /var на отдельную ФС, цепляем её к своему LUKS, которая находится на каком-то логическом томе (LV). Теперь при необходимости почистить /var будет быстро и легко. Аналогично на свой LUKS можно повесить корневую ФС. Вообще все группы данных должны находиться на своих ФС внутри своих LUKS, а эти LUKS'ы — на своих LV. Это даёт гибкость. Легко можно удалять данные какого-то типа или просто частично очищать их. Конечно, есть и минусы: чем больше LUKS'ов, тем больше паролей надо вводить на каждый чих и при загрузке компьютера, а чем чаще вы их вводите, тем, при прочих равных, легче их перехватить.


Что касается системных разделов, я остановился на такой схеме: нужны 4 ФС: под корневую систему, под /var, под системных юзеров (root и служебный) и под служебные скрипты с данными. С первыми двумя ФС всё понятно, с остальными могу пояснить. Первое требование — полный отказ от su, sudo и их удаление из системы. Второе требование — работать под рутом нужно из иксов, т.к. только в этом случае легко сделать блокирование всех дисплеев[link50], где запущены X-сервера и залогинен какой-то из юзеров, по хоткею. Третье требование — не держать ФС, где лежат некоторые скрипты по монтированию и зачистке ФС, постоянно подключенными, поскольку они нужны не так часто и содержат информацию, которая потенциально может ослабить отрицаемость. Далее:

  • Создаём LUKS на LV, делаем ФС на нём и монтируем её, например, в /home/home_extra. Делаем домашней директорией служебного юзера /home/home_extra/service, а домашней директорией рута — /home/home_extra/root. Оба хоума юзеров будут на одном LUKS. Кладём туда те данные и скрипты, которые допустимо раскрыть при cold boot. Для остальных скриптов создаём отдельную директорию /home/home_extra/service/extra, куда будет монтироваться отдельная ФС со своим LUKS [такой метод разделения данных[link51] не слишком безопасен, но в данном случае приемлем].
  • На lo запускаем sshd, даём доступ к root-аккаунту для служебного юзера по SSH-ключу.
  • После загрузки системы, запускается необходимое количество X-серверов на разных дисплеях. Логинимся в каких-то иксах под служебным юзером, оттуда получаем рута по SSH — так это работает.

Служебный юзер не имеет непосредственного доступа в сеть и не используется ни для чего, кроме редактирования конфигов, доступных ему для редактирования, и работы под рутом. При должной автоматизации при логине в иксы терминал и SSH в рута в нём запускаются автоматически. Ввели пароль в xdm — получили root-консоль. Можно было бы логиниться непосредственно под рутом, но тогда пришлось бы под ним запускать такую сомнительную и дырявую иксовую программу, как xscreensaver, что явно не хотелось. В данном случае всё осталось чистым: терминал, оконный менеджер и xscreensaver запускаются с правами обычного пользователя.


Последнее пояснение — по четвёртому пункту, зачистке буферных ФС. Допустим, мы сделали отдельного юзера для пользования браузером. Из интернета скачивается какая-то информация, сам этот юзер через браузер легко может быть скомпрометирован, а в его $HOME постоянно попадает множество данных, нежелательных к раскрытию. Мы его цепляем на свой LUKS и логинимся в этого юзера в отдельных иксах. Информацию, которая в данный момент нужна юзеру для работы, можно каждый раз под рутом копировать с других файловых систем (к примеру, пароли к сайтам), а потом тут же удалять. Под самим юзером ничего постоянно не храним кроме того, что ему нужно — конфигов браузера, шелла, оконного менеджера и т.п. минимума. Когда этого юзера настроили (при отключенном доступе к сети), его домашняя директория бэкапится на другой LUKS-раздел. Поработали с какими-то сайтами, что-то сделали — удалили домашнюю директорию Tor Browser'а и восстноавили её с чистого бэкапа. Хочется большей чистоты — разлогинились из-под юзера и выполнили скрипт, который удалил все данные в его $HOME и восстановил его содержимое с чистого бэкапа5 (перед этим все нужные данные можно перенести на другие «перманентные» LUKS-разделы). Наконец, захотелось полной чистоты с защитой от cold boot — отмонтировали его $HOME, сделали luksKillSlot, luksFormat и восстановили $HOME# с бэкапа. Чтобы этим было удобно пользоваться, пишутся скрипты. Разлогинился, переключился в рута, выполнил одну команду — и через 5 секунд $HOME абсолютно чист, можно снова логиниться и продолжать работать. Очень удобно. По этому же принципу можно регулярно зачищать разделы, где лежат все данные для IM (конфиги, история сообщений). Выполнил один скрипт с luksKillSlot — и всё, никто не восстановит историю переписки. Другими словами говоря, раз нельзя защитить данные, можно хотя бы минимизировать их утечку — при cold boot атаке на систему злоумышленник получит только то, что попало в те ФС после последней их зачистки (а эта зачистка проводится регулярно).


Примерно так это всё может работать. Если потратить время на автоматизацию процесса, работать будет ещё и комфортно и безопасно. Полезно иметь скрипты для проверки статуса системы, которые показывают, какие ФС из не необходимых подмонтированы, какие LUKS из ненеобходимых подключены, какие процессы запущены, что интересного пишется в системных логах. Одна команда, выполняемая время от времени, даёт информацию о статусе системы и происходящем: можно вовремя отключить лишние LUKS'ы и/или вовремя среагировать на инцидент.


Кстати, если хотите поменять что-то в своей конфигурации на то, что здесь выше описано, скорей всего, можно обойтись без реинсталляции: грузитесь в какую-то третью систему, создаёте бэкап корневой файловой системы с помощью rdiff-backup, потом создаёте в своём LVM нужного размера логические тома, форматируете их под LUKS, создаёте файловые системы на них и восстанавливаете туда системные файлы с rdiff-backup. Потом при загрузке можете поменять значение опции root=/path/to на правильное, загрузиться (с проблемами, но обычно можно найти способ, см. выше), отредактировать fstab и crypttab, сделать update-initramfs -u и update-grub (старый образ загрузочного носителя куда-то сохраните на всякий случай). Можно даже добиться того, что у вас будет несколько ОС внутри LVM, и, выбирая нужный образ для загрузочного носителя, вы сможете автоматически грузиться в ту или иную из них.


Общая схема: внутри бессигнатурки на весь диск лежит LUKS, внутри LUKS — LVM (т.е. тоже на весь диск), логические тома которого — тоже LUKS'ы, внутри которых нарезаны ФС. Часть этих LUKS'ов с ФС предназначена для системных директорий, а другая — для прочих юзерских данных.


Я взял cold boot как пример получения доступа к загруженной системе, но всё описанное одинаково хорошо работает и против других атак, приводящих к чтению содержимого оперативной памяти и/или всего диска, начиная с уязвимостей через firewire-порт, через PCI-слоты (чтение ОЗУ) и заканчивая банальным «забыл заблокировать экран, поэтому злоумышленник получил доступ к root-консоли».


Начиналось всё с банальной проблемы типа такой: я иду на работу и хочу, чтобы на работе было доступно/подмонтировано только то, что нужно для работы и её непосредственно касается. Казалось бы, нет ничего проще: устанавливаем вторую ОС, из-под которой будем заниматься только работой. Однако, во-первых, это неудобно (на каждую задачу инсталлировать свою ОС), во-вторых — нет полноценной изоляции (если что-то понадобилось из сервисов/данных с другой ОС, каждый раз перезагружаться?), и, в-третьих, — в рамках самой работы тоже есть данные разного класса, не всё и не всегда стоит держать подключенным/подмонтированным. Т.е., намного удобней иметь единый гибкий своего рода фреймворк, из которого подключением/отключением нужных ФС (LUKS'ов) делать ту конфигурацию, которая нужна в конкретный момент. В идеале в некоторых LUKS'ах стоит держать собственные гостевые ОС, что позволяет убрать доступ к информации об основной (хостовой) ОС и железе, на котором она запущена.



Может быть, физическая, а не логическая? Честно говоря, не понял вопрос.


5 Пример скрипта:

#/bin/sh
 
# USER is username of your user. Below replace USER everywhere with
# necessary username: %s/USER/your_username/g
 
our_mount_info=$(mount |grep '/dev/mapper/USER_crypt on /home/USER' \
    |cut -d ' ' -f1-3)
our_mount_target='/dev/mapper/USER_crypt on /home/USER'
 
if [ -h /dev/mapper/USER_crypt ] ; then
    if [ "${our_mount_info:-nonexisting}" = "$our_mount_target" ] ; then 
        if ! ps -UUSER > /dev/null ; then
            if [ -d /tmp/USER ] ; then
                rm -R /tmp/USER && \
                echo /tmp/USER removed
            else
                echo /tmp/USER does not exist, therefore I don\'t remove it
            fi
            set -x
            find /home/USER -mindepth 1 -delete && \
            # EDIT IT:
            rdiff-backup -r now /path/to/backup/USER /home/USER && \
            set +x
            echo ' '
            # Let us see everything together:
            df -h |grep USER && \
            ls -laFh --color /dev/mapper |grep USER_crypt && \
            ls -laFh --color /home/USER |sed '1s/total.*$/ /'
        else
            echo There are processes of USER:
            ps aux -ww |grep -v \"grep\" |grep USER
        fi
    else
        echo USER_crypt is not mounted in proper place
    fi
else
    echo USER_crypt does not exist
fi
Проверяем, подключен ли его LUKS-раздел, туда ли он подмонтирован, все ли процессы от того юзера завершены. Если ответ на все три вопроса — «да», выполняем процедуру и выводим нужную диагностику. Предполагается, что некоторые временные файлы создаются[link50] в /tmp/USER.

— Yellow (08/08/2015 16:08, исправлен 08/08/2015 16:26)   

Вас читать – как энциклопедию. В очередной раз – спасибо за огромное количество нужной инфы.



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


Удалось убидиться, что поняв логику и метод инсталляции конкретного дистра, можно довести установку через инсталлятор до любого желаемого конца в один присест/заход/проход. Зная процесс установки, можно после исполнения инсталляционного скрита, еще до рестарта системы, при необходимости, чрутиться в только-что установленную систему и исправлять нужные конфиги, создавать всякие "инитрамы", итд. (если, например, инсталлятор не умеет дописывать нужное в crypttab/fstab). И система сразу запускается.


Но, честно говоря, сегодня мне уже думается, что самое простое это установить голую систему на отдельный носитель, перенести ее на нужные разделы, полечить нужные моменты через чрут. (О возможных проблемах с безопасностью помним.)


А вообще – да, даже если инсталлятор "сопротивляется", ему все-равно можно "объяснить", что /boot будет на отдельном носителе.


По поводу cold boot, который и меня напрягает. :-) Скажем так, типа proof of concept :-) ?



sdmem[link52]


Еще лучше было бы как-то извратиться и позакрывать вообще все устройства и только потом вайпить. Может быть было бы правильно засунуть это в какой-то системный скрипт выключения системы?



Если не ошибаюсь, то на внешнем загрузочном носителе должны быть MBR+GRUB+{содержимое /boot}. Это можно как-то упростить?


Пытаюсь разобраться подробнее с поцессом загрузки. Последовательность загрузки, вроде бы, такая (если с BIOS'ом):


BIOS -> MBR -> GRUB -> итд.


Разве нельзя взять более-менее подходящий Live-CD и воспользоваться опцией из его меню, вроде "Boot from HDD"? Тогда удалось бы избежать необходимости предварительно копировать загрузочные данные на флешку.


По поводу kexec[link53] есть еще такая инфа[link54].

— pgprubot (09/08/2015 15:04, исправлен 09/08/2015 15:28)   

Спасибо. Всё описывать с объяснением, что и почему — это надо писать чуть ли ни книгу, но к концу её написания выяснится, что половина надо переделать или улучшить. Безопасность — это никогда не кончающийся процесс, а не состояние. © Практически всё, что здесь описывается, ранее уже озвучивалось разными людьми на форуме, вопрос лишь в сборке этого в нечто связное или в отсылке к обсуждениям, ранее имевшим место.



Возможно:


В[link55] принципе, если собираете что-то параноидально-кастомное, то поставьте систему с обычным шифрованием, а с неё вручную поставьте на флэшку что нужно. Есть и куча всяких средств для создания своих дистров, клонирования конфигов и пр.

Но если уже разобрались, как лечить бессигнатурку,6 это будет немного быстрее.7



Могу поэкспериментировать, но я никогда не разбирался с системой завершения работы ОС. Мне казалось, что он не даст отмонтировать системные разделы, либо, если даст, то никакие новые команды выполнены быть не могут, потому что исполнимые файлы были на них. Наверно, это как-то обходится, но не изучал, как. Если системные разделы не отмонтированы и их LUKS'ы не отключены, vgchange -an он тоже не даст сделать. Своп пока что вообще никак не использую.



Эта утилита тут ранее обсуждалась [1][link56], [2][link57], но у меня она вызывает ряд вопросов.


sdmem is designed to delete data which may lie still in your memory (RAM)

The wipe algorythm is based on the paper "Secure Deletion of Data from Magnetic and Solid-State Memory" presented at the 6th Usenix Security Symposium by Peter Gutmann, one of the leading civilian cryptographers.

Тем временем, вот что[link58] пишет сам Гутман. Т.е. множественные перезатирания памяти уже давно не имеют смысла даже для HDD,8 а для немагнитных технологий записи (SDD, флэшки, RAM) это всё вообще сомнительно. Зачем перезаписывать RAM много раз, да ещё и случайными данными?


Wiping the memory is very slow. You might use sdmem with the -ll option. (tip)

Я так понял, что оно «slow» только потому, что использует /dev/urandom — именно это ограничивает его скорость.9 Однако, urandom нужен там, где нужен именно PRNG. Для затирания данных вполне достаточно гаммы шифрованных нулей[link12]. Вместо того, чтобы играться с числом проходов, автору следовало бы имплементироваать этот способ.


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



Да. Штатный скрипт окончания работы, конечно, внешние LUKS'ы не отключает, поэтому есть как шансы, что соответствующие мастер-ключи остаются в RAM, так и шансы, что они не перезатираются при последующей загрузке системы. Если есть возможность, может помочь тотальное обесточивание системы (как вариант, вынуть батарею).



С этим надо разбираться. Если бы у вас получилось это сделать с пониманием, а потом здесь описать, было бы очень неплохо.



LiveCD загрузит grub, а grub должен загрузить ядро, но откуда он его возьмёт? Grub поддерживает LUKS, но не знаю, насколько полноценно. Допустим, grub позволяет подключить бессигнатурно шифрованное пространство на диске и выудить оттуда ядро и initramfs, тогда всё сработает. Для этого нужно:


  1. Grub на вашем LiveCD должен содержать cryptsetup. Обычно, как я понимаю, grub устанавливают без поддержки соответствующего модуля.
  2. Поддержка cryptsetup должна быть достаточно полноценной, чтобы подключать /boot с того же бессигнатурно шифрованного носителя, где находится и сама операционная система.
  3. LiveCD не должен привлекать внимание: он не должен быть самосборным, кастомным, ещё каким-то специфическим.
  4. Если всё получится, в нагрузку к тем командам, которые приходится вручную набирать в initramfs-шелле, придётся ещё и набирать что-то в командной строке grub'а.

Мне положительное решение вопросов 1-3 априори кажется маловероятным, поэтому я предложил более реалистичный промежуточный вариант: предварительную запись загрузочных данных на флэшку, но с шифрованным grub'ом.



Этот загрузчик тут не раз обсуждался [3][link59], [4][link60], [5][link61], [6][link62], [7][link63], [8][link64], но я с ним не разбирался, чтоб как-то прокомментировать его полезность для обсуждаемых целей. Во всяком случае, если речь идёт о полноценной замене grub'а, то в пользу последнего говорит то, что он штатный в рамках инсталлятора и системы обновлений (вместе, например, с lilo и syslinux). Если брать что-то совсем постороннее, могут сломаться[link65] обновления ядра через apt-get upgrade. Конечно, всё можно исправить или научиться делать вручную, но не хотелось бы лишний раз усложнять себе жизнь без реальной на то необходимости.


6 Т.е. если устанавливалось сразу на бессигнатурно шифрованный диск.
7 Т.е. загрузиться с чего-то, потом выйти в chroot и быстро «полечить» систему.
8 Изначально они было нужны из-зза того, что по остаточной намагниченности в лабораторных условиях определялся исходный заряд ячейки.
9 Сама скорость записи в RAM очень большая.

— pgprubot (12/08/2015 21:52, исправлен 12/08/2015 22:14)   

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


Я так понимаю, в процессе завершения работы ядро получает некий сигнал, переходит на иной runlevel, выполняются определённые скрипты останова, а потом ядро уже само должно прибить оставшиеся LUKS'ы и маппинги. В принципе, это всё задокументировано, можно начать с гугления, man shutdown, man inittab и далее по ссылкам.



Как и все наколеночные абстракции, эта тоже протекает. Рут в этой схеме является единственным пользователем, который может спокойно перебрасывать файлы из одного юзера в другого. Следовательно, информация о файлах остаётся в истории комманд шелла. В некоторых случаях можно нечайно создать[link66] файл логов screen (screenlog.0) или hardcopy[link67], т.е. всё содержимое терминала при нечайном нажатии внезапно оказывается на не так часто затираемой файловой системе. Если нужные шеллы screen не закрыть, введённые команды и информация о файлах (какие-нибудь cp -iv file1 file2) остаются в его буфере — можно отмотать несколько экранов в терминале назад и посмотреть. У самих терминалов тоже есть история буфера. Всё это легко может привести к тому, что разделы отомонтированы, пассфраза удалена, файлов нет, но информация о них продолжает где-то висеть и оставаться доступной, даже sdmem против таких утечек бессилен.


Конечно, если каждый раз стирать все временные файлы и разлогиниваться из-под рута, проблема кажется решаемой, но это лишнее неудобство и лишняя завязка на operational security — забыл сделать одно действие из множества нужных или поленился, и гарантированной защиты уже нет.

— Yellow (14/08/2015 13:02)   

Я так понимаю, что, например, в Tails система в конце выключения перед запуском sdmem (или аналога) перезагружает новое ядро с помощью kexec.
— pgprubot (15/08/2015 17:29, исправлен 15/08/2015 17:31)   

Видимо, да:


F[link68]irst, the memory erasure process is triggered at the end of a normal shutdown/reboot sequence. This is implemented by slightly modifying the System V initscripts shipped by the kexec-tools Debian package: the kexec-load initscript, that normally only runs at reboot time, is enabled to run at shutdown time as well. A custom tails-kexec initscript replaces the kexec one in order to support the case when the boot medium is not available anymore at the time this script runs; it also provides an improved user interface more suitable for Tails target users needs. Finally, the standard Debian halt and reboot initscripts are taken over by having the tails-kexec initscript run before they have a chance to be run (implemented with Required-Stop in the LSB headers).

Я не уверен, что безопасную очистку памяти нельзя сделать без kexec. Главное — удалить ту информацию в RAM, которая может содержать какие-либо юзерские данные.


Ещё в тему:


М[link69]не озвучивали мнение о том, что в Linux'е ядро зануляет фоново оперативную память (так ли это?), что уменьшает опасность утечек при доступе к оперативке постфактум, но насколько быстро идёт процесс стирания для реальных данных после реальной работы (поглядел документ, посмотрел фильм, послушал музыку) — не ясно.

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

— pgprubot (17/08/2015 13:56, исправлен 17/08/2015 13:58)   

Он ещё и новые утечки добавляет. К слову о скрытии процессов от других пользователей[link71] и разделении информации между пользователями: после выполнения sdmem ядро ругается на нехватку памяти, записывая в dmesg список текущих выполняющихся процессов и их параметры, а dmesg и т.п. логи* по умолчанию доступны для чтения всем пользователям системы.


* /var/log/{debug,dmesg,kern.log,messages,syslog} — содержимое этих файлов во многом дублирует друг друга.

— Yellow (18/11/2015 13:16, исправлен 18/11/2015 13:38)   

Хотелось бы вернуться к вопросу загрузочного носителя. Выше говорилось





На внешней загрузочной флешке должны быть MBR+GRUB+{содержимое /boot}. Всех данных от силы пол-гига. В crypttab и fstab указаны UUID-ы, в том числе и загрузочного носителя, поскольку это упрощает практическую жизнь.


Пусть размер флешки 1Г. Копирование каждый раз всей флешки с помощью dd и последующее ее затирание – муторное дело.


Будьте добры, как можно повысить эффективность процедур, но так, чтобы при этом у флешки не поменялся UUID?

— pgprubot (20/11/2015 15:00, исправлен 20/11/2015 15:03)   

Слишком много. На самом деле, их около 60 MB.



В crypttab — нет. В fstab UUID указан только для /boot, но и тут можно поменять на /dev/sdb1, например. А можно вообще эту строчку убрать из fstab, и каждый раз, когда нужно, монтировать /boot руками.


Другое дело — что UUID прописан и в initramfs на той самой флешке, с которой грузится система. В момент загрузки система ещё ничего не знает про crypttab и fstab, ей всё равно. Вот там поменять UUID — да, уже тяжелей. Я какой-то раз игрался, но не получилось. Правда, реальной необходимости его менять нет. Если вы делаете dd, UUID устройства не меняется.



Если изначально использовался компактный носитель для /boot, расширить его потом будет легко. Сузить уже существующий — сложнее, я этого никогда не делал, могу дать только теоретические советы. У меня полное затирание носителя занимает несколько десятков секунд, что вполне можно потерпеть.


Если в теории... могу выдать такие советы. UUID есть у устройств (/dev/sdb, /dev/sdb1) и у файловой системы. grub2 слишком умный. Скорей всего, если хоть один из UUID'ов поменяется, он откажется грузить систему.


Соответственно, есть 2 пути: либо назначать UUID'ы всем устройствам вручную, либо взять готовый образ и переделать его так, чтобы UUID'ы не поменялись. Первый способ более правильный, если получится. MBR можно будет перенести с помощью dd, всё остальное — через стандартные инструменты типа rdiff-backup и fdisk.


Второй способ тупее, но может оказаться проще. Я бы попытался как-то так:

  1. Снимаем образ с загрузочного носителя в файл посредством dd.
  2. Ищем способы сделать shrink (уменьшить размер) для файловой системы FAT, которая на /dev/sdb1 (но работаем сейчас не с носителем, а с образом). Есть утилита fatresize, но не уверен, что она это умеет. Вопрос в сети обсуждался, гуглите, результаты я после беглого чтения не понял.
  3. После уменьшения размера ФС уменьшаем размер (DOS'овского) дискового раздела на флешке. (Процедура аналогично ужиманию файловых систем на LVM: уменьшается ФС, потом ужимается LV, потом ФС расширяется до размеров ужатого LV).
  4. Когда всё ужали, как надо, таблица дисковых разделов будет исправленой. Осовбодившееся место можно будет просто выкинуть из таблицы разделов (fdisk).
  5. Берём dd и читаем нужное число секторов с образа — чтобы захватить только то пространство, которое адресовано новой таблицей разделов.
  6. Считанное число секторов в п.5. записываем в файл — это новый «ужатый» загрузочный образ.

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


Есть ещё один способ, куда более тупой. Поскольку на носитель записывается и затирается меньше 100MB каждый раз, вы можете затирать не всего его, а только его часть. Затирание, таким образом, будет не столь надёжным, но его надёжность можно будет на каком-то уровне проверить экспериментально — выяснить, меняются ли данные при записи dd в конце носителя (точнее, за тем пространством, которое вы затираете).

— Yellow (29/11/2015 16:03, исправлен 29/11/2015 16:04)   

Спасибо. Вашей развернутой инфой обязательно воспользуюсь, т.к. назрела необходимось переделки всей системы по практическим причинам. В настоящий момент пришлось воспользоваться самым простым и тупым способом из предложенных:



Копировалось, затиралось и восстанавливалось с помощью dd первых 100MiB данных, которые уверенно включают MBR и /boot (и одновременно помнить цифру 100 просто). Затирание производилось как с помощью /dev/zero, так и с помощью /dev/urandom.


При всех указанных операциях, данные после первых 100MiB не изменяются. Проверялось командой



После восстановления данных с помощью dd, UUID не изменяется, как Вы и указывали.

— Yellow (03/12/2015 11:49, исправлен 03/12/2015 12:22)   

Читая форум, решил попробовать упростить схему бессигнатурки. Сейчас схема такая: бессигнатурно шифрованный хард, внутри которого LUKS, разбитый на LVM-разделы. Какие чисто пользовательские подводные камни возникнут, если сделать по-другому, как в заметке[link75] – на харде будет прямо LUKS (с LVM или без, без разницы), заголовки которого вынесутся на внешний носитель, где уже есть MBR и /boot?

— pgprubot (04/12/2015 14:28, исправлен 04/12/2015 14:58)   

Хорошо, но лучше, если вы этот способ будете применять не к флэшкам, SSD-дискам или SD-карточкам, а к обычным HDD-дискам (например, подключаемым по USB), поскольку частичное затирание данных достаточно надёжно (для современных используемых носителей) только для последних. Иначе говоря, если есть HDD, который можно использовать только как загрузочный диск, это хорошо, он и затраться будет быстрее флэшек.


То, что ничего за пределами первых 100MiB не меняется, следует, как я понимаю, из особенностей таблицы разделов, располагающейся в начале диска, и файловой системы FAT. Если бы вместо FAT было бы что-то менее примитивное, скорей всего, как минимум, была бы ругань ОС на обрезанную файловую систему. Не знаю, как NTFS, но типичные UNIX'овские ФС пишут так называемые суперблоки в разных местах ФС при её создании, т.е. нет такого, что за пределами какого-то объёма точно нет служебных метаданных.



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



Сначала комменты по поводу самой заметки:


It is absolutely NOT POSSIBLE to decrypt the LUKS device without the header because of the SALT in it. No known technology could decrypt the device without the SALT. That’s a very strong cryptographically NOT POSSIBLE. It would take something far beyond quantum computing.

Автор путает тёплое с мягким. Соль, хидер, LUKS — это всё инструменты для вывода мастер-ключа. Если КК будет брутфорсить просто AES как алгоритм, т.е. сам мастер-ключ, ему всё равно, откуда он взялся. Если следовать рекомендациям АНБ[link76], нужно крутить режимы, а хидеры ни на что не влияют. AES-128 на КК превращается в 64-битный шифр, и это плохо. Чтобы было хорошо, нужно брать AES-256 и 256-битный случайный ключ в качестве пароля. С точки зрения опций, это те самые -c aes-xts-plain64 -s 512 -h sha512.


cryptsetup luksFormat /dev/sda --header /dev/sdb --align-payload=0

Во-первых, автор, кажется, не совсем понимает смысл команды luksFormat. Во-вторых, --align-payload=0 должно нормально заработать только в 1.6.7[link77], а в более ранних версиях эта опция попросту игнорируется.


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


В принципе, вот это должно бы работать (даже с несуществующим файлом tmpLUKS):

# cryptsetup -q -c aes-xts-plain64 -s 512 -h sha512 --header /tmp/tmpLUKS luksFormat
но синтаксис cryptsetup'а этого не позволяет. Эта команда могла бы создавать файл tmpLUKS и записывать туда LUKS-хидер. Можно создать пустой файл tmpLUKS и/или в конце команды указать /dev/null как фейковое целевое устройство для шифрования, но это тоже не помогает. Думаю, разработчиков LUKS можно было бы убедить в том, что такое поведение cryptsetup'а нелогично.


Рабочий метод есть, и он примитивен:

# dd if=/dev/urandom of=/tmp/tmpLUKS bs=1M count=5
# cryptsetup -q -c aes-xts-plain64 -s 512 -h sha512 luksFormat /tmp/tmpLUKS
# cryptsetup --header /tmp/tmpLUKS luksOpen [устройство] mydevice_crypt
Т.е. в случае автора было бы достаточно написать
# cryptsetup luksFormat /dev/sdb
вместо
# cryptsetup luksFormat /dev/sda --header /dev/sdb --align-payload=0


Я взял 5MB для файла с хидером, что было с запасом, потому что размер хидера может отличаться в зависимости от версии cryptsetup'а. Когда хидер на файле уже создан, его можно ужать до актуального размера с помощью команды luksHeaderBackup:

# cryptsetup luksHeaderBackup /tmp/tmpLUKS --header-backup-file /tmp/pure_header
Файл pure_header короче; он будет занимать, скорей всего, 2MB. Далее можно пользоваться уже только им в качестве опции для --header.


Идём далее. Следующая команда по ссылке:

# cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y --header container.h \
  --align-payload=0 container

С учётом вышеприведённых замечаний она эквивалентна такой:

# cryptsetup -c aes-xts-plain64 -s 512 -h sha512 -y \
  --align-payload=0 luksFormat container.h
причём --align-payload=0, скорей всего, тоже можно убрать.


Следующие команды:

# losetup /dev/loop0 container
# cryptsetup luksOpen /dev/loop0 --header container.h cont

Это усложнение (первая команда) просто не нужно — cryptsetup сам догадается рассмотреть файл как блочное устройство, поэтому можно писать напрямую:

# cryptsetup --header container.h luksOpen container cont
Соответственно, не нужны и команды losetup -d потом. Кроме того, вместо luksClose в современных версиях cryptsetup можно писать remove — тип устройства он определяет сам.



Теперь вернёмся к самому вопросу. Да, метод правильный и логичный: вместо двойного шифрования просто пользоваться откреплённым хидером. Думаю, его можно было бы класть отдельным файлом в /boot. В крайнем случае, можно было бы создать отдельный дисковый раздел на загрузочном носителе, и класть хидер туда в виде файла (или сам этот дополнительный дисковый раздел использовать как хидер).


Проблемы могут быть только в автоматизации процесса и в установке системы на такую конфигурацию. При установке внешний бессигнатурный слой всё равно создавался вручную (см. пункт 3[link78]), поэтому отличий не будет — точно так же в командной строке создаём и устройство и хидер. Понятно, что в crypttab инсталлятор вряд ли догадается прописать хидер, поэтому первая загрузка будет в ручном режиме с указанием всех опций cryptsetup'а из командной строки grub'а, но потом можно будет crypttab подправить на нужный — вдруг можно добиться автоматической загрузки и для такой конфигурации? Первая строчка crypttab'а должна быть, думаю, какой-то такой:

cryptroot /dev/sda none header=/dev/sdb2,luks,initramfs
если загрузочное устройство — /dev/sdb, /boot находится в /dev/sdb1, а раздел /dev/sdb2 содержит LUKS-хидер. Если хидер в файле в /boot, может быть, надо писать header=/boot/header_file, но это надо проверять, т.к. я не уверен, что на стадии командной строки grub'а /boot уже есть и подмонтирован в этот каталог.


Последнее, на что стоит обратить внимание — опция --align-payload. Если она везде указывалась в версии 1.6.6, оффсет будет всё равно ненулевой (и если не указывалась, то тоже). Потом вы обновляете систему и получаете cryptsetup 1.6.7, где опция трактуется правильно — соответственно, автоматическая загрузка сыпется, всё перестаёт работать. Конечно, указанием правильного значения для --align-payload всё можно будет поправить, чтоб работало, как и раньше, но учтите этот подводный камень — можете в будущем об него споткнуться.

— Yellow (31/12/2015 12:01, исправлен 31/12/2015 12:35)   

Вижу, что опять задал простой вопрос. :-) Большое спасибо, уже пробую.



Возник легкий практический затык на пользовательском уровне. Если загрузочная файловая система на внешнем носителе всего 100MiB (включая MBR), то в рамках обновления системы не хватает места для обновления /boot. Вижу всего два варианта решения – или перед каждым обновлением ядра увеличивать ФС с /boot на борту и потом умешьшать обратно (проверено с некоторыми диск-менеджерами и разными ФС, работает без ошибок), или размер ФС увеличить перманентно.


Есть еще варианты?


Второй пользовательский затык. Порядок действий: грузимся с Live-CD, записываем загрузочный раздел на флешку с бессигнатурно шифрованного харда, перезагружаемся, делаем плановое обновление системы. Теперь хотим записать обновленный загрузочный раздел с флешки обратно на хард, но не тут то было. В запущенной системе уже имеются подмонтированные разделы с данного харда, поэтому система не позволяет подмонтировать другую область того же самого харда, где хранится загрузочный раздел для флешки. Это означает, что надо опять грузиться с болванки для одной единственной операции.


Как сделать наиболее эфективно, чтобы было поменьше действий?

— pgprubot (02/01/2016 17:15, исправлен 02/01/2016 17:18)   

Если места на самом носителе, используемом как загрузочный, достаточно, никто не запрещает аналогичным образом использовать, например 200MiB вместо ста. Увеличить размер ФС проще, чем уменьшить. Раз вам удалось сжать до 100, почему бы не повторить процедуру для 200? Можно вообще всё пространство носителя использовать как загрузочное, а затирать только начало — вы же сами убедились, что за пределами какого-то числа первых секторов данные всё равно не пишутся.



Не понимаю, зачем вам такие сложности. Какая разница, куда на бессигнатурно шифрованном носителе будет сохранён загрузочный образ? Сохраняйте его просто файлом на какой-либо внутренней файловой системе на нём — именно её вы и должны монтировать с LiveCD, чтобы забрать оттуда образ (снимаете бессигнатурный слой, потом LUKS, потом LVM, потом на какой-то стадии добираетесь до ФС, оттуда выцепляете файл с загрузочным образом и записываете его на временный загрузочный носитель). Можете загрузочный образ хранить хоть в корневой файловой системе: главное — что с LiveCD вы до любой информации на этом носителе можете добраться, где бы и как бы она ни была записана.

— pgprubot (11/01/2016 18:39, исправлен 11/01/2016 18:41)   

После последнего обновления ядра система при загрузке начала подвисать на минуту-две перед тем, как показать меню grub'а (далее загрузка идёт, как и раньше). Пока она подвисает, идёт активное обращение к носителю (что она при этом с ним делает — непонятно). Загрузочный образ без последнего обновления с этого же носителя грузится без задержек. Что они могли сломать при bugfix-обновлении стабильного релиза? Была ошибка в grub'е с обходом пароля, разве что, но в данном случае он не использовался.


Хорошо, что хоть вообще ОС грузится. Эта новость лишний раз подтверждает нестандартность и опасность всей схемы. Например, по этой причине могли отвалиться все обновления ОС: пока проблемы не решишь, пришлось бы работать на необновлённом ядре с дырами.

— pgprubot (24/01/2016 10:08)   

Последующее обновление системы устранило эту проблему; теперь всё снова работает так же, как и раньше.
— pgprubot (08/03/2016 19:47, исправлен 08/03/2016 20:32)   

Ресайз сделал — всё работает, как и описывал. Берём готовый внешний загрузочный носитель, монтируем его в /boot, смотрим размер ФС. Делаем, например, resize2fs /dev/sdb 70M — ужимаем размер файловой системы до 70 MB, этого должно бы хватать. Потом запускаем fdisk -l -u /dev/sdb и смотрим на таблицу секторов. 2048 секторов (1MB) в начале — это MBR + таблица разделов, далее идёт ФС. Возьмём размер раздела с запасом — допустим, 80 MB. Значит, количество первых используемых секторов на флешке будет X=2048+80*1024*1024/512+1 (1 — потому что в fdisk Size раздела почему-то на 1 больше, чем разница между Start и End; возможно, это MBR так учитывается, не знаю). Короче, X-2048 — новый размер раздела в секторах. При редактировании fdisk не меняет ничего в данных, а только редактирует таблицу разделов, хранящуюся в фикисированном месте в начале диска. Запускаем fdisk /dev/sdb, удаляем имеющийся раздел (скорей всего, он один), и добавляем новый с 80 MB места. Первый сектор так же будет 2048, конечный сектор — вводим число X. Потом меняем командой "t" тип раздела на исходный (83 — Linux) и командой "a" делаем разделу bootable-флаг. В общем, это всё. Теперь снова запускаем resize2fs /dev/sdb, и она расширит ФС с 70 MB в точности до нового чуть большего размера — 80MB (там, где просят сделать e2fsck -f, делаем). Флешка готова и урезана, теперь остаётся только снять с неё образ до указанного места: dd if=/dev/sdb of=/path/to/file.img count=X. Получается новый образ, который занимает примерно 81 MB, его можно копировать на загрузочный носитель, когда нужно загрузиться. Правда, если речь о флешках, затирать потом нужно всё равно всё пространство, а не только первые 81 MB.


Были идеи упростить эту процедуру, но они не сработали. Например, можно создать образ, в котором первый мегабайт тот же, что и в /dev/sdb, а на оставшемся месте нарезана та же файловая система. С помощью rdiff-backup туда можно перенести файлы c /boot с сохранением всех атрибутов. Получается вроде бы валидный образ, grub загружается, но потом продолжить загрузку не может, т.к. uuid не совпадает. Попытки на лету убрать UUID'ы в меню тоже не приводят к успеху, т.е. grub'у нужна строго та же ФС, какая была изначально. Кстати, образы дисков можно легко монтировать на лету как mount -o offset=$((2048*512)) boot.img /path/to — loop-устройство создаётся автоматически.



Другая интересная идея — отказаться от использования внешнего носителя при обновлении системы (типа apt-get upgrade), т.к. это, прежде всего, влечёт за собой много лишних действий. Если просто подмонтировать образ носителя в /boot, команды update-grub и update-initramfs -u (иногда ещё надо -t указывать) отрабатывают, но создаваемый образ не грузится — grub слишком умён и прописывает loop-устройство как загрузочное (причём во многих местах) вместо конвенциональных set root='hd1,msdos1' и т.п. Теоретически это можно потом править своим скриптом, но такое решение грязное, а исправлений будет много. Можно ли сделать чище? Оказывается, можно.


Фактически, дело за малым — надо объяснить системе, что некий образ — это реальное устройство /dev/sdb, а не что иное. Может быть, это можно порулить какими-то грязными хаками и симлинками в /dev, но, оказывается, есть простой и изящный трюк — проброс устройств в Xen. Его можно установить, он проапдейтит ядра и таблицу вариантов загрузки в grub, а всё остальное останется, как и раньше — т.е. отличий работы на обычном ядре и на паравиртуальном ядре в dom0 особо никаких нет. Однако, если основная ОС загружена именно как дом 0, появляется возможность использовать утилиту управления домами xl. Xen поддерживает переброс на лету между гостевыми ОС (domU) множества всякого харда — дисков, сетевых и PCI-устройств. Проброс дисков обычно делается из дома 0 в какой-то дом U, однако... в сети есть указание, что никто не запрещает пробрасывать устройства из дома 0 в дом 0. :-) Т.е. мы берём какой-то образ и закидываем его самим себе как новый виртуальный диск.


В VG создаём LV для загрузочной флешки, размер выбираем равным размеру готового образа (ужатого, как описано выше, например) + 2 MB на LUKS-хидер — получается примерно 83 MB (если делать, как выше). Нарезаем на новом LV хидер LUKS, открываем устройство, внутрь через dd записываем наш образ загрузчной флешки. Когда всё готово, перекидываем его самим себе:

# xl block-attach 0 phy:/dev/mapper/DEVNAME_crypt sdb w
Теперь по теории в системе должен появиться диск /dev/sdb. Однако, ОС слишком умная и принимает его к себе как Xen-диск, т.е. xvdb. К счастью, это не будет фатальным. Далее монтируем его (mount /dev/xvdb1 /boot) и можем выполнять обновление системы, update-grub и т.д. Когда всё сделано, делаем umount /dev/xvdb1, возвращаем устройство от самих себя себе: 
# xl block-detach 0 sdb
а потом с помощью dd содержимое устройства /dev/mapper/DEVNAME_crypt складываем в базу данных загрузочных флешек как файлы boot.img, готовые к переносу на внешние носители. LUKS на LV-устройстве с образом теперь можно закрыть через luksClose — подмонтированный /boot в норме системе не нужен, он только для обновлений.


Это работает. Странно, что хотя 'hd1,msdos1' более не пишется, grub это не смущает. Если подключение (монтирование) /boot и отмонтирование скриптовать, после/перед xl-командами следует сделать паузы хотя бы в 1 сек через "sleep 1", потому что виртуальное устройство появляется/исчезает не моментально.



Кстати, Xen умеет очищать RAM от старых данных перед загрузкой: добавляем опцию

GRUB_CMDLINE_XEN_DEFAULT="bootscrub=1"
в /etc/default/grub и делаем update-grub. При загрузке потом об этом будет писаться, можно посмотреть и непосредственно:
# xl dmesg |grep scrub
(XEN) Scrubbing Free RAM: .done.

— Yellow (02/11/2016 10:10, исправлен 02/11/2016 10:21)   

В рамках работы над совершенствованием системы решил пошагово проверить затирание части флешки[link80]. Оказалось, что может быть сюрприз. Действия:


1. Затираем флешку



2. Снимаем с нее хеш, отступив от начала на 100MiB, на которых потом будет партиция



3. С помощью gparted создаем MBR.


4. Повторяем шаг 2...


...и обнаруживаем, что хеши НЕ соответствуют. Оказывается, при создании MBR gparted пишет в конец носителя нули. Проверялось созданием дампа конца флешки



Больше сюрпризов не было. Идем дальше.


5. Затираем флешку, отступив все тех же 100MiB



6. Снимаем хеш, как во втором шаге.


7. С помощью gparted создаем партицию FAT32 размером 99MiB (gparted резервирует первый 1MiB, наверное в связи с MBR). Проверяем, чтО мы создали (выхлоп команды опускается)



8. Снимаем хеш, как во втором шаге, и убеждаемся, что он не изменился.


9. Экспериментируем с затиранием первых 100MiB и созданием в их рамках разных файловых систем. Этим убеждаемся, что это ни в коем случае не затрагивает остальную часть флешки. Прверялось на


FAT32
ext4
reiserfs
ntfs

— pgprubot (02/11/2016 21:49, исправлен 02/11/2016 21:52)   

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


Gparted — GUI-шная приблуда к parted, который сам по себе не так прост как кондовый fdisk. Каждый следующий уровень усложняет логику и контроль простых действий. Делайте всё простыми предсказуемыми инструментами — и не будет никаких сюрпризов.


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


Говоря простым языком, ваш комментарий сводится к следующему: при первичном форматировании диска и установке MBR parted зачем-то пишет нули в конце диска, но при последующей работе с дисковыми разделами этого не наблюдается — конец не трогается.

— Yellow (03/11/2016 11:13, исправлен 03/11/2016 11:14)   

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



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


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


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


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

— pgprubot (03/11/2016 19:51, исправлен 03/11/2016 19:53)   

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


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

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



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


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


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



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

— Гость_ (15/11/2016 21:46)   
Чей-то блогпост с похожими идеями: Encrypting your HDD with plausible deniability[link82].
— Yellow (19/02/2017 14:18, исправлен 19/02/2017 14:24)   

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



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

— Гость_ (19/02/2017 16:27, исправлен 19/02/2017 16:39)   

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



Лучше не мучиться, а сделать с Xen, как выше описано[link84], тогда записывать инфу на флэшку придётся только в том случае, когда будете перезагружаться. Самый красивый способ – это обновлять ядро вообще без перезагрузки, что теоретически можно, но не в случае 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 на /, не указывался дважды, первый раз из которых – первой строкой. Достаточно удалить первую строку. Можно попробовать вручную[link85]: распаковываете 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-скриптах не трудно найти строки, ответственные за вывод и запрос пароля, их можно поменять на любые свои, но большого смысла в этом не вижу[link86].



Такой способ тоже работает. Чтобы закидывать файл в initramfs, нужно написать отдельный хук как здесь[link87] или выполнять свой кастомный скрипт, который перепакует 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)   

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



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


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

— Yellow (25/01/2018 21:45)   
Будьте добры, нужна помощь. Боюсь расковырять все до полностью нерабочего состояния.

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

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

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

Как безопасно убедиться, что мое предположение правильно, и как исправить эту фигню?

Ссылки
[link1] https://www.eff.org/wp/defending-privacy-us-border-guide-travelers-carrying-digital-devices

[link2] http://www.rusplomba.ru/safe_packages/

[link3] https://www.pgpru.com/comment76322

[link4] https://www.pgpru.com/comment73398

[link5] https://www.pgpru.com/comment73412

[link6] https://www.pgpru.com/comment73786

[link7] https://www.pgpru.com/comment81977

[link8] http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=blob;f=defaults/initrd.scripts;h=7cb41b3d6476cde5f69aefbac12880a0895b4628;hb=3fa1bf680d90f5841d8830634ed13bbfd76271b7

[link9] https://www.pgpru.com/comment79509

[link10] http://wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_Keyfile

[link11] http://wiki.gentoo.org/wiki/Custom_Initramfs#Device_Nodes

[link12] https://www.pgpru.com/comment80362

[link13] https://www.pgpru.com/comment82154

[link14] https://wiki.debian.org/systemd#Installing_without_systemd

[link15] https://www.pgpru.com/comment77182

[link16] https://www.pgpru.com/comment86705

[link17] http://blog.surgut.co.uk/2013/06/now-less-cryptic-cryptsetup-changes-in.html

[link18] https://www.pgpru.com/comment53852

[link19] https://www.pgpru.com/comment52123

[link20] https://www.pgpru.com/comment86924

[link21] https://www.pgpru.com/comment67554

[link22] http://www.hermann-uwe.de/blog/towards-a-moderately-paranoid-debian-laptop-setup--part-1-base-system

[link23] http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/debian-testing-i386-binary-1.iso

[link24] https://www.pgpru.com/comment90691

[link25] https://www.pgpru.com/forum/offtopik/anonimnostjibezopasnostjkakmezhdisciplinarnyjjpodhod

[link26] https://www.pgpru.com/comment39528

[link27] https://www.pgpru.com/biblioteka/rukovodstva/zaschitadiska/tailsotricaemoehraneniedannyh

[link28] https://www.pgpru.com/comment80173

[link29] https://www.pgpru.com/comment57545

[link30] https://www.pgpru.com/comment93057

[link31] https://www.pgpru.com/comment86869

[link32] https://www.pgpru.com/comment86822

[link33] https://www.pgpru.com/comment93497

[link34] https://en.wikipedia.org/wiki/Overengineering

[link35] https://www.pgpru.com/comment18100

[link36] https://www.pgpru.com/novosti/2007/0707s1oktjabrjavvelikobritaniikljuchiperestanutbytjsekretami

[link37] https://www.pgpru.com/comment39694

[link38] https://www.pgpru.com/comment39698

[link39] http://www.pavelkogan.com/2015/01/25/linux-mint-encryption/#fnref:mint

[link40] http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/

[link41] https://wiki.archlinux.org/index.php/GRUB#Boot_partition

[link42] https://en.wikipedia.org/wiki/Kexec

[link43] https://www.pgpru.com/comment93634

[link44] https://www.pgpru.com/comment93636

[link45] https://www.pgpru.com/novosti/2008/javnyeparolivoperativnojjpamjatipovsemestny

[link46] https://www.pgpru.com/novosti/2011/amnesiaprogramnajazaschitaotatakholodnojjperezagruzki

[link47] https://www.pgpru.com/forum/tehnicheskievoprosy/kakbystroochistitjozuposlerebuta

[link48] https://www.pgpru.com/comment93545

[link49] https://www.pgpru.com/novosti/2015/vypuskdistributivatails14

[link50] https://www.pgpru.com/comment90508

[link51] https://www.pgpru.com/comment73064

[link52] http://manned.org/sdmem/acd0b8d1

[link53] https://www.pgpru.com/comment93617

[link54] https://www.plop.at/en/plopkexec.html

[link55] https://www.pgpru.com/comment86936

[link56] https://www.pgpru.com/comment79493

[link57] https://www.pgpru.com/comment79502

[link58] https://www.pgpru.com/comment49723

[link59] https://www.pgpru.com/comment60190

[link60] https://www.pgpru.com/comment60192

[link61] https://www.pgpru.com/comment61389

[link62] https://www.pgpru.com/comment93206

[link63] https://www.pgpru.com/forum/unixlike/sozdanielivecd

[link64] https://www.pgpru.com/forum/prakticheskajabezopasnostj/ispoljzovaniezagruzchikaplop

[link65] https://www.pgpru.com/comment93087

[link66] https://unix.stackexchange.com/questions/198881/where-can-i-find-the-screenlog-0-file

[link67] https://stackoverflow.com/questions/18127728/differences-between-screenlog-and-hardcopy-on-gnu-screen

[link68] https://tails.boum.org/contribute/design/memory_erasure/

[link69] https://www.pgpru.com/comment49120

[link70] https://www.pgpru.com/comment93810

[link71] https://www.pgpru.com/comment87421

[link72] https://www.pgpru.com/comment93654

[link73] https://www.pgpru.com/comment93660

[link74] https://www.pgpru.com/comment94239

[link75] https://skrilnetz.net/bullet-proof-data-encryption-with-luks-and-a-detached-header/

[link76] https://www.pgpru.com/comment94133

[link77] https://www.pgpru.com/comment94043

[link78] https://www.pgpru.com/forum/unixlike/maskirovkavvodaparoljavcryptsetup?p=2&show_comments=1#TwoA

[link79] https://www.pgpru.com/comment94268

[link80] https://www.pgpru.com/comment94282

[link81] http://aforism.ru/681608

[link82] https://and1equals1.blogspot.fr/2009/10/encrypting-your-hdd-with-plausible.html

[link83] https://www.pgpru.com/comment94407

[link84] https://www.pgpru.com/comment94729

[link85] http://backreference.org/2010/07/04/modifying-initrdinitramfs-files/

[link86] https://www.pgpru.com/comment81973

[link87] https://unix.stackexchange.com/questions/134553/full-disk-encryption-with-dm-crypt-without-luks

[link88] https://xakep.ru/2015/09/02/os-level-encryption/

[link89] https://github.com/kriswebdev/grub-crypto-deluks

[link90] https://github.com/kriswebdev/cryptsetup-deluks