forum.lissyara.su

Здравствуйте.
Пытаюсь собрать следующую конфигурацию:
FreeBSD загружается с usb-drive на котором находятся ключи шифрования от всего диска (geli), естественно с паролем. (уже сделано)
Проблема же заключается в следующем - после загрузки должна быть возможность извлечь флешку, чтобы сохранить ключи, без потери /boot раздела.
Идея - во время начальной загрузки создать md диск который добавить в зеркало с /boot, затем отключить флешку и потереть ключи на загрузочном разделе.
Не знаю что меня останавливает %)
Просто хочу спросить Ваше мнение на этот счет.
Заработает?

зачем их сохранять после загрузки?
раздел же уже примонтирован

А сохранять их надо для возможности подгрузки модулей ядра во время работы ОС.
И проблема как раз в том и состоит, что флешку надо выдернуть и кинуть на карман, чтобы ключи никому не достались...
Ну а /boot останется на md0 например.

ну, а в чём проблема собственно?
что не получается?

Хочется еще все это на GPT сделать.
Допустим скрипт поместим в /etc/rc.d/bootmirror.sh
Сможет ли ОС загрузиться, если я обработаю раздел `gmirror label ...`?

флэшку с ГПТ?
изврат....

Согласен - Из_врат!
Потому и хочется...
Можна будя написати хав-ту на тему: "АкууИЫВ Total Offline Security" %)

Чтож, жаль что Вы меня не поддержали...
А у меня 8-ка, установленная на юсб-флешку грузиться отказывается, не видит da0s1a. Никто не сталкивался? Вроде ядро даже umass0 определяет, но при этом da не видит... мне 8-ка нужна чтобы флешку сделать...

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

Мне кажется слишком мудрёно вы делаете.
Шифрование с паролем, чревато применением терморектального криптоанализа.
Шифрование по ключу, самое то.

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

