Маскировка ввода пароля в cryptsetup
Форумчане, скажите, можно ли сделать в Crytpsetup затирание вывода консоли при вводе пароля на загрузку?
Как в TrueCrypt – фейковая ошибка, например "Invalid BOOT.INI file Booting from C:windows", таким образом ввести в заблуждение по поводу установленной системы и не реагировать на ввод неправильных паролей.
Спасибо
Ссылки
[link1] https://www.eff.org/wp/defending-privacy-us-border-guide-travelers-carrying-digital-devices
[link2] http://www.rusplomba.ru/safe_packages/
[link3] http://www.pgpru.com/comment76322
[link4] http://www.pgpru.com/comment73398
[link5] http://www.pgpru.com/comment73412
[link6] http://www.pgpru.com/comment73786
[link7] http://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] http://www.pgpru.com/comment80362
[link13] http://www.pgpru.com/comment82154
[link14] https://wiki.debian.org/systemd#Installing_without_systemd
[link15] http://www.pgpru.com/comment77182
[link16] http://www.pgpru.com/comment86705
[link17] http://blog.surgut.co.uk/2013/06/now-less-cryptic-cryptsetup-changes-in.html
[link18] http://www.pgpru.com/comment53852
[link19] http://www.pgpru.com/comment52123
[link20] http://www.pgpru.com/comment86924
[link21] http://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] http://www.pgpru.com/comment90691
[link25] http://www.pgpru.com/forum/offtopik/anonimnostjibezopasnostjkakmezhdisciplinarnyjjpodhod
[link26] http://www.pgpru.com/comment39528
[link27] http://www.pgpru.com/biblioteka/rukovodstva/zaschitadiska/tailsotricaemoehraneniedannyh
[link28] http://www.pgpru.com/comment80173
[link29] http://www.pgpru.com/comment57545
[link30] http://www.pgpru.com/comment93057
[link31] http://www.pgpru.com/comment86869
[link32] http://www.pgpru.com/comment86822
[link33] http://www.pgpru.com/comment93497
[link34] https://en.wikipedia.org/wiki/Overengineering
[link35] http://www.pgpru.com/comment18100
[link36] http://www.pgpru.com/novosti/2007/0707s1oktjabrjavvelikobritaniikljuchiperestanutbytjsekretami
[link37] http://www.pgpru.com/comment39694
[link38] http://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] http://www.pgpru.com/comment93634
[link44] http://www.pgpru.com/comment93636
[link45] http://www.pgpru.com/novosti/2008/javnyeparolivoperativnojjpamjatipovsemestny
[link46] http://www.pgpru.com/novosti/2011/amnesiaprogramnajazaschitaotatakholodnojjperezagruzki
[link47] http://www.pgpru.com/forum/tehnicheskievoprosy/kakbystroochistitjozuposlerebuta
[link48] http://www.pgpru.com/comment93545
[link49] http://www.pgpru.com/novosti/2015/vypuskdistributivatails14
[link50] http://www.pgpru.com/comment90508
[link51] http://www.pgpru.com/comment73064
[link52] http://manned.org/sdmem/acd0b8d1
[link53] http://www.pgpru.com/comment93617
[link54] https://www.plop.at/en/plopkexec.html
[link55] http://www.pgpru.com/comment86936
[link56] http://www.pgpru.com/comment79493
[link57] http://www.pgpru.com/comment79502
[link58] http://www.pgpru.com/comment49723
[link59] http://www.pgpru.com/comment60190
[link60] http://www.pgpru.com/comment60192
[link61] http://www.pgpru.com/comment61389
[link62] http://www.pgpru.com/comment93206
[link63] http://www.pgpru.com/forum/unixlike/sozdanielivecd
[link64] http://www.pgpru.com/forum/prakticheskajabezopasnostj/ispoljzovaniezagruzchikaplop
[link65] http://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] http://www.pgpru.com/comment49120
[link70] http://www.pgpru.com/comment93810
[link71] http://www.pgpru.com/comment87421
[link72] http://www.pgpru.com/comment93654
[link73] http://www.pgpru.com/comment93660
[link74] http://www.pgpru.com/comment94239
[link75] https://skrilnetz.net/bullet-proof-data-encryption-with-luks-and-a-detached-header/
[link76] http://www.pgpru.com/comment94133
[link77] http://www.pgpru.com/comment94043
[link78] https://www.pgpru.com/forum/unixlike/maskirovkavvodaparoljavcryptsetup?p=2&show_comments=1#TwoA
[link79] http://www.pgpru.com/comment94268
[link80] http://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] http://www.pgpru.com/comment94729
[link85] http://backreference.org/2010/07/04/modifying-initrdinitramfs-files/
[link86] http://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
Можно пересобрать рамдиск так, чтобы он обходил вызов cryptsetup при полнодисковом шифровании. Будет что-то вроде "partition not found" или «том не найден», или вообще загрузка посторонней системы. А можно вставить в скрипты рамдиска какую-то свою команду, которая бы вызывала кусок скрипта с нормальным cryptsetup только при определённых условиях — нажатии комбинации клавиш, хотя бы малоприметный read с таймаутом.
Но это чисто внешняя защита: грамотный противник, способный провести экспертизу, разберёт и рамдиск построчно, и подозрительные разделы заметит.
Да мне собственно внешняя защита и интересна. Так сказать "от дурака". Зачастую в моей модели угрозы нет никаких спецов, кроме продажных студентов "Юго-Запада Москвы".. Если m0fx64 в своем AcodeMorse реализует – посмотрю готовый вариант. Я так понял, если ты говоришь о плясках с ramdisk, то упомянутый мной TrueCrytp не в тему, потому, что он эту опцию видимо только на винде и поддерживал..(
А постороннюю систему загружать – это в духе:
В общем смысла, если правде в глаза смотреть, с этой "внешней" защиты – как с козла молока, правильно я понял?
А как еще можно сделать скрытую OS, кроме средств TrueCrypt? Ну т.е. тупо написать скрипт, который будет дешифровывать криптоконтейнер, распаковывать к примеру тот же AcodeMorse, подгружать его в виртуалку и после работы – обратно упаковывать?
Да, можно, но я не готов сейчас об этом говорить. Идея в том, что вы можете указать опции загрузки ядру на лету (в загрузчике). Вы также можете грузиться с бессигнатурно шифрованного диска (нужен только загрузчик; рекомендуется lilo или syslinux). Вы можете даже сразу установить на бессигнатурно шифрованный диск Debian, прям во время инсталла создать дополнительный нейтральный iso или образ для флэшки и сразу начать грузиться, как надо. Также можно грузиться с нейтрального LiveCD или LiveUSB.
Всё это уже оттестировано и работает, но, повторюсь, я не готов сейчас об этом говорить. Как я понял, есть скрипт cryptroot в рамдиске, он очень умный, ему можно подсовывать даже те шифрованные cryptsetup'ом разделы, которые в plain mode. Ядру надо будет указать что-то типа cryptopts="cipher=... hash=... size=... source=... target=...". Конечно, там не так всё просто, и если сейчас начинать это описывать, нужно создавать огромный документ с объяснением матчасти, внутренней кухни рамдиска и его создания, а также всех подводных камней... Если что, в самом рамдиске не будет ничего такого, что напрямую указывало бы на "специальность задач, для которых его используют".
P.S. Unknown'а не слушайте, в данном случае он просто не в теме. :-)
Согласен, я не любитель таких извратов.
В принципе конечно можно каждый раз в GRUB входить и редактировать по памяти, что передавать ядру, и для cryptsetup помнить все режимы, оффсеты и пр. Если это у кого-то отлажено, работает и удобно организовано, то я рад, но действительно не в теме :)
Гость (29/07/2014 17:15), супер! Это то, что нужно. Правда для меня пока не подъемно. Буду по мере возможности изучать.
Да, как-то так. Там не много команд, достаточно указывать опции каждый раз, и всё.
Да, в рамках рабочей группы я проинформирован, что решение уже есть и работает. У меня есть большая часть сырого материала, но готовых инструкций пока нет.
Перые методики шли с вываливанием в single mode, откуда вы цепляете plain mode шифрование и LVM внутри него, а потом переходите в многопользовательский режим, и всё ОК. Позже было оттестирован способ с указанием опций ядру на лету. Ещё позже — тестирование разных загрузочных медиа, как стандартных, так и специально созданных. Наконец, последний шаг — как это сделать сразу при установке Debian: установить его на бессигнатурный полностью шифрованный диск и заодно тут же приготовить загрузочный диск/USB. Этот квест тоже был пройден. Может быть, есть ещё какие-то подводные непройденные камни, я так навскидку не скажу.
Это бессигнатурка-лайт. Полная будет включать в себя паравиртуалку и сокрытие в неспользуемых местах диска.
Для загрузки лучше всего подойдёт, пожалуй,А вообще, есть об этом смысл тут писать? Просто есть разные мнения, и опасения высказывались разными людьми и здесь и в других местах. Оно, конечно, достаточно хорошо защищено от полного раскрытия всех деталей "как и каким образом это делается", но всё же надо понимать, что это bleeding edge в security-технологиях, они разрабатываются специалистами для решения специальных задач. Вы не прочитаете нигде в открытых источниках о том, как это сделать, даже в английских. И в рассылке Debian вам тоже никто не блюдечке не преподнесёт инструкцию, как получить weaponized Debian.Если шифрованный диск подключен и загрузчик смог с него загрузить ОС, то всё ОК, всё прозрачно для ОС читается и пишется на диск. Вопрос "после работы" тут как бы неуместен. Как и положено, при журналируемых ФС система должна быть устойчива даже к резету. Конечно, я сомневаюсь, что система сможет всё правильно определить и отмонтировать диски, но если в самом конце работы (штатное завершение, shutdown -p now) будет писаться какой-нибудь малозначимый ворнинг на этот счёт, то не думаю, что это сколь-нибудь страшно.
В том-то и дело, что cryptroot в рамдиске довольно умён, самому ничего изобретать не надо. Если вы не укажите опции в ручную, он ничего не найдёт и напишет ошибку загрузки. Если укажете правильные опции, он запросит пароль, и если этот пароль правильный, то загрузка пойдёт как по маслу.
С созданием рамдиска там тоже весело: например, если LUKS не установлен, cryptroot не будет положен в рамдиск при его создании, т.е. вы полностью останетесь без автоматики подключения шифрованного дискового пространства. Если установлен, туда могут утечь UID'ы ваших разделов и путь/имя root-устройства (какой-нибудь /dev/VG-NAME/root), что тоже плохо. Однако, там есть варианты конфигурации, при которых всё более-менее ОК.
Можно, конечно, не париться, и вообще создать внешний загрузчик, где всё будет уже указано и без лишних команд грузиться искоробки, но тогда, если такой загрузчик у вас найдут, будет то же самое, как будто его не было (впрочем, для переноса информации через границу годится — загрузочный диск можно с собой не возить). Конечно, лучше, в любом случае, использовать какой-нибудь стандартный загрузчик, которому руками указывать всё: и путь к руту, и опции cryptsetup.
Конечно, поэтому никто и не рекомендует так делать. :-)
Спасибо большое за ответы. Надеюсь, что у меня получится поднять знания до этого уровня. В любом случае – очень признателен.
Через границу банановой республики — да. А через серьёзные страны лучше возить только чистые носители или с системой, в которой нет никакого рэндома.
Лучше-то оно лучше, но тут речь о другом: либо вы везёте забитый рандомом диск без сигнатур (утверждается: да, было, но всё затёр, там ничего нет, диск пуст), либо диски с LUKS-заголовками и следами их использования, т.е. у вас могут спросить пароль. Как по мне, то первое лучше второго.
А почему в "серьезные" страны нельзя не возить информацию? Ну т.е. зачем рисковать, если можно залить в зашифрованном виде на свой сервер, а потом на месте скачать? Меньше рисков, вопросов в аэропортах и тд. Или я не правильно Вас понимаю, господа?
Правдободное отрицание, такое правдободное… Это прокатит при честном судебном расследовании. При въезде в страну вас могут просто не пустить, сбэкапить весь ваш диск на всякий случай и попросить спецслужбы повнимательнее приглядеть за вашим трафиком (времена и места выхода в сеть, объём скачанного), поставить на слежку все ваши перемещения, контакты и пр.
Именно так и советуют делать в EFF:
Defending Privacy at the U.S. Border: A Guide for Travelers Carrying Digital Devices[link1].
Ну, такова жизнь, значит.
Пусть бэкапят на здоровье. Главное, что они не смогут это сделать тайно, а то, что у данных появится нелегитимный бэкап, я учту.
Это они всегда могут сделать и по любому поводу — например, из-за посещения linuxjournal.com.
Скачать сколько? Терабайт данных? Ага, ага. Я имел в виду случай, когда нужно вести. Случай, когда без этого можно обойтись, очевиден. Там по ссылке, кстати, в таких случаях советуют позже высылать шифрованный диск по почте. Это плюс в том плане, что это не повиляет на пропуск на границе столь непосредственно, но минус в том смысле, что вы не будете знать, досматривали ли его (правда, unknown где-то кидал ссылку на то, что можно так покрасить его блёстками, что вскрыть, не оставляя следов, будет невозможно).
У меня есть часть дисков, которые не используются. Я их очищу, допустим, рандомом. Потом надо будет их везти с собой. Мне их что, принципиально потом ещё раз нулями перезаписывать, всем назло?
В таком случае есть safe-packages[link2], если, опять таки, я правильно понял.
На счет терабайта данных я не подумал, для меня это немыслимый объем. Но, опять таки, в зависимости от цели и ценности этих данных. Если риск большой – уж лучше потратить сутки, и даже более – на скачивание их, нежели рискуя провозить. По поводу почты – снова, ну даже если в сейф-пакет упаковать – придет он распечатанный, забэкапят данные – кому претензии предъявлять и, главное, зачем уже?) Поздно ведь, отчасти личность скомпрометирована.
Ага, этот терабайт данных копился лет 10, а потом «взять и за сутки скачать». Кстати, мало какой провайдер позволит на максимальной скорости выкачивать такие объёмы данных. И качать вы будете, боюсь, неделю или месяц.
Там хитрее было, но пусть unknown выскажется, мне сейчас будет трудно найти тот его пост.
Повторюсь, я даже гипотетически не могу представить скачку подобного объема данных. Ну пусть неделя, с нескольких компом, децентрализовано, с разбивкой на 100Гб, потом склеить. Не знаю, на сколько это технически выполнимо. Но если действительно невыполнимо – то конечно только провозить. А здесь у меня тоже возникал вопрос по поводу скрытой операционной системы и ее реализации. То есть попросят показать – ну показывайте "нужную" ОСь, а в разделе будут данные. И, на сколько я понимаю – никто не поймет, что это криптоконтейнер.
/comment76322[link3].
Слушайте, ну дурь же. У меня месячный трафик до 50GB не дотянет. Не каждый ISP это позволит + очень долго + много гемороя + неудобно + это не вопрос жизни и смерти.
Это "бессигнатурка-хэви" [1][link4], [2][link5], [3][link6], её намного тяжелее сделать чем то, что вы хотите здесь как топикстартер. Во-первых, там надо будет играться с Xen-ядром, а не просто с cryptroot, во-вторых, настроить гостевые системы, в-третьих, делать БД для dmsetup, в четвёртых, скрипты для автоматизации всего процесса.
/comment81977[link7]
Доведите до ума по максимуму сначала сами, чтобы исключить упование на obscurity, затем публикуйте, если считаете, что это стоит того. Может удасться толково перевести на английский и протолкнуть идею в мэйнстрим Debian.
я так понимаю все завязано на initramfs?
Ну предположим так?
добавляем что то вроде
и
у генты свое поделие[link8]
Или просто монтируем как диск[link9] предварительно загрузившись в LiveCD/USB ставим тутда что нам надо в загрузчике прописываем что вроде этого
Или вводим вручную чтобы не палить UUID.
Примерную модель я правильно представил?
Можно еще и initramfs пересобрать и это все описано[link10], дальше только полет фантазии...
[fix]
Но суть то думаю ясна?
[/fix]
UUID надо помнить наизусть что-ли? Или диск состоит не из чистого рэндома, как будто его целиком стёрли, а на нём какие-то тома с уидами торчат?
crypt_root=/dev/sda2 /dev/mapper/root
Понятно. Внутри sda2 м.б. физический том и все логические сами распознаются если надо, когда он откроется паролем. Только при перепаковке рамдиска автоматом при обновлениях логические уиды из sda2 могут в него утечь и остаться запакованными, если я не путаю.
все зависит от того как это пересобираться[link11]
На встроенные стандартные функции/скрипты initrd, если быть точнее.
Не надо там ничего специально модифицировать, это приведёт к палеву.
Можно и так, но это более трудоёмкий способ, чем воспользоваться инсталляционном диском и сразу сделать, как надо. Естественно, у нас тоже с него начинали. Примерная последовательность действий была (все тесты на Debian):
- Ставим Debian штатно как есть с криптами и т.д. на посторонний диск.
- Грузимся с постороннего диска, создаём нужный initrd, пишем его на CD-диск или ещё куда там надо (флэшка, например, — зависит от того, с чего планируете грузиться).
- Затираем[link12] целевой диск, после чего он превращается в
- Устанавливаем Debian на бессигнатурный диск: после загрузки инсталляционного диска дропаемся в шелл, создаём plain mode раздел размером на весь диск, внутри него можем создать ещё один LUKS-раздел на весь диск, который, в свою очередь, разбить на LVM-тома (которые также могут быть шифрованными или нет); после создания нужных устройств, они будут распознаны и подцеплены инсталлятором автоматически.
- Грузимся с CD с записанного initrd, в загрузчике указываем опции типа cryptopts="cipher=... hash=... size=... source=... target=...".
Предварительная установка требовалась, чтобы создать правильный initrd. Квест был пройден.тыквудиск без разделов и без сигнатур.Кроме того, ваши команды с хидером LUKS'а плохи для внешнего уровня шифрования. Мы исходим из того, что у юзера на руках не должно быть носителей с подозрительными файлами, которые должны остаться в тайне, а раз так, где вы собираетесь хранить хидеры LUKS'а? Если на том же диске через выделенную посредством device mapper область пространства, то чем вы её будете шифровать? Всё равно на каком-то уровне у вас должен быть конец ниточки, потянув за который, всё распутывается, и этот конец не должен требовать ничего кроме знания конкретных команд и пароля. Короче, я не вижу смысла в хидерах или ключевых файлах на самом внешнем шифровании.
Указывать UID'ы не требуется.
Можно, но палево будет меньше, если использовать стандартный.
OMG, я сказал, на диске нет разделов! Диск забит случайными данными[link12].
Итак, примерная модель:
Бессигнатурка-лайт
Информации указано с избытком, на случай про запас (не всё из этого нужно знать для создания «решения», но это может оказаться полезным). Текст плохо структурирован, возможны повторения и взаимосиключающие параграфы, но для понимания общих идей этого достаточно. Это не готовая инструкция — пока что это скорее памятка с фактами для тех, кто пытается что-то аналогичное сделать самостоятельно. Общий дисклеймер — берегите мозг.
Оглавление
B. Вариант с однопроходным решением
C. Вариант с двупроходным решением
D. Загрузка с флэшки как есть
E. Загрузка с флэшки с указанием опций загрузчику на лету
Факты о загрузчиках
Все 3 загрузчика умеют грузить ядро с произвольно введенными с ком. строки опциями ⇒ grub* не необходим. В инсталляторе Debian'а предлагается выбор между grub2 и lilo, но никто не мешает потом сделать загрузчик на isolinux/syslinux. Ниже пойдёт речь исключительно о Debian, хотя это не принципиально.
Эксперимент
Инсталляция
Для первого эксперимента воспользуемся lilo (в перспективе syslinux предпочтительнее; к тому же, lilo с сидюками не дружит). Тестовая система — QEMU с KVM, загрузчик будем ставить на реальную внешнюю флэшку, которая также «подмонтирована» к виртуалке. Последовательность действий:
Однако, в нашей схеме в crypttab'е ничего нету, поэтому он просто выдает варнинги.Соответственно, initrd у нас теперь вообще ничего не знает про наш криптораздел, хотя инструменты для его подключения есть.Опции из crypttab нужны только для разделов с plain dm-crypt, а если у нас LUKS, никаких опций в initrd не будет, т.к. они сидят в самом хидере LUKS-раздела(при генерации initrd хук cryptsetup'а прописывает туда опции cryptsetup'а для всех разделов, где не LUKS, а берёт он эти опции из crypttab). 100%-гарантию дать трудно (для этого надо все скрипты просмотреть), но вроде все конфиги пишутся в conf.d внутри initrd. Содержимое можно посмотреть, распаковав initrd:Вариант с однопроходным решением
Решение в том, как на стадии инсталляции закатать на CD-диск isolinux. При Debian netinstall, конечно, всегда можно дропнуться в rescue shell, сделать chroot и по сети подгрузить/установить любой пакет (apt-get install). В этом варианте, очевидно, загрузчик в инсталляторе лучше не выбирать.
Вариант с двупроходным решением
В двухпроходном варианте сначала Debian ставится штатным образом на посторонний диск (с LUKS или plain mode). Если там LUKS, то можно сразу после его загрузки установить isolinux с тулзами для CD и записать. Если использовалась plain mode, то надо после загрузки поставить cryptsetup — это сгенерит подходящий initrd, и далее задача сведена к предыдущей. Т.е., самый важный факт в том, что для сборки подходящего initrd необходимо и достаточно наличия в системе установленного cryptsetup. Ну, или возвращаемся к однопроходному варианту, где вместо записи CD-диска в конце достаточно иметь под рукой болванку с Debian rescue Live CD той же версии, а загрузчик вовсе не ставить в инсталляторе.
Загрузка с флэшки как есть
Загрузка с флэшки с указанием опций загрузчику на лету
Указываем lilo при загрузке опции:
Значение опции lvm — название lvm без полного пути, т.е., если в системе есть /dev/vg/root, то надо указать lvm=vg-root (синтакисис: имя_VG-имя_LV). Короче, в lvm надо указать после «=» ту часть пути, которая после /dev/mapper/ [восстановить правильный вариант мысли не удалось].Мысли и вопросы общего характера
Впрочем, как оно будет дружить с обновлениями, и не рассинхронизируется ли однажды (после обновлений) совместимость — это вопрос. Самому apt-get'у на всю эту внутреннюю кухню пофиг, но на это реагируют всякие postinst-триггеры от определенных пакетов, так что при реконфигурации загрузчика могут начаться нюансы. В частности, хуком на kernel-postinst стоит переустановка lilo (в нашем тестовом случае там указано, что mbr надо пихать на реальную подмонтированную флэшку, но если её не будет, lilo просто поругается [впрочем, это можно проверить]). Можно играться с фиктивным boot'ом, но он должен будет очень сильно смахивать на натуральный: т.е. должно быть псевдоустройство, куда lilo сможет лезть (например, файл, подключенный через loop), а просто /boot как часть корневой ФС ничего не даст (подмонтированного /boot для хранения конфигов будет недостаточно). Грубо говоря, в lilo.conf прописано битым текстом «mbr писать на такое-то устройство».
isolinux вполне органично смотрится на usb-флэшках, т.е. он, а принципе ставится не только на CD. Его чаще исользуют, чем syslinux, т.к. у него больше всяких фич, в частности в работе с рамдисками.
Можно использовать два диска. На одном открытая система для игры в пасьсянс. На другом шифрованная рабочая. Какую запускать --указывается параметрами при загрузке.
А так, как я и представлял: совсем уж чуда не будет. Слишком большой шанс в ответственный момент получить апдейт в систему, после которого поломается и будет не загрузиться. Ну т.е. откатываясь и проделывая массу ручных операций, всё конечно можно разрулить и пофиксить, но это всё такой «закат солнца вручную», которого хотелось бы избежать.
Ну а что вы хотите? Это ж пока совсем пре- пре- для лайта. Всё начинается с демонстрации принципа работы, с тестовых систем. Только потом идёт автоматизация, оптимизация и упрощение.
Апдейты можно тоже рассмотреть, оттестировать и включить в модель, но пока не до того.
Зарегтесь на сайте и создайте вики-страничку под этот документ, пусть для начала даже с черновыми и нерекомендуемыми к практическому использованию вариантами. Будет проще её исправлять по мере коментирования, возвращаться с новыми идеями, чем терять разрозненные посты в форуме.
Для вики-странички желательна хоть какая-то завершаемость, а для этого нужен хотя бы прототип инструкции. Инструкции нет. Тест пока что опирался на самодельный загрузчик — это плохо, но это просто эксперименты, нужные, чтобы достичь понимания принципов (cистему всегда надо строить от простого к сложному). В итоговом тексте 80% того поста было бы попросту ненужным информационным мусором. Наконец, у меня столько сырых недоведённых до ума страниц и идей, что я уже не рискую, не видя почти готового варианта, серьёзно браться за что-то новое.
Только без --use-random — оно к plain mode неприменимо (что вполне логично).
Кощеева смерть
Самостоятельно попроходил квест. Инсталлятор Debian'а понятен почти всюду, но в двух местах пришлось тыкать на угад. Первое уже забыл (что-то с разбиениями и конфигурацией дисков), а второе — conversion (uuid'ов?) перед самым finish install в районе записи загрузчика (взял lilo) на внешний носитель.
Извратился и сделал такую схему:
В 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, там теперь можно так монтировать:
Разбиение на диски и крипторазделы там всегда было отвратным. Там есть возможность выйти в консоль и сделать всё вручную, но раз в несколько лет плевался и как-то методом тыка добивался нужного от обычного инсталлятора.
Кстати, LILO может плохо понимать навороты с томами, он для минимализма в духе старых систем, безо всяких (крипто)томов. Конечно, всё решает рамдиск, но в него из grub.conf передаются какие-то UID'ы.
Оно нормальное, но недокументированное, до всего надо доходить самому, даже если понимаешь, как это всё внутри должно быть устроено. Общая схема такая: идёшь по пунктам:
/dev/sda
/dev/sda
Не уверен. Но если вы правы, то, по моим представляениям, это надо сделать до захода в меню 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 с его БД, и дальше загрузка пойдёт штатным образом.
Во время инсталляции 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. Поиск пестрит рецептами, один другого страшнее, от которых хочется выть: нечитаемые скрипты на много листингов и прочая машинерия. Наконец, находится (конечно же, не на официальной странице, где оно должно быть, а у кого-то любителя в заметке):
Чудесно, просто опупеть, как чудесно. Не трудно видеть, что в этой[link16] конфигурации, по такой логике, cryptsetup в initramfs ну вообще не нужен! Кто же такой умный? А там и пояснение в конце:
Судя по гуглу, grub-update/install не пересоздают initramfs, для этого надо то ли dpkg-reconfigure linux-image-... сделать, то ли update-initramfs -u -v перед собственно grub-install. Кстати, вместо извращений с распаковкой initrd для проверки, есть удобная тулза lsinitramfs. Можно пробовать. Я только одно не понял: почему в случае с lilo так нужный cryptsetup всё-таки попал в initramfs.
Продолжение следует.
Да, правы. Во всяком случае, меню инсталлятора всё показывает, хотя LVM- и LUKS-разделы были созданы ранее вручную. Правда, до конца не ясно, скажется ли это на чём-то, когда он захочет сгенерить initramfs [т.е. всё равно ли инсталлятору, как создавались разделы/устройства (в консоли или через меню) или нет, обращает ли он на это внимание при генерации содержимого /boot?].
Нет, всё не так. Собственно, эта страница по ссылке и есть данного автора — он только задекларировал имеющийся статус-кво, а вот кто его таким сделал — этот вопрос остаётся открытым.
Не помогает, как ни извращайся: ни '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/ в системе тоже присутствуют.
Вспомнил, что на старой системе на таком же железе было так: с Xen'ом не запускалось никак, а без него запускалось только с nomodeset, передаваемом ядру. Думаю, дай проверю, как теперь тут, на новом ядре. Итоги: с nomodeset графика с Xen вообще не запускается; без Xen запускается, но больше одного xdm'а по-прежнему не запустить, и принудительный старт графики на иных дисплеях через xinit продолжает работать.
Можно, хак найден: дописать rootdelay=0 к опциям загрузки. Он тогда практически моментально выбрасывается в шелл, что нам и нужно (всё равно автоматикой там ничего толком не цепляется).
Хак грязный, хотелось бы почистить.
Для начала поэкспериментировал с указанием опции загрузчику на лету. Так, чтобы после указания всё начинало цепляться автоматически, не происходит. Однако, самый верхний уровень шифрования действительно можно сделать автоматикой — для этого дописываем
Это всё меня натолкнуло на мысли создать правильный crypttab — вдруг после этого всё заработает вообще автоматически? Структура, как выше сказано, такая:
plainOpen[LUKS{VG1( LV1,1( LUKS[VG2( LV2,1(root), LV2,2(usr), ... )] , ... ))}]
Зелёным помечено то, что, похоже, initramfs способен понять из коробки. Всё остальное — только через кастомные скрипты, если кто-то готов их писать. Казалось бы, если он готов раскручивать LVM, когда встречает его внутри «матрёшки», то всё должно отрабатывать, но этого почему-то не происходит, причины неизвестны. Тестировался вот такой crypttab:
Фиктивный swap убрал c /etc/fstab и даже убил соответствующее LUKS- и LV-устройство принудительно, однако, после
Кстати, до сих пор не пойму, почему 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 показывает, попал он туда или нет.
Не знаю, кстати, были ли она там когда-то или нет, но в моей версии man initramfs.conf опции CRYPTSETUP не числится.
Когда-то разбирал initrd, вроде туда можно положить что угодно. В дебьяне нельзя ничего делать по общелинуксовому (можно и так, но не рекомендуется), а нужно делать по-дебьяновски. Т.е., если вы вручную распакуете initrd, поправите, запакуете и положите на место, то оно сработает, но предполагается, что за такое кто-то должен бить по рукам, например, очередной апдейт к вашей системе.
Есть /etc/initramfs-tools. Там нужно в подкаталоги в соответствии с их структурой поместить всё, что нужно, поправить там конфиги. Разумеется, на изучение всего этого и на эксперименты нужно потратить достаточно времени, зато потом всё будет работать как часы и можно забыть этот напильник на многие годы.
Затем командой update-initramfs -u все обновления попадут в initrd. И так будет происходить при соответствующих апдейтах системы автоматически.
Может ещё где-то что-то нужно конфигурировать для поддержания initrd, сходу не помню.
Можно попросить туда положить загрузчик TrueCrypt?
Можно, просите.
И дасться?
Вам удалось? Вы на среднем уровне вникали в то, как собирать 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. Итог:
Кого сейчас заинтересушь гибридными CD? Флешки появятся только через 10 лет у людей.Про то, что большинство современных ноутов уже поставляются без CD-приводов, авторы не подозревают.Вот так и живём, господа. В XXI-ом веке LiveCD с шеллом, где есть LVM и cryptsetup — роскошь. Моя кастомная ramfs размером в 60MB, оказывается, намного полезней для восстановлений при сбоях и всём остальном, чем все эти популярные инсталляционные и LiveCD-диски, распространяемые миллионами. По крайней мере, cryptsetup, LVM и dd там работают, а это уже достаточный минимум для отката системы к предыдущей версии. Если б не необходимость иметь нейтральный загрузочный носитель, можно было б не мучиться. Может быть авторы удаляют всё из ядра, чтобы оно грузилось на калькуляторах? Памяти не хватает? А для plymouth-место таки нашлось? Нет, всё-таки просто пидорасы, нет других объяснений.
В BSD не бывает такого сорта проблем. Любая BSD содержит необходимый минимум. Чтобы его оттуда выпилить, надо очень сильно постараться, и за это не приято гладить по головке. Там концепция полноты и самодостаточности системы настолько глубока, что базовая система содержит даже косольный браузер.
В initramfs-шелле не хватает man'ов. Неужели они так много весят? Во времена, когда найти флэш-память размером меньше, чем на гигабайт — это проблема, в чём смысл не класть man'ы? И ком. строки grub'а это тоже касается.
Сейчас пишу с бессигнатурки. Здесь на форуме уверяли, что такое невозможно. Судя по всему, никакого «заката Солнца в ручную» нет и близко, всё работает как и раньше. Канитель:
- В загрузчике (конфиг grub) указываем rootdelay=0
- В initramfs выполняем штук 5 команад.
- Делаем exit и система грузится, как ни в чём ни бывало.
Системе вообще пофигу откуда она грузится. /boot перед apt-get updgade монтируется стандартно, апдейты тоже идут стандартно. Можно было бы, конечно, всё автоматизировать, чтоб не вводить лишние команды в initramfs при загрузке, но мне это некритично.И собирал, и разбирал, и выковыривал что-то оттуда и разбирал как там все скрипты устроены.
И даже чуть выше среднего и не для себя, но это было давно и неправда :)
Придёться палиться своими конфигами, ну мне терять нечего. У меня какая-то старая записка в файле есть по этому делу:
Ещё лежят образцы device.map, grub.cfg, ещё помню, что uuid берется с ext2fs, вот комент про это:
Просто это всё разбирается подолгу, затем годами трогать не надо, а если под рукой нет нужных записок, то забывается.
Вы не поняли дух Debian, там всё есть, но сделано так, чтобы потыкались и решили, что ничего нет, что Debian — УГ и ушли на свою Убунту. :) По памяти не помню, но в Debian специально, чтобы никто непосвящённый в эти обряды не догадался, где-то в дремучих глубинах сайта есть какой-то правильный Live-cd, то-ли professional, то ли rescue, то ли как-то так, там все профессиональные утилиты, вплоть до всякой полуфорензиковой экзотики. с него и инсталлиться можно. А инсталлиться надо выбрав все пакеты вручную, поставив в систему только минимум и apt, а затем аптом выбрать всё, что нужно.
В принципе, если собираете что-то параноидально-кастомное, то поставьте систему с обычным шифрованием, а с неё вручную поставьте на флэшку что нужно. Есть и куча всяких средств для создания своих дистров, клонирования конфигов и пр.
С Debian так: долго помучался, но разобрался, сделал и забыл на несколько лет. Он же стабильный.
Пришёл, не разобрался, всех обхамил. Вот разрабы так и делают, чтобы было понятно только для самих разрабов, полупродвинутым пользователям всё равно не угодишь, пусть ковыряют всё сами, если надо, как бы нелогично снаружи без знаний всей этой кухни оно не выглядело.
На будущее, там и ядро самоскомпилённое нельзя ставить через make install, надо собрать из него кастомный пакет и прописать в apt. И grub.cfg править нельзя: надо править конфиг, который предназначен для правки grub.cfg, который лежит в другом месте. Я половину этих штук не знаю и делаю криво и неправильно, но считаю, что это разработчики имеют право быть дартаньянами, а не я.
Ну вот вам понятно, почему update-initramfs не цепляет crypttab? Куда рыть, что смотреть?
Ага, я тут один идиотствую из проекта. Больше никто не палится. Все умные, один я дурак.
Это под первую версию граба, во второй править уже очень нежелательно (во всяком случае, если только вы не планируете полностью отказаться от автоматических обновлений системы).
Честно говоря, не то, чтоб мне это так сильно надо было, просто как PoC было бы красиво. Наверно, в гугле есть относительно внятные инструкции, как переносить /boot на иной носитель для современных версий ОС.
Общее понимание остаётся, что там и как работает, что с чем связано. Проблема — не подглядеть в скрипт/man, проблема — понять схему работы всей конструкции в целом и связь её частей.
На основной странице сайта проекта есть ссылки на всё, что у них имеется, я там многократно лазил. Содержимое серверов с iso-шками напрямую я тоже анализировал, хоть и поверхностно. Ни на что такое не наткнулся ни разу. Если кто-то где-то под себя из принципа что-то собирает, это ещё ничего не говорит о проекте в целом. Этот LiveCD официальный? Покажите ссылку. И описание его на сайте тоже покажите, без этого просто не о чем говорить.
Вы за оффлайновую инсталляцию? Может быть, она и даёт больше безопасности, но не так значительно — всё равно ж с сетью работать компьютер будет и софт тянуть оттуда тоже. Раз инсталляционный CD проверяет подписи на пакетах, то что ещё нужно? Разве что файерволл.
Ручной перенос системы, если нет под это знаний — жесть полная. Даже в самых простых BSD это не такая простая процедура, и по затратам мозг-время часто проще не клонировать, а поставить заново. На клонинг идут тогда, когда это окупается (ну, например, не надо обновлять ОС до более новой версии, и там уже есть весь необходимый софт — требуется просто копия системы). Я несколько раз в жизни проходил через клонинг, но все разы мне помогали более опытные в этом деле товарищи.
Сейчас такое железо делают, что может и года не проработать, а новое железо — это новые пляски с ОС, новые «не поддерживается» и т.д.
Это я-то не разобрался?! А что я, как юзер, по-вашему, должен? Полностью изучить за разрабов всю их внутренню кухню, вычитать всю рассылку, учесть все явно упомянутые и неупомянутые костыли, все сделать правильно назло всем, а потом вежливо намекнуть «УМВР, но разрабы могли бы сделать чуть лучше»? Добро пожаловать в реальный мир тогда. Как в таких случаях бывает, начальство жмёт руки и говорит «спасибо вам за то, что вы у нас работали».
Я — потребитель, и во многом судья со стороны. К тому же, у меня есть опыт и возможность сравнивать, что где и как работает. И меня абсолютно не волнует исходя из каких соображений ребята породили говно. Мне достаточно факта.
Без новояза объяснить не получается?
Я в курсе, но это как бы хорошо известно и всем понятно.
Знаю, поэтому делал всё через автоматику, но она почему-то тоже делает не то, что должна, а почему?
А я уже мальца подустал от дартаньянства «слишком умных». Меня незнанием матчасти всю жизнь тыкали, но вроде уже давно наступил момент, когда мне можно потыкать этим других. Знаете ли, я делал намного более сложные вещи чем эти ваши ядра и инсталляторы, и знаю, какой бардак там творится: и очковтирательство и бред и всё остальное (Это там, где люди реально несут ответственность, делают не for fun и стараются вылизать каждый кусок своей работы). А если глянуть глубже, там такой ужас, что я не представляю, как всё до сих пор не рухнуло.
Эти горе-программисты просто порождают говно как Константин Клягин, и все, кому надо, это прекрасно понимают. Можно искать, как оправдать любую дичь, но дичью это быть не перестаёт. Не делайте, одним словом, из разработчиков небожителей. Сидят там такие же придурки, как и во всех остальных местах (и у нас, в том числе) и ваяют говно. Но если в коммерции из-за косяка встанет процесс или рухнет инфраструктура, баготворителя могут выставить за дверь, и он об этом знает. А если баг в опенсырце, который for fun, то можно натворить любые косяки, а потом надменно комментировать их в рассылке как «ну и что, подумаешь, ерунда; у меня всё работает».
При любых обновлениях ядра вам на флэшку надо будет скопировать только system.map, initrd, vmlinuz и config. Сам grub обновляется редко. При его обновлении надо будет пересоздать флэшку заново по этому черновику, так что править там конфиг всё-равно придёться заново, благо одна строчка, а если иметь его бэкап, то всё ещё проще — часто после обновления grub diff'ом можно сравнить бэкапы, выдернутые в разное время из /boot и убедиться, что там ничего не поменялось.
Там всё ещё хуже. Обратитесь по дорогой платной корпоративной техподдержке к кому-нибудь типа Оракла, MS, Intel, IBM и пр. с вопросом чуть сложнее, чем «не туда ткнул мышкой». А если ещё с какой-то нестандартной штукой, которую 99.99% пользователей не настраивает, то будет вообще цирк.
А вот этого в коммерции категорически нельзя, специально обученные люди будут говорить по всем каналам связи с пользователями «всё хорошо, прекрасная маркиза». Там надо лицемерно врать, да. Но насчёт ответственности даже с крупными денежными контрактами — вы преувеличиваете, все риски у крупных компаний учтены и покрыты заранее. На мнение особо упрямых клиентов им пофиг («ваше мнение очень ценно для нас, спасибо, что сообщили»), порушить их репутацию почти ничем нельзя.
С техподдержкой везде так — на том конце провода соединяют с клушами, а до специалистов надо ещё добраться.
Серьёзные косяки — это, например, аварии на магистралке, когда огромная страна остаётся без Интернета. Ну, или из-за головотяпства какой-нибудт ютуб оказывается заблочен на всю страну. И эти вопросы требуют решения за минуты, т.к. иски за простой могут быть колоссальными.
Специалисты тоже могут нихрена не решить проблемы с дорогущим оборудованием, можно собачиться с компанией, а можно плюнуть и найти решение почти как в опенсорсе, а не ждать пока там компания включит это в свою официальную документацию.
Вы больше напираете на пример компания-клиент, хотя я изначально имел в виду вопросы кода для нужд внутри компании. И оправдываться, почему оно не работает, придётся не перед заказиками извне, а перед собственным руководством, которое тебе задачу поставило, а ты её или не выполнил или выполнил криво.
Там масса примеров такого же абсурда, внутренней бюрократии, плохой организации, наказания невиновных и награждения непричастных. И такие вещи некорректно сравнивать. Вы с поставщиками дистра — не одна компания, вы же пользователь, а не разработчик.
Я кстати упоминал ранее, что когда-то шифрования в ядре и утилитах для работы с диском не было (не говоря уже о возможности это завести прямо из инсталлятора, как сейчас). Всё это пропатчить, пересобрать рамдиск, переделывать при обновлениях — был тот ещё геморой. Аналогично не было штатной поддержки подписей пакетов, но можно было самому написать скрипт, который их выкачивает без установки, сверяет все суммы с подписью и не ставит, если что-то не так. Сейчас часто не хватает сил и времени поддерживать что-то из нестандартных настроек, иногда проще склониться к выбору в пользу изкоробочности, пока это не поддерживается штатно. Т.е., если возможность доработки напильником есть, но она слишком сложна для пользователя, то дистростроитель в большинстве случаев в этом не виноват.
Это всё хорошо, и можно понять, но как это касается вполне конкретной вещи — исключения dm_mod из загрузочного ядра? Загрузчочное ядро же наоборот стараются делать как можно более GENREIC, чтобы не испытать проблем ни с поддержкой железа, ни с недостатком фич. В крайнем случае, можно было бы давать несколько ядер на выбор — полное и, если с полным проблемы, усечённое.
Можно ещё руками попробовать сделать в шелле modprobe dm_mod или поискать соответствующий файл на диске; если найдётся, то insmod /path/to/module_file должно спасать. Но вроде модули обычно подгружаются при надобности автоматически, так что вряд ли это поможет.
У все продвинутых мелкий шрифт, а у меня крупный. Почему?
Потому[link19].
Вспомнился комментарий
Автор там пишет:
Он ставит Debian именно оффлайново, но не с netinst CD. В принципе, само название netinst как бы подразумевает, что это «network installation», поэтому неудивительно, если чего-то базового и важного там не предусмотрено. А ставить с другого типа CD — значит, устанавливать в систему множество всякой софтовой бредятины, которую потому замечаешься вычищать. ☹
Был неправ. Инсталляционный диск (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 команду, чтобы подгрузить нужные модули ядра, но пройти этот квест не удалось.
Потому, что вы не продвинутый. К.О.
Перечитал тред и сам ужаснулся. Теперь не верится, что через всё это когда-то пришлось пройти... Я даже уже успел забыть, что однопроходного решения вроде так и не было найдено, и если всё повторять заново, похоже, хак с реинсталляцией загрузчика из-под другой системы всё равно понадобится.
Здесь был гипероффтоп[link24]. Пусть он будет там[link25].
Вы хотите бессигнатурно шифровать, делать множество нетривиальных вложений томов и т.д. В Debian был баг-репорт, что при даже не самом навороченном вложении шфированных томов некая матрёшечная конструкция некорректно отмонтировалась при poweroff и накапливались ошибки. Тогда что-то пофиксили. Если вы городите что-то очень своё, то есть шанс поиметь проблемы с потерей доступа к данным после очередного выключения, обновления и т.д. Не говоря уже об общей оценке затрат сложности персонального поддержания на некоторые самопальные неискоробочные решения.
Даже при стандартном полнодисковом шифровании он не мог корректно всё отмонтировать и удалить ключи из памяти, а при таком — тем более, поэтому, по-хорошему, всё критическое надо перед выключением отмонтировать самостоятельно (а также удалять ключи из памяти). В идеале — зачищать оперативную память перед выключением, как это можно сделать при желании из настроек Tails.
К счастью, журналирование в ФС есть, это сильно спасает дело, но и бэкапы никто не отменял, естественно.
Угрозы со временем только растут, атаки становятся только сильнее, поэтому, чтобы сохранять паритет с противником и быть хотя бы на один шаг впереди, нужно развиваться и совершенствовать защиту.
Господа, подскажите, можно ли сделать загрузку OS по ключевому файлу и паролю с флешки?
Ну, к примеру сделать openssl rand -base64 16384, записать его на флешку и при включении компьютера система будет требовать его и ввод пароля?
При полнодисковом шифровании так и делается, только openssl явно ни к чему. Как это сделать, зависит от конкретного дистрибутива, в Gentoo опции для сборки initrd можно определить с помощью genkernel.
SATtva, ну мне, как ламеру – что-то дебианоубунтуобразное. А почему openssl ни к чему? Так то по сути – плевать, что будет исполнять роль ключевого файла, правильно? Хоть тот же gpg-ключ или "семейная фотография".
Обычно всё же нет. Во-первых, /boot, как правило, на том же диске, который и шифруется, а не на внешнем носителе, а, во-вторых, cryptsetup обычно работает без каких-либо ключевых файлов. Конечно, всё это можно наворотить при желании самому.
Ок, скажем так, это достаточно распространённый подход.
См. /usr/share/doc/cryptsetup/examples.
Просто штатное полнодисковое шифрование — оно не для параноиков, посторонний внешний носитель для загрузки ещё таскать — неудобно, поэтому вот так. ☺
Только хотел сказать, что --key-file — это не произвольный файл, а файл для пассфразы, поэтому для двухфакторной аутентификации, видимо, понадобятся костыли (в отличие от того же cgd, где это по умолчанию делается всегда и штатно). Собственно, да, в examples приведён пример костыля. ☺ Кстати, тут это уже обсуждалось[link26].
Патчи к пунктам[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-разделы нужны только для возможности быстрого удаления, на них можно ставить пустые или простые пароли.
Раз загрузочный носитель всё равно затирается:
можно на него помещать как скрипты для автоматического монтирования дисков, так и LUKS-заголовки к ним:
Т.е. аутентичный режим plain mode нужен только при шифровании образа загрузчика. Этот образ нужно будет при каждой загрузке расшифровывать вручную из-под того или иного LiveUSB и записывать на флэшку/карточку.
Но:
Т.е., похоже, всё было не так. С lilo загрузчик установился сразу, всё работало, но система не пережила upgrade. С grub2 загрузчик штатно нормально не поставился, понадобились ручные фиксы, но зато после этого система стала нормально штатно апгрейдиться/апдейтиться.
Можно было бы тщательней поковырять вариант с lilo, но непонятно, насколько он считается штатным и поддерживаемым в Debian. К примеру, правильно ли он фиксится/апдейтится (как grub2) при установке гипервизора Xen и dom0-ядер Linux?
Пожалуйста, уточните архитектуру бессигнатурки с grub2. Я так понимаю, что на HDD есть бессигнатурное шифрование, и отдельно имеется носитель с Live-OS. Для загрузки скрытой ОСи, в этом случае, используется grub с live-носителя?
Каждый городит пример в меру своей испорченности...
Это как один из вариантов.
В таком случае нужной отрицаемости не получится, потому что сложно сделать универсальный grub для загрузки всего.
С Live-OS грузится только Live-OS. После её загрузки надо вытянуть загрузочный boot-образ (с настоящим grub2 для скрытой ОС) с бессигнатурно шифрованного носителя и записать его на какой-то третий носитель. После этого Live-OS выключается, вы грузитесь в скрытую ОС с этого третьего носителя. Затем вы этот третий носитель отмонтируете и затираете (из-под той же скрытой ОС). Примерно так это выглядит.
Справедливо ещё более сильное утверждение: на VG тоже ничего не заязано. Можно взять корневую ФС, как-то иначе переразбить на отдельные ФС, каждую ФС зацепить на своё LUKS-устройство с иным именем, потом перегенерировать initrd, и всё будет работать.
update-initramfs -u (или ещё с -t, если нужно) с последующим update-grub достаточно умно, чтобы понять, каков стал новый root=/path/to и прописать его в настройках. Однако, ожидаемо, при этом cryptsetup в initramfs не попадёт, требуются хаки.
Похоже, он полностью игнорирует эту опцию из-за каких-то ошибок в скриптах. Вместо того, чтобы разбираться с сотнями строк скриптов, можно применить следующий хак: в /usr/share/initramfs-tools/hooks/cryptroot закомментить проверку условия (строки с if и fi) в
Очевидно, из /etc/initramfs-tools/conf.d/resume. Этот файл можно отредактировать или оставить вообще пустым. Вообще, resume («восстановление») — файл с настройками для свопа, откуда система будет «просыпаться». Если hibernate/suspend не используются, про него можно забыть.
Если без initramfs, то первые две строки не работают. Последняя и другие ей подобные работают, если соответствующий раздел также указан в /etc/fstab.
Не уверен в правильности понимания логики работы этих скриптов, но, по всей видимости, оно работает как-то так: то, что без initamfs, не будет автоматически запрошено на стадии загрузчика. После подмонтирования корневой ФС он смотрит в /etc/fstab и пытается смонтировать ФС'ы оттуда. Если непосредственно это сделать нельзя, он заглядывает в /etc/crypttab на предмет того, можно ли найти нужный раздел, открыв какой-нибудь LUKS-том. Т.е. fstab первичен по отношению к crypttab. Если нечто указано только во втором, запрос на открытие LUKS-тома не поступит. Это ещё видно из того, что он запрашивает пароли по мере загрузки и необходимости (не все сразу).
Точнее, там так: берём /etc/crypttab наподобие такого:
Если в командной строке initramfs подсоединить самый верхний бессигнатурный слой вручную:
Правда, легко это сделать удаётся не всегда, тут много факторов.
Сделал бэкап системных разделов в 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.
Спасибо. А вручную задать опции загрузки в стандартном GRUB2 в этом варианте не получится?
Мои, разумеется, поверхностные и дилетантские вопросы связаны с попыткой определиться, в какую сторону копать подробно и тщательно.
Дело же не только в 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], там хотели нечто подобное сделать. Разработчики пошумели, но так ничего и не сделали (видимо, потому, что это действительно непросто).
pgprubot,
спасибо за подробное объяснение. Уже ковыряюсь.
Пожалуйста. Если кто-то решает похожую задачу, и вышеописываемые наблюдения ему в этом помогают, могу только порадоваться.
Шифрование /boot на уровне grub2 здесь когда-то обсуждали [1][link37], [2][link38]. В сети есть мануалы на этот счёт, которые можно поосмыслять [3][link39], [4][link40], [5][link41]. В принципе, эта фича полезная, т.к. ни в какой момент не возникает носителя с незашифрованным ядром и конфигом загрузки, такой штукой стоило бы пользоваться.
Это так называемый Kexec[link42], в новых ядрах он уже должен работать.
Смысл ответа всё же сохраняется: вряд ли есть какой-то более-менее стандартный/распространённый Live-образ, поддерживающий как шифрованние в grub'е, так и последующее выполнение kexec,* чтобы использовать сторонний носитель для загрузки скрытой ОС напрямую.** Тем не менее, в будущем всё может поменяться. Возможно, я чего-то просто не знаю / не понимаю, поэтому сильно зарекаться не буду.
* Хотя я не знаю, что именно нужно для kexec.
** А не готовить загрузочный носитель каждый раз самому, записывая туда образ, а потом затирая его.
Пока-что, пройден базовый левел – отработан алгоритм установки системы на неразмеченный хард с бессигнатурным шифрованием с GRUB2 на флешке. Это запускается нормально.
Теперь переходим на второй левел – LUKS внутри бессигнатурного шифрования. Здесь возникла проблема с запуском.
Возьмем crypttab без опций initramfs
Указываем загрузчику опции на лету
Система запрашивает пароль на внешний слой, после чего загрузка останавливается.
Если в crcrypttab указать опции initramfs, то не работают опции, заданные загрузчику на лету. Initramfs долго жует и вываливается в шелл с объяснением, что не может найти /dev/mapper/cryptname. Указание в этом месте каких-либо опций в шелл не помогает.
Использование умолчательного имени cryptroot (с/без опции target=) тоже не решает вопроса.
Будьте добры,
где искать затыкчто делаю не так?Я такой способ не тестировал, но по отзывам от других, всё так и есть. Если внутри бессигнатурного слоя сразу идёт LVM, то запрос пароля можно сделать полностью автоматическим.
Мне не удалось добиться автоматическго запуска для этого случая, т.е. в initramfs вам всё равно придётся вводить какие-то команды каждый раз, чтоб система загрузилась.
Раз это LUKS, шифр и режим уже указаны в заголовке LUKS-тома (в отличие от бессигнатурки), поэтому напишите cryptname_crypt /dev/mapper/cryptname none luks. Дописывать там опции шифра просто бессмысленно.
Так и должно быть. Вы оказываетесь в initramfs-шелле. В нём вы можете сначала проверить, правильно ли вы указали пароль:
Я бы посоветовал вам написать так в crypttab:
В initramfs-шелле загрузчика вы выполняете вручную (если у вас последний Debian):
Когда вы дописываете cryptopts=target=... на лету, вы, во-первых, пишете больше букв, чем в команде
Странно, что оно связано. В принципе, можете опустить initramfs в crypttab для первой строчки, где бессигнатурное шифрование, благо оно всё равно автоматически не подключается, но для последующего LUKS (и других LUKS'ов), если хотите добиться автоматики, указывать опцию initramfs нужно. Если готовы всё и всегда подключать вручную, можете initramfs не писать нигде, но я не вижу смысла так делать.
Как вы его назовёте — это ни на что не влияет. Главное — чтоб было консистентно: одни и те же имена в fstab, в crypttab, в конфиге grub'а и в командной строке initramfs'а.
4 В принципе, это действие избыточно: если внутри не LUKS, т.е. пароль задан неверно, то последующая команда luksOpen вернёт ошибку. В этом случае можете сделать cryptsetup remove cryptname и повторить команду подключения бессигнатурного слоя.
Спасибо Вам, разобрался. Теперь работает схема: бессигнатурное шифрование->LUKS->LVM. Параметры внешнего слоя задаются руками в шелле, пароль на LUKS запрашивается автоматом.
А на какой способ Вы указывали[link33]? Моя испорченность толкает меня в плохом направлении?
Какая может быть наиболее эфективная логическая форма для такого затираемого носителя с учетом проделываемых манипуляций?
Поздравляю! У меня к вам тоже вопрос: при инсталляции вы создавали загрузочный носитель с /boot на нём, так? Т.е. указывали в инсталляторе, что сделать загрузочным /dev/sdb какой-нибудь. Система начала сразу с него грузиться? Или вам понадобилось сначала каким-то образом искуственно загрузиться во вновь инсталлированную ОС, чтобы сделать update-grub, реинсталлировать mbr и т.д., что требует полноценного chroot'а с пробросом всех девайсов и системных ФС?
Я имел в виду, что LUKS внутри бессигнатурного шифрования в моих экспериментах был всегда. Внутри LUKS, понятное дело, всегда был LVM. Более простые схемы, на мой взгляд, не удовлетворяют минимальным необходимым требованиям, поэтому я их даже не тестировал, хотя знакомился с результатами других людей. Точнее говоря, более простые схемы я тестировал, но то был не Linux, и там вообще отдельный разговор.
Вам виднее. Когда человек делает явные ошибки в настройке — например, неосознанно ослабляет безопасность (на своём техническом уровне заморочек и неудобств), на это можно указать. Однако, есть более тонкий случай, когда нечто вносится или выносится в/за рамки модели угрозы. Это можно быть, на мой субъективный взгляд, как обоснованно, так и неоправданно. Обычно по мере повышения осведомлённости о том, как легко получить доступ к системе, человек старается учесть как можно больше моделей угроз, даже если нет иных причин считать себя ставшим более лакомой целью для атакующих.
Мне, например, неинтересно копировать то, что уже сделано другими. Куда более интересно (да и актуально) попытаться сделать защиту от того, от чего ещё никто (во всяком случае, массово) не делал. Я стараюсь внести в модель угрозы cold boot и иные способы получения информации с работающего компьютера. До этой новости[link45] и последующих улучшений[link46] атаки об этом мало кто задумывался, но сейчас вопросы типа таких[link47] — скорее, норма (кстати, Tails это умеет [1][link48], [2][link49]).
Обычно для защиты от cold boot предлагаются разные красные кнопки, физическая охрана помещений и сейфы с детектором вскрытия. Всё это хорошо, но, во-первых, сильно завязано на человеческий фактор, а, во-вторых, крайне неудобно. Для работы с информацией требуется отдельное помещение с контролем входящих, специально оборудованное рабочее место,
бункер,что в современном мобильном мире ноутбуков и планшетов обычно реализовать невозможно.Главное осознание — то, что полнодисковое шифрование само по себе по сути ни от чего не защищает. Точнее, оно хорошо защищает от конкретной угрозы: расшифрования диска, отключенного от компьютера и лежащего в шкафу. Бессигнатурность такого диска даёт некоторую отрицаемость, если ею правильно пользоваться. А бессигнатурность диска, с которого вы постоянно работаете — совсем другое. Ключи на его расшифрование постоянно загружены в оперативную память, да ещё и в развёрнутом виде, который устойчив к потери памятью напряжения и к частичному искажению данных.
Большинство специалистов скажут, что проблема нерешаема: либо вы смиряетесь со сложившимся положением дел, либо
строите бункерсоздаёте охраняемое помещение со всеми нужными атрибутами физической безопасности (заодно и защиту от TEMPEST'а можно предусмотреть). Тем не менее, кое-что бюджетное сделать можно, если вспомнить, чтоИдея простая: мы все файловые системы (ФС) делим на несколько классов:
Каждая файловая система должна быть привязана к своему LUKS. Типичная работающая система содержит подключенными все ФС класса А, класса B и несколько ФС класса C.
Какие принимаются меры для противодействия утечкам? Первая и очевидная — это, конечно, не подключать больше ФС, чем вам нужно в данный момент. Вторая — не подключать ФС, требующие повышенной безопасности, в тех публичных местах, где всё совсем плохо с физической безопасностью компьютера. Третья — время от времени очищать ФС от старых данных. Четвёртая — систематическая зачистка тех ФС, которые являются буферными, и где постоянно возникают непредвиденные данные. На последних двух мерах стоит остановиться подробнее.
Как очистить ФС от старых данных? Представим, что всё хранится на одной ФС: система, $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-сервера и залогинен какой-то из юзеров, по хоткею. Третье требование — не держать ФС, где лежат некоторые скрипты по монтированию и зачистке ФС, постоянно подключенными, поскольку они нужны не так часто и содержат информацию, которая потенциально может ослабить отрицаемость. Далее:
Служебный юзер не имеет непосредственного доступа в сеть и не используется ни для чего, кроме редактирования конфигов, доступных ему для редактирования, и работы под рутом. При должной автоматизации при логине в иксы терминал и 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 Пример скрипта:
Вас читать – как энциклопедию. В очередной раз – спасибо за огромное количество нужной инфы.
В процессе познания пришлось перепробовать разные дистрибутивы. Во-первых, надо было понять их пригодность для моих конкретных целей. Во-вторых, разобраться с логикой работы инсталляторов.
Удалось убидиться, что поняв логику и метод инсталляции конкретного дистра, можно довести установку через инсталлятор до любого желаемого конца в один присест/заход/проход. Зная процесс установки, можно после исполнения инсталляционного скрита, еще до рестарта системы, при необходимости, чрутиться в только-что установленную систему и исправлять нужные конфиги, создавать всякие "инитрамы", итд. (если, например, инсталлятор не умеет дописывать нужное в 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].
Спасибо. Всё описывать с объяснением, что и почему — это надо писать чуть ли ни книгу, но к концу её написания выяснится, что половина надо переделать или улучшить. Безопасность — это
никогда не кончающийсяпроцесс, а не состояние. © Практически всё, что здесь описывается, ранее уже озвучивалось разными людьми на форуме, вопрос лишь в сборке этого в нечто связное или в отсылке к обсуждениям, ранее имевшим место.Возможно:
Но если уже разобрались, как лечить бессигнатурку,6 это будет немного быстрее.7
Могу поэкспериментировать, но я никогда не разбирался с системой завершения работы ОС. Мне казалось, что он не даст отмонтировать системные разделы, либо, если даст, то никакие новые команды выполнены быть не могут, потому что исполнимые файлы были на них. Наверно, это как-то обходится, но не изучал, как. Если системные разделы не отмонтированы и их LUKS'ы не отключены, vgchange -an он тоже не даст сделать. Своп пока что вообще никак не использую.
Эта утилита тут ранее обсуждалась [1][link56], [2][link57], но у меня она вызывает ряд вопросов.
Тем временем, вот что[link58] пишет сам Гутман. Т.е. множественные перезатирания памяти уже давно не имеют смысла даже для HDD,8 а для немагнитных технологий записи (SDD, флэшки, RAM) это всё вообще сомнительно. Зачем перезаписывать RAM много раз, да ещё и случайными данными?
Я так понял, что оно «slow» только потому, что использует /dev/urandom — именно это ограничивает его скорость.9 Однако, urandom нужен там, где нужен именно PRNG. Для затирания данных вполне достаточно гаммы шифрованных нулей[link12]. Вместо того, чтобы играться с числом проходов, автору следовало бы имплементироваать этот способ.
Возможно, я чего-то не понимаю, но всё это очень похоже на то, что автор вообще не удосужился изучить тему, по которой он написал код. А если так, то возникает вопрос доверия и к самому коду.
Да. Штатный скрипт окончания работы, конечно, внешние LUKS'ы не отключает, поэтому есть как шансы, что соответствующие мастер-ключи остаются в RAM, так и шансы, что они не перезатираются при последующей загрузке системы. Если есть возможность, может помочь тотальное обесточивание системы (как вариант, вынуть батарею).
С этим надо разбираться. Если бы у вас получилось это сделать с пониманием, а потом здесь описать, было бы очень неплохо.
LiveCD загрузит grub, а grub должен загрузить ядро, но откуда он его возьмёт? Grub поддерживает LUKS, но не знаю, насколько полноценно. Допустим, grub позволяет подключить бессигнатурно шифрованное пространство на диске и выудить оттуда ядро и initramfs, тогда всё сработает. Для этого нужно:
Мне положительное решение вопросов 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 очень большая.
Если посмотреть на логи, которые пишутся при выключении системы, то сначала убиваются все процессы, а только потом отмонтируются системные разделы. Пока они не убиты, umount не сделать никаким образом, даже принудительно.
Я так понимаю, в процессе завершения работы ядро получает некий сигнал, переходит на иной runlevel, выполняются определённые скрипты останова, а потом ядро уже само должно прибить оставшиеся LUKS'ы и маппинги. В принципе, это всё задокументировано, можно начать с гугления, man shutdown, man inittab и далее по ссылкам.
Как и все наколеночные абстракции, эта тоже протекает. Рут в этой схеме является единственным пользователем, который может спокойно перебрасывать файлы из одного юзера в другого. Следовательно, информация о файлах остаётся в истории комманд шелла. В некоторых случаях можно нечайно создать[link66] файл логов screen (screenlog.0) или hardcopy[link67], т.е. всё содержимое терминала при нечайном нажатии внезапно оказывается на не так часто затираемой файловой системе. Если нужные шеллы screen не закрыть, введённые команды и информация о файлах (какие-нибудь cp -iv file1 file2) остаются в его буфере — можно отмотать несколько экранов в терминале назад и посмотреть. У самих терминалов тоже есть история буфера. Всё это легко может привести к тому, что разделы отомонтированы, пассфраза удалена, файлов нет, но информация о них продолжает где-то висеть и оставаться доступной, даже sdmem против таких утечек бессилен.
Конечно, если каждый раз стирать все временные файлы и разлогиниваться из-под рута, проблема кажется решаемой, но это лишнее неудобство и лишняя завязка на operational security — забыл сделать одно действие из множества нужных или поленился, и гарантированной защиты уже нет.
Я так понимаю, что, например, в Tails система в конце выключения перед запуском sdmem (или аналога) перезагружает новое ядро с помощью kexec.
Видимо, да:
Я не уверен, что безопасную очистку памяти нельзя сделать без kexec. Главное — удалить ту информацию в RAM, которая может содержать какие-либо юзерские данные.
Ещё в тему:
Понятно, что перед выделением памяти юзерским процессам она должна зачищаться, иначе это было бы фатальной уязвимостью, а как выглядит картина в целом — не знаю. По логике вещей если раздел с данными отмонтирован, а ключ удалён, система должна понимать, что никто к этим данным уже не может обратиться, поэтому ими занимаемую область памяти нужно вычищать для выделения другим процессам, когда понадобится.
Он ещё и новые утечки добавляет. К слову о скрытии процессов от других пользователей[link71] и разделении информации между пользователями: после выполнения sdmem ядро ругается на нехватку памяти, записывая в dmesg список текущих выполняющихся процессов и их параметры, а dmesg и т.п. логи* по умолчанию доступны для чтения всем пользователям системы.
* /var/log/{debug,dmesg,kern.log,messages,syslog} — содержимое этих файлов во многом дублирует друг друга.
Хотелось бы вернуться к вопросу загрузочного носителя. Выше говорилось
На внешней загрузочной флешке должны быть MBR+GRUB+{содержимое /boot}. Всех данных от силы пол-гига. В crypttab и fstab указаны UUID-ы, в том числе и загрузочного носителя, поскольку это упрощает практическую жизнь.
Пусть размер флешки 1Г. Копирование каждый раз всей флешки с помощью dd и последующее ее затирание – муторное дело.
Будьте добры, как можно повысить эффективность процедур, но так, чтобы при этом у флешки не поменялся UUID?
Слишком много. На самом деле, их около 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.
Второй способ тупее, но может оказаться проще. Я бы попытался как-то так:
Процедура сложная, тут может понадобиться погуглить, поэкспериментировать, поизучать процесс, хотя заранее понятно, что её сделать можно.
Есть ещё один способ, куда более тупой. Поскольку на носитель записывается и затирается меньше 100MB каждый раз, вы можете затирать не всего его, а только его часть. Затирание, таким образом, будет не столь надёжным, но его надёжность можно будет на каком-то уровне проверить экспериментально — выяснить, меняются ли данные при записи dd в конце носителя (точнее, за тем пространством, которое вы затираете).
Спасибо. Вашей развернутой инфой обязательно воспользуюсь, т.к. назрела необходимось переделки всей системы по практическим причинам. В настоящий момент пришлось воспользоваться самым простым и тупым способом из предложенных:
Копировалось, затиралось и восстанавливалось с помощью dd первых 100MiB данных, которые уверенно включают MBR и /boot (и одновременно помнить цифру 100 просто). Затирание производилось как с помощью /dev/zero, так и с помощью /dev/urandom.
При всех указанных операциях, данные после первых 100MiB не изменяются. Проверялось командой
После восстановления данных с помощью dd, UUID не изменяется, как Вы и указывали.
Читая форум, решил попробовать упростить схему бессигнатурки. Сейчас схема такая: бессигнатурно шифрованный хард, внутри которого LUKS, разбитый на LVM-разделы. Какие чисто пользовательские подводные камни возникнут, если сделать по-другому, как в заметке[link75] – на харде будет прямо LUKS (с LVM или без, без разницы), заголовки которого вынесутся на внешний носитель, где уже есть MBR и /boot?
Хорошо, но лучше, если вы этот способ будете применять не к флэшкам, SSD-дискам или SD-карточкам, а к обычным HDD-дискам (например, подключаемым по USB), поскольку частичное затирание данных достаточно надёжно (для современных используемых носителей) только для последних. Иначе говоря, если есть HDD, который можно использовать только как загрузочный диск, это хорошо, он и затраться будет быстрее флэшек.
То, что ничего за пределами первых 100MiB не меняется, следует, как я понимаю, из особенностей таблицы разделов, располагающейся в начале диска, и файловой системы FAT. Если бы вместо FAT было бы что-то менее примитивное, скорей всего, как минимум, была бы ругань ОС на обрезанную файловую систему. Не знаю, как NTFS, но типичные UNIX'овские ФС пишут так называемые суперблоки в разных местах ФС при её создании, т.е. нет такого, что за пределами какого-то объёма точно нет служебных метаданных.
Если тёрли нулями какой-то раз чисто для тестов, это ещё ладно, но в нормальной рабочей схеме никогда не затирайте ничего нулями — только рандомом, поскольку нули рушат отрицаемость всей схемы.
Сначала комменты по поводу самой заметки:
Автор путает тёплое с мягким. Соль, хидер, LUKS — это всё инструменты для вывода мастер-ключа. Если КК будет брутфорсить просто AES как алгоритм, т.е. сам мастер-ключ, ему всё равно, откуда он взялся. Если следовать рекомендациям АНБ[link76], нужно крутить режимы, а хидеры ни на что не влияют. AES-128 на КК превращается в 64-битный шифр, и это плохо. Чтобы было хорошо, нужно брать AES-256 и 256-битный случайный ключ в качестве пароля. С точки зрения опций, это те самые -c aes-xts-plain64 -s 512 -h sha512.
Во-первых, автор, кажется, не совсем понимает смысл команды luksFormat. Во-вторых, --align-payload=0 должно нормально заработать только в 1.6.7[link77], а в более ранних версиях эта опция попросту игнорируется.
luksFormat всего лишь записывает LUKS-хидер на какое-то устройство или в файл. Это устройство/файл потом просто будет проверять введённую пассфразу и выдавать мастер-ключ для расшифрования целевого устройства. Каким будет целевое устройство — абсолютно неважно. Иными словами говоря, на стадии luksFormat можно вообще не указывать, к какому устройству будет применяться создаваемый хидер. Кроме того, одним хидером можно расшифровывать разные устройства (так делать не советуется, но технически это возможно, если разные устройства используют один и тот же хидер, а, следовательно, и один и тот же мастер-ключ).
В принципе, вот это должно бы работать (даже с несуществующим файлом tmpLUKS):
Рабочий метод есть, и он примитивен:
Я взял 5MB для файла с хидером, что было с запасом, потому что размер хидера может отличаться в зависимости от версии cryptsetup'а. Когда хидер на файле уже создан, его можно ужать до актуального размера с помощью команды luksHeaderBackup:
Идём далее. Следующая команда по ссылке:
С учётом вышеприведённых замечаний она эквивалентна такой:
Следующие команды:
Это усложнение (первая команда) просто не нужно — cryptsetup сам догадается рассмотреть файл как блочное устройство, поэтому можно писать напрямую:
Теперь вернёмся к самому вопросу. Да, метод правильный и логичный: вместо двойного шифрования просто пользоваться откреплённым хидером. Думаю, его можно было бы класть отдельным файлом в /boot. В крайнем случае, можно было бы создать отдельный дисковый раздел на загрузочном носителе, и класть хидер туда в виде файла (или сам этот дополнительный дисковый раздел использовать как хидер).
Проблемы могут быть только в автоматизации процесса и в установке системы на такую конфигурацию. При установке внешний бессигнатурный слой всё равно создавался вручную (см. пункт 3[link78]), поэтому отличий не будет — точно так же в командной строке создаём и устройство и хидер. Понятно, что в crypttab инсталлятор вряд ли догадается прописать хидер, поэтому первая загрузка будет в ручном режиме с указанием всех опций cryptsetup'а из командной строки grub'а, но потом можно будет crypttab подправить на нужный — вдруг можно добиться автоматической загрузки и для такой конфигурации? Первая строчка crypttab'а должна быть, думаю, какой-то такой:
Последнее, на что стоит обратить внимание — опция --align-payload. Если она везде указывалась в версии 1.6.6, оффсет будет всё равно ненулевой (и если не указывалась, то тоже). Потом вы обновляете систему и получаете cryptsetup 1.6.7, где опция трактуется правильно — соответственно, автоматическая загрузка сыпется, всё перестаёт работать. Конечно, указанием правильного значения для --align-payload всё можно будет поправить, чтоб работало, как и раньше, но учтите этот подводный камень — можете в будущем об него споткнуться.
Вижу, что опять задал простой вопрос. :-) Большое спасибо, уже пробую.
Возник легкий практический затык на пользовательском уровне. Если загрузочная файловая система на внешнем носителе всего 100MiB (включая MBR), то в рамках обновления системы не хватает места для обновления /boot. Вижу всего два варианта решения – или перед каждым обновлением ядра увеличивать ФС с /boot на борту и потом умешьшать обратно (проверено с некоторыми диск-менеджерами и разными ФС, работает без ошибок), или размер ФС увеличить перманентно.
Есть еще варианты?
Второй пользовательский затык. Порядок действий: грузимся с Live-CD, записываем загрузочный раздел на флешку с бессигнатурно шифрованного харда, перезагружаемся, делаем плановое обновление системы. Теперь хотим записать обновленный загрузочный раздел с флешки обратно на хард, но не тут то было. В запущенной системе уже имеются подмонтированные разделы с данного харда, поэтому система не позволяет подмонтировать другую область того же самого харда, где хранится загрузочный раздел для флешки. Это означает, что надо опять грузиться с болванки для одной единственной операции.
Как сделать наиболее эфективно, чтобы было поменьше действий?
Если места на самом носителе, используемом как загрузочный, достаточно, никто не запрещает аналогичным образом использовать, например 200MiB вместо ста. Увеличить размер ФС проще, чем уменьшить. Раз вам удалось сжать до 100, почему бы не повторить процедуру для 200? Можно вообще всё пространство носителя использовать как загрузочное, а затирать только начало — вы же сами убедились, что за пределами какого-то числа первых секторов данные всё равно не пишутся.
Не понимаю, зачем вам такие сложности. Какая разница, куда на бессигнатурно шифрованном носителе будет сохранён загрузочный образ? Сохраняйте его просто файлом на какой-либо внутренней файловой системе на нём — именно её вы и должны монтировать с LiveCD, чтобы забрать оттуда образ (снимаете бессигнатурный слой, потом LUKS, потом LVM, потом на какой-то стадии добираетесь до ФС, оттуда выцепляете файл с загрузочным образом и записываете его на временный загрузочный носитель). Можете загрузочный образ хранить хоть в корневой файловой системе: главное — что с LiveCD вы до любой информации на этом носителе можете добраться, где бы и как бы она ни была записана.
После последнего обновления ядра система при загрузке начала подвисать на минуту-две перед тем, как показать меню grub'а (далее загрузка идёт, как и раньше). Пока она подвисает, идёт активное обращение к носителю (что она при этом с ним делает — непонятно). Загрузочный образ без последнего обновления с этого же носителя грузится без задержек. Что они могли сломать при bugfix-обновлении стабильного релиза? Была ошибка в grub'е с обходом пароля, разве что, но в данном случае он не использовался.
Хорошо, что хоть вообще ОС грузится. Эта новость лишний раз подтверждает нестандартность и опасность всей схемы. Например, по этой причине могли отвалиться все обновления ОС: пока проблемы не решишь, пришлось бы работать на необновлённом ядре с дырами.
Последующее обновление системы устранило эту проблему; теперь всё снова работает так же, как и раньше.
Ресайз сделал — всё работает, как и описывал. Берём готовый внешний загрузочный носитель, монтируем его в /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 записываем наш образ загрузчной флешки. Когда всё готово, перекидываем его самим себе:
Это работает. Странно, что хотя 'hd1,msdos1' более не пишется, grub это не смущает. Если подключение (монтирование) /boot и отмонтирование скриптовать, после/перед xl-командами следует сделать паузы хотя бы в 1 сек через "sleep 1", потому что виртуальное устройство появляется/исчезает не моментально.
Кстати, Xen умеет очищать RAM от старых данных перед загрузкой: добавляем опцию
В рамках работы над совершенствованием системы решил пошагово проверить затирание части флешки[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
Есть умные программы со сложной логикой, предназначение которых — продумывать детали за вас, пользователя. Когда вы используете такие программы, не удивляйтесь, что эти интеллектуальные исполнители ваших желаний продумают детали за вас, опираясь на свою логику и широко экстраполируя ваши намерения на те тонкости действия, которые вы явно не оговорили (явно оговорить не всегда бывает возможно).
Gparted — GUI-шная приблуда к parted, который сам по себе не так прост как кондовый fdisk. Каждый следующий уровень усложняет логику и контроль простых действий. Делайте всё простыми предсказуемыми инструментами — и не будет никаких сюрпризов.
Возможно, там использовалось какое-то выравнивание геометрии, из-за чего конец оказался неразмечен, а потом завайплен нулями. Возможно, конец как-то предполагается использовать в качестве резервного места хранения для таблицы разделов. По вашему описанию ничего похожего в сети не ищется, а своего опыта с parted у меня нет — остаётся только гадать.
Говоря простым языком, ваш комментарий сводится к следующему: при первичном форматировании диска и установке MBR parted зачем-то пишет нули в конце диска, но при последующей работе с дисковыми разделами этого не наблюдается — конец не трогается.
Прекрасно сказано! :-)
Совершенно точно.
А вообще, меня здесь пугают две собственные ошибки:
1. не была сделана пошаговая проверка
2. действие, обеспечивающее безопасность (окончательная рандомизация неразмеченной поверхности флешки, т.е. не подготовительная – перед разметкой, а окончательная – перед началом использования флешки по назначению) должно было быть сделано как последнее
Эти ошибки безопасность не затронули, поскольку, ввиду понятных причин, флешка после бута всегда затиралась полностью и дважды. Т.е. безопасность была обеспечена прямой мерой. Но сам факт, что в таких простых действиях можно жутко проколоться из-за собственной тупости, просто пугает. :-)
Можно было короче:
Тупыми легче управлять. Выбирайте тупые программы.
Нет, вы всё правильно сделали. Не должен разметчик диска писать непонятно что непонятно куда. Возможно, это даже баг, но проверять ваши действия у меня нет ни времени, ни мотивации. Ваша ошибка только в том, что взяли вместо предсказуемого fdisk непредсказуемый Gparted.
Эти продвинутые вещи (parted) нужны для GPT-разметки. Если у вас не GPT, а стандартная MsDOS-разбивка, зачем переусложнять вещи? То, что вы проверили неизменность неразмеченного пространства — сделали правильно. Ничему на 100% доверять нельзя.
По правде сказать, я бы на вашем месте, если б использовал fdisk, даже не делал бы таких проверок, потому что сама идея, что fdisk будет писать не пойми чего в конец диска, противоречит всем моим представлениям, да и проверка неизменности неразмеченного дискового пространства для больших дисков может занять много часов.
В будущем их у вас будет ещё много, целый кладезь. Не расстраивайтесь, все через это проходили. Лучше поздно, чем никогда.
Чей-то блогпост с похожими идеями: Encrypting your HDD with plausible deniability[link82].
Была небольшая проблема[link83].
Решение простое до безобразия. Сделать второй маппинг на том же устройстве позволяет опция --shared утилиты cryptsetup.
Да. Помимо прочего, есть много глюков, которые решаются созданием дополнительного маппинга устройства через 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.
Нет. Можно и так и так. Нешифрованным будет каталог grub. Шифрованным – весь остальной boot с initramfs и ядрами. Меню граба будет выведено без пароля. Пароль будет запршен позже при попытке открыть раздел, указанный в конфигурации выбранной строки в граб-меню. На уровне хауту это описано в хакере[link88] (Способ там формально рабочий, но кривой, потому что нужно руками вносить опции в конфиг граба. update-grub нужные опции перезапишет при первом же обновлении. Правильно – писать свои хуки с кодогенератором конфига, которые будут читаться при каждом update-grub).
Стандартный grub поддерживает часть функционала cryptsetup (LUKS) через собственные модули. Там нет полной совместимости. Нельзя указать хидер для LUKS и нельзя использовать plain mode – только обычное LUKS-устройство с встроенным хидером. Некоторые предлагают ступенчатую загрузку, когда один grub грузит другой grub с шифрованного раздела, но смысл затеи непонятен.
Есть проект grub-DeLUKS[link89], который устраняет эти недостатки, но в апстрим его не приняли. Если его установить, выйдет, что загрузчик использует специальный софт для отрицаемости, и эта отрицаемость потеряется. Аналогичная история с обычным cryptsetup – cryptsetup-DeLUKS[link90].
Будьте добры, нужна помощь. Боюсь расковырять все до полностью нерабочего состояния.
Схема системы: раздел /boot на флешке, вся остальная система лежит на бессигнатурно шифрованном харде, после бута отмонтировывается /boot и флешка затирается.
Я обновляю систему исключительно после свежего бута. Поскольку в таком состоянии не требуется предварительное подмонтирование раздела /boot. Следующим шагом является запись нового содержимого флешки на отдельный носитель и ее затирание.
Думается, что после очередного обновления я забыл записать новое содержимое флешки на отдельный носитель. Поэтому на нем осталось старое старое содержимое. И когда я записал его на флешку для очередного запуска системы, система нормально запустилась, но перестала читать ФС одного из дисков, который используется под свалку устаревших пользовательских данных. Этот диск я всегда расшифровывал и монтировал вручную. А теперь, при попытке примонтирования, ОС говорит, что не может найти ФС данного диска. Причем, с этим диском все абсолютно ОК, я тщательно проверял из-под лайва.
Как безопасно убедиться, что мое предположение правильно, и как исправить эту фигню?