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

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

sdmem из пакета secure-delete.

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

О sdmem и не только

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

https://www.pgpru.com/comment82155

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

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

После pkill надо бы ещё удалять юзерские файлы из /tmp (те, которые нельзя удалить, обнулять).


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


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

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


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


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


С гипервизором будут примерно те же проблемы. Автоматически оперативка от гостевых систем надёжно не очищается, всё равно нужен sdmem.

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

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


Да, и все данные гостя находятся всё в той же RAM. При отключении LUKS сбрасывается ключ, но не сами закешированные данные. Их надо чистить с помощью sdmem.

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

Это почему?

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

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


Можно вводить в гостевой (т.е. шифровать средствами гостевой), но зачем? Цель виртуалки – запуск потенциально опасного кода, чреватого исполнением малвари. Если в гостевой системе появляется уязвимость, малварь может сделать дамп мастер-ключа криптораздела и слить его по сети. У неё этого не выйдет, если слой шифрования снимается на хосте, а не в госте. Вместо передачи условного /dev/sdb в гостевую систему можно передавать какой-нибудь /dev/mapper/sdb_crypt, который появляется после открытия sdb на хосте как cryptsetup luksOpen /dev/sdb sdb_crypt.

Так я понял.

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

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

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

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


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


Для потенциально опасной сетевой хрени нужна одна гостевая ОС, для конфиденциальной – другая. Для каждой задачи должна быть своя гостевая ОС. Если железо позволяет, можно одновременно запустить хоть десяток разных гостевых ОС, а можно запускать и неодновременно.