Да, но 2 фактора, есть 2 фактора.
У меня вообще планы сделать по отпечатку. Есть даже флешка с хардвёрной аутентификацией по пальцу, одна проблема - на ней максимум 5 пользователей может быть, а найти загрузчик, который будет грузить с разных разделов флешки разные ОС , да ещё и понимающий GPT+ZFS или хотя бы UFS - я пока тоже не смог ;( [хотя поговаривали про grub2]

Кстати, Ваше монтирование я бы сделал по событию вставки флешки (ридера?) (devd.conf). Да и ещё одно: что-то я не обнаружил в скрипте перенос данных на md0, а если они в зеркале, то его придётся разметить...в общем не внял я... %((

Если уж разговор заладился, продолжу: т.к. с загрузчиком пока всё плохо, решил сменить схему. Загрузчик с ключом - на microSD, пароль - в голове. Идея такова: носить microSD в лацкане пиджака например, и в случае опасности - разгрызть и съесть (Для верности можно смазать цанидом %). Как вариант - изготовить криптекс на основе термита...
Отсюда кстати следует не сильно праздный вопрос: Кто нибудь разгрызал microSD? Как ощущения?

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

В идеале - это должна быть SmartCard, но быстрых и таких что могут использоваться через crypto(4) - не видал.
Кража ключа ничего не даст, если у Вас установлен ещё и пароль.
Коли нет нормальных ключей, приходится извращаться: проверка контрольных сумм файлов на флешке + шифрование с ключом и паролем.
Подобную конфигурацию использую уже лет 5, ещё начиная с bde...
Считаю шифрование необходимостью на всех мобильных устройствах (и для телефонов тоже %).

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

По сути нужно отключить от gmirror'a флешку, не нарушая gmirror разметки. Сейчас - я дёргаю на горячую, а потом при загрузке он ругается, мол грязный раздел и т.п. хочется чистого решения.

З.Ы.Ж
Лучше всего использовать GPT-labels для адресации устройств хранения, тогда всё ОК.

hishnik писал(а): Кстати, Ваше монтирование я бы сделал по событию вставки флешки (ридера?) (devd.conf). Да и ещё одно: что-то я не обнаружил в скрипте перенос данных на md0, а если они в зеркале, то его придётся разметить...в общем не внял я... %((

А зачем данные переносить? Они уже там, зашифрованны. И у меня зеркало. Всё сделанно на скорую руку, после масок-шоу на соседних предприятиях.

Кстати, Ваше монтирование я бы сделал по событию вставки флешки (ридера?) (devd.conf)

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

Извините, не понял с первого раза %(.
Зеркало тут ни при чём.
В Вашем случае действительно так удобней, но пароли никто не отменял, тем паче их можно по частям раздать разным людям, и тогда паяльник грозит ИМ %)
У меня подобная схема на удостоверяющем центре. Геля позволяет иметь 2 независимых ключа (и пароля соответственно), поэтому одна флешка - у начальства в сейфе, а одна - в работе. При этом кнопка уничтожения ключа настроена на рабочий.

P.S.: считаю тред актуалным и буду благодарен тому кто придумает как вытащить флешку из зеркала, так чтобы разметка gmirror была в consistent state.

!UP!

А попробовать по detach в devd делать
gmirror remove name prov
а по attach gmirror insert

Вот выдержка из мана, по-поводу remove:
remove Remove the given component(s) from the mirror and clear meta-
data on it.
Мне же необходимо выдернуть из рэйда флешку, не затронув метаданные. Сейчас - я её просто выдёргиваю, но флаг "подключённости" к рэйду остаётся и в статус он потом пишет DIRTY.

По поводу события on-detach - мне не сильно подходит, так как уже на флешку ничего не скинешь.

Повторю ещё раз основную идею:
Загрузка с MicroSD (GELI+KEYs+PASS), затем создание memorydrive, включение md0 в gmirror microSDшки, ожидание окончания процесса зеркалирования, отключение microSD из рэйда, вытаскивание флешки должно вызывать событие удаления ключей с md0.

Пока - просто терплю сообщения о грязном RAID при загрузке %(((

а если процессы начнут кушать свап, а у тебя его нету ?

Зачем /boot на флэшке? На ней нужны только ключи. Больше ничего. /boot можно оставить на жестком диске.

Boot не должен быть в свободном доступе. На диске он подвержен атакам, тем паче - модули ядра работают в нулевом кольце защиты процессора. Да и есть флешка с хардвёрной аутентификацией по отпечатку - самый раз чтобы загрузчики с ключами там разместить.
...немного оффтоп...Правда следующую проблему стоит обсудить в отдельном треде: нужен загрузчик, чтобы ставился на флешку (желательно с GPT-разметкой) и мог передавать управление загрузчикам разделов - там много граблей %(. например если делаешь GPT-разметку и делаешь раздел типа freebsd-boot то с какого раздела будет произведена загрузка - со следующего или это где-то можно настроить?

manefesto писал(а):а если процессы начнут кушать свап, а у тебя его нету ?

Ну почему же у меня его нету?
Я на свап не скуплюсь, и вообще люблю `mdconfig -t swap` побаловаться в целях ускорения процессов...

hishnik писал(а):Boot не должен быть в свободном доступе. На диске он подвержен атакам, тем паче - модули ядра работают в нулевом кольце защиты процессора. Да и есть флешка с хардвёрной аутентификацией по отпечатку - самый раз чтобы загрузчики с ключами там разместить.
...немного оффтоп...Правда следующую проблему стоит обсудить в отдельном треде: нужен загрузчик, чтобы ставился на флешку (желательно с GPT-разметкой) и мог передавать управление загрузчикам разделов - там много граблей %(. например если делаешь GPT-разметку и делаешь раздел типа freebsd-boot то с какого раздела будет произведена загрузка - со следующего или это где-то можно настроить?

Какие-то сложности на ровном месте, правда.
Хорошо, пусть будет /boot на флэшке, тогда его просто не надо монтировать на /boot после загрузки. На корне должен быть свой /boot не разделом, с модулями ядра и прочим. Системе решительно все равно где находится /boot/kernel/modules.
Загрузчик у тебя уже есть, называется loader(8). man boot. Еще читай developers-handbook, там процедура загрузки подробнее рассматривается.
man loader - на предмет root fs и настройки откуда и чего нужно грузить.

не монтировать boot - хорошая идея. У меня была подобная конфигурация... не устроила тем, что не сильно прозрачна процедура обновления, да и возможностью появления "разноверсицы" модулей. Хотел скрипт набацать, чтобы всё это в фоне, на gmirror зеркалировалось на memorydrive, и по необходимости (после обновления ядра), эти данные синхронились с разделом флешки (поиграться с приоритетами).
Это решение было бы более технологично, на мой вкус.

Технологично будет не усложнять. Сделать скрипт в один маунт флэшки, rsync и umount - это технологично. Все равно обновление системы/пересборка ядра это 95% операций с /boot и вызвать после этого руками некий afterupdateboot.sh вполне логично, просто и ясно.

Именно так (в смысле только (dump/restore)) выглядят мои нынешние конфигурации.
Тут разница во времени синхронизации серьёзная. dump/restore - минут 5, gmirror - и минуты не проходит.
А насчёт afterupdateboot.sh - всё так, но тогда ведь нет никакой разницы как он там внутри сделан gmirror или rsync.
Зеркало - быстрее и не позволяет случиться аномалиям в данных. Если уж делать скрипт, хорошо бы свести к минимуму возможность повредить системе.
Оба варианта - рабочие, проверял. Но, как я писал выше, хочется на зеркале сделать, пока не ясно как...