Безопасность спящего режима компьютера
При отправке компьютера в спящий режим сеанс сохраняется на жестком диске. При включении компьютера, после загрузки базовых компонентов системы, достаточно лишь ввести пароль пользователя, после чего на мониторе появляется (достаточно быстро) рабочий стол с открытыми теми программами, которые были в работе на момент завершения работы компьютера. Однако заставляет задуматься следующий факт, учитывая, что в системе используется шифрование учетной записи, хотя и стандартным способом системы, который предлагается при создании учетной записи (система Ubuntu 10/04).
А именно: учитывая очень быстрое открытие программ можно предположить, что при включении машины данные либо расшифровываются БЕЗ РУЧНОГО ввода пароля, а ввод пароля лишь разблокирует доступ к монитору, либо сохраняются в контейнер спящего режима без зашифровки. Выходит, что к пользователським данным можно получить доступ либо взяв их с винчестера, если они сохраняются в нешифрованном виде, либо включив компьютер постараться обойти блокировку монитора. Есть ли в моих рассуждениях доля истины?
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
Ну так ещё хуже.
Файлы подкачки, предотвращение утечек там же и Предотвращение утечек в файле hiberfil.sys, Отключение Восстановления Системы (System Restore) и другое.
Вроде бы своп шифруется и в открытую не читается. Как это сделано – черт его знает.
а это что?
Есть как часть функций DiskCryptor, насколько я помню. Проверяйте. Оно opensource.
комментариев: 9796 документов: 488 редакций: 5664
Если использовать рекламируемое unknownом иерархическое шифрование, то расшифровка корня приведёт к расшифровке всего остального. Поэтому самое надёжное – выключение, если нет уверенности что hibernate правильно сделан. А быть уверенным в хибернейте можно только если хорошо известно его устройство, в идеале нужно делать его самостоятельно.
комментариев: 9796 документов: 488 редакций: 5664
При ручном отмонтировании томов LUKS по идее принудительно стирает их ключ из памяти и он вообще старается до последнего не попадать в своп кроме случая гибернейта.
Однако при гибернейте в свопе накапливается много лишней потенциально опасной информации, которая вся зависит от безопасности корневого шифрования. В этом его потенциальная опасность и компромиссность.
Поэтому в моём варианте своп шифруется дважды. Как самим фактом размещения логического своп-раздела на шифрованном физическом. Так и шифрованием производным ключом от физического раздела. Это позволяет мгновенно стереть ключ шифрования из LUKS слота своп-файла (при этом запись-чтение на этом ключе в своп продолжатся, в памяти то он продолжает висеть). А затем при отсутствии необходимости гибернейта сделать poweroff. Тогда после повторного включения своп будет нерасшифровываемым, т.к. ключ от него будет навсегда утерян и все накопленные в нём данные пропадут. Это гораздо быстрее (пара секунд), чем перетирать своп после гибернейтов (десятки минут) или отсоединять его для перешифровывания на рабочей системе (минуты). После загрузки не из гибернейта своп (по желанию) заново подключается и форматируется в шифрованном виде. Поскольку он уже отсоединённый и пустой, это тоже занимает секунды.
Простой скрипт, правка пары конфигов и обновление initrd.