id: Гость   вход   регистрация
текущее время 11:50 30/03/2017
создать
просмотр
ссылки

Я использую дебиан, создал зашифрованный раздел с помощью cryptsetup luks, но вынужден часто открывать и закрывать его, не выключая рабочую машину. Теперь вопрос, остаётся ли ключ шифрования в оперативной памяти? Также интересно было бы узнать методы вайпа RAM на работающем компьютере.
Сейчас я делаю так:
# Убиваю все процессы юзера
pkill -9 -u <user>
# Вырубаю зашифрованный диск
umount /dev/mapper/crypt_disk
cryptsetup luksClose /dev/mapper/crypt_disk
# Наивно зачищаю оперативную память
dd if=/dev/zero of=/tmp/file
rm /tmp/file


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


 
Комментарии
— гыук (28/05/2016 21:55)   профиль/связь   <#>
комментариев: 244   документов: 0   редакций: 0

Сколько по времени можно делать слепок и при каких условиях?
— supervillain (28/05/2016 23:17)   профиль/связь   <#>
комментариев: 5   документов: 3   редакций: 4

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

sdmem из пакета secure-delete.
— гыук (29/05/2016 13:13, исправлен 29/05/2016 13:57)   профиль/связь   <#>
комментариев: 244   документов: 0   редакций: 0

sudo sh -c 'for i in 1 2 3; do sync; echo $i | tee -a /proc/sys/vm/drop_caches; done'


О sdmem и не только

— гыук (30/05/2016 19:16, исправлен 30/05/2016 20:53)   профиль/связь   <#>
комментариев: 244   документов: 0   редакций: 0

Посмотрите в сторону "TRESOR: шифрование за пределами ОЗУ"


https://www.pgpru.com/comment82155


А еще можно попробовать открывать данные через гипервизор. Его то выгрузить можно достаточно быстро.


Интересно для прочтения

— Гость_ (31/05/2016 01:44)   профиль/связь   <#>
комментариев: 411   документов: 5   редакций: 9
После pkill надо бы ещё удалять юзерские файлы из /tmp (те, которые нельзя удалить, обнулять).


В современных версиях достаточно сделать cryptsetup remove crypt_disk


Это если /tmp на tmpfs? Всё равно неправильно. Удалять, как уже сказали, через sdmem -fll. sdmem запускается после всего и вся. Команды работы с файлами юзера и закрытия его LUKS обычно выдаются под рутом – историю команд рута поэтому тоже лучше предварительно очищать, терминал закрывать, шелл и иксы рестартить.

Нельзя безопасно удалить файл с файловой системы. Надёжное удаление – только вместе с файловой системой (удалили слот LUKS на котором была файловая система). С очисткой памяти ситуация, возможно, та же: sdmem тупо забивает RAM данными, но нет гарантий, что приватные данные не останутся где-то в недрах процессов ядра, которые не убиваются и не рестартятся. По этой причине в Tails используют более хитрый метод очистки на основе kexec, но он, думаю, годится только при полном выключении системы или при выключении виртуальных машин, если правильно настроить. Насколько он правильный – непонятно, всестороннего анализа проблемы нигде не видел.


Можно вообще не делать, смысл будет тот же.


umount не стирает ключи.


С гипервизором будут примерно те же проблемы. Автоматически оперативка от гостевых систем надёжно не очищается, всё равно нужен sdmem.
— гыук (31/05/2016 22:48)   профиль/связь   <#>
комментариев: 244   документов: 0   редакций: 0

Почему такие же? Ключ вводится в вирт машине. Смысл использования для обеспечения изоляции вирт машины и хоста. Другой вопрос хост контролирует гостя, но это как раз другая история.
— Гость_ (01/06/2016 01:15)   профиль/связь   <#>
комментариев: 411   документов: 5   редакций: 9
Ключ вводится в хостовой системе. Можно делать шифрование дисков гостевой ОС средствами её самой, но это менее безопасно. С точки зрения хоста нет разницы для чего открывается LUKS – для запуска оттуда гостевой ОС или для подключения хоума какого-то юзера. Проблемы те же.


