id: Гость   вход   регистрация
текущее время 00:48 29/03/2024
Автор темы: ressa, тема открыта 29/07/2014 10:40 Печать
Категории: криптография, инфобезопасность, защита дисков, алгоритмы, операционные системы
https://www.pgpru.com/Форум/UnixLike/МаскировкаВводаПароляВCryptsetup
создать
просмотр
ссылки

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


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


 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии
— pgprubot (06/07/2015 16:15, исправлен 06/07/2015 16:19)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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



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



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


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

— pgprubot (09/07/2015 22:16, исправлен 09/07/2015 22:22)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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


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



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

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



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



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


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

— pgprubot (10/07/2015 00:19, исправлен 10/07/2015 00:23)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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

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


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

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

— pgprubot (10/07/2015 19:51, исправлен 10/07/2015 20:11)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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


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


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


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


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


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



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

— Yellow (19/07/2015 14:42)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

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

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

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


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



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


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

— Yellow (28/07/2015 18:59)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4
pgprubot,
спасибо за подробное объяснение. Уже ковыряюсь.
— pgprubot (28/07/2015 20:08, исправлен 28/07/2015 20:14)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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



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



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


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



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

— Yellow (29/07/2015 09:43, исправлен 29/07/2015 09:53)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

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


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


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



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



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


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


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


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

— pgprubot (29/07/2015 16:37, исправлен 29/07/2015 16:59)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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



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



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



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

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


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

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


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

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


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

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



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



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


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

— Yellow (01/08/2015 09:56, исправлен 01/08/2015 10:01)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

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



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



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

— pgprubot (02/08/2015 05:29, исправлен 02/08/2015 06:36)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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



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



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


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


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


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


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


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

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


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

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


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

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


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


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


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

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

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


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


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


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


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


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


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



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



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

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

— Yellow (08/08/2015 16:08, исправлен 08/08/2015 16:26)   профиль/связь   <#>
комментариев: 64   документов: 0   редакций: 4

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



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


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


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


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


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



sdmem


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



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


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


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


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


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

— pgprubot (09/08/2015 15:04, исправлен 09/08/2015 15:28)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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



Возможно:


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

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



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



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


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

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

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


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

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


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



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



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



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


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

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



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



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

— pgprubot (12/08/2015 21:52, исправлен 12/08/2015 22:14)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

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


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



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


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

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