Да, и все данные гостя находятся всё в той же RAM. При отключении LUKS сбрасывается ключ, но не сами закешированные данные. Их надо чистить с помощью sdmem.
— гыук (02/06/2016 01:04, исправлен 02/06/2016 01:07)   профиль/связь   <#>
комментариев: 244   документов: 0   редакций: 0

В одном поезде, но в разных направлениях..



Это почему?


В VB (и не только) я могу примонтировать к гостю физический ж.д.( например так ) или usb-устройство с шифрованым разделом или полностью. Затем открыть его средствами гостевой системы. Ключ я буду вводить в таком случае в гостевой системе, а не в хосте. В чем я не прав?

— Гость_ (02/06/2016 09:45)   профиль/связь   <#>
комментариев: 411   документов: 5   редакций: 9

Потому, что так делать правильно.


Можно вводить в гостевой (т.е. шифровать средствами гостевой), но зачем? Цель виртуалки – запуск потенциально опасного кода, чреватого исполнением малвари. Если в гостевой системе появляется уязвимость, малварь может сделать дамп мастер-ключа криптораздела и слить его по сети. У неё этого не выйдет, если слой шифрования снимается на хосте, а не в госте. Вместо передачи условного /dev/sdb в гостевую систему можно передавать какой-нибудь /dev/mapper/sdb_crypt, который появляется после открытия sdb на хосте как cryptsetup luksOpen /dev/sdb sdb_crypt.
— гыук (02/06/2016 11:28, исправлен 02/06/2016 11:29)   профиль/связь   <#>
комментариев: 244   документов: 0   редакций: 0

Так я понял.



Да интересный аргумент. Контраргумент – "Кто как хочет, так и делает". :-)



По существу. Вы говорите в общем, я в частном. ТС озабочен остатками информации (ключа) в ОЗУ. Ход его мысли – Очитска ОЗУ. Как вариант, было предложено открывать зашифрованный раздел/диск/usb в виртуальной машине, специально организованной для этой задачи, дабы изолировать действия.



У вирт машин более широкий спектр использования. Да и нечего запускать всякую потенциально опасную "хрень" там, где собираешься работать с конфеденциальной инфой. Да решение не самое лучшее. Лучше завести отдельный изолированный от сети ПК/ноутбук/нетбук/ультрабук и выполнять действия с шифрованием/расшифрованием данных там, но ТС конкретизировал задачу. От этого и отталкиваемся.

— Гость_ (03/06/2016 03:13)   профиль/связь   <#>
комментариев: 411   документов: 5   редакций: 9

Кто хочет, может пострелять себе в ногу, послушав ваших советов – не спорю.


Есть две разные задачи – очистка ключа шифрования и очистка данных с шифрованного раздела, осевших в RAM. Первая задача решается и на гостевой и на хостовой системе одинаково надёжно – достаточно сделать luksClose или remove. Однако, если шифрование происходит средствами хостовой системы, это безопаснее по ряду вышеозвученных причин. Вторая задача – очистка данных – сама по себе не решается ни виртуалкой, ни самой ОС – нужен запуск sdmem в любом случае. После выключения гостевой ОС её данные по-прежнему могут находиться в свободной части RAM, которую предстоит зачистить через sdmem. Если бы виртуалка не использовалась, RAM после разлогина соответствующего пользователя и отключения его домашнего каталога так же пришлось бы чистить через sdmem. Да, виртуалка, возможно, делает процедуру пользования и чисток памяти более надёжной, но детальный анализ проблемы мне неизвестен.


Для потенциально опасной сетевой хрени нужна одна гостевая ОС, для конфиденциальной – другая. Для каждой задачи должна быть своя гостевая ОС. Если железо позволяет, можно одновременно запустить хоть десяток разных гостевых ОС, а можно запускать и неодновременно.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3