Безопасное удаление файлов в файловой системе btrfs

22

Иногда необходимо удалить файл в файловой системе и убедиться, что файл действительно удален. Например, файл, содержащий конфиденциальные пароли, должен быть полностью удален с диска.

Выпуск простого rmфайла в типичной файловой системе удаляет индекс («указатель») для файла, но не удаляет содержимое файла на физическом диске - они остаются там до тех пор, пока не будут перезаписаны, когда файловой системе потребуется свободное место.

Во многих файловых системах программа уничтожения обеспечивает такое безопасное удаление. Однако в файловой системе CoW, такой как btrfs, этот подход бесполезен . Проблема усугубляется тем, что файл может присутствовать на снимках тома.

Есть ли способ безопасно удалить файл в файловой системе btrfs? Достаточно ли удалить все указатели (на всех томах) и заполнить свободное место нулями ?

— goncalopp
источник

2

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

— mreithub

@mreithub Действительно, шифрование таких файлов всегда хорошая идея, как и FDE. Тем не менее, он не может рассматривать все варианты использования (например, встроенную систему - хотя можно спорить, будет ли такая система в любом случае запускать btrfs ...). Я на самом деле спрашиваю об этом, потому что я забыл настроить шифрование перед копированием конфиденциальных файлов, но я хотел бы избежать стирания всего раздела

— goncalopp

9

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

Обратите внимание, что стирание с нулями так же хорошо, как стирание со случайными байтами, и вам не нужно многократных проходов. Стирание с нулями оставило остаточные данные, которые можно было частично восстановить в лабораторных условиях с технологиями жестких дисков 1980-х годов; это больше не применимо сегодня. См. Почему запись нулей (или случайных данных) на жесткий диск в несколько раз лучше, чем просто сделать это один раз?

Вы можете избавиться от конфиденциальных данных открытым текстом, зашифровав все на диске. Настройте том ecryptfs над этой файловой системой и переместите все свои (конфиденциальные) файлы в нее. Затем перезаписать все неиспользуемое пространство файловой системы. Вы можете стереть большинство из них, заполнив файловую систему cat /dev/zero >zero. В неполных блоках все еще может оставаться некоторая информация (блоки, содержащие последний фрагмент файла, за которым следует мусор, который может быть остатком из конфиденциального файла). Чтобы гарантировать отсутствие незавершенных блоков, переместите все в файловой системе в ecryptfs (файлы ecryptfs используют целые блоки, по крайней мере, в типовых установках, где блоки имеют размер 4 КБ). Обязательно примените это ко всем томам и сотрите все снимки, содержащие незашифрованные конфиденциальные данные.

Возможно, в журнале осталась некоторая информация. Я не знаю, как это почистить.

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

— Жиль "ТАК - перестань быть злым"
источник

3

Недостатки имеют недостаток, заключающийся в том, что они могут быть сжаты или полностью пропущены (SSD может записывать TRIM вместо записи нулей, поскольку сектора TRIM возвращают нули при их чтении). Это делает нули небезопасными в наше время. Использование случайных данных вынуждает файловую систему и диск фактически записывать данные как есть.

— frostschutz

@frostschutz Будет ли писать любой символ, кроме 0как в порядке, и не подпадает под действие TRIMing, скажем, писать все 1вместо? Или некоторые диски используют сжатие на всем?

— Xen2050

@frostschutz Если вы заполняете том ecryptfs нулями (как я и думал, здесь предлагается ответ, хотя, при дальнейшем рассмотрении, я вижу, что его формулировка на самом деле неоднозначна), то вы будете писать практически случайно (несжимаемо / нет данных) данных на диск, нет?

— JamesTheAwesomeDude

@JamesTheAwesomeDude Нет, я предлагал записать нули в незашифрованную часть, но я упомянул, что этого недостаточно для SSD ниже.

— Жиль "ТАК - перестань быть злым"

6

Хммм, кажется, btrfs побеждает все обычные методы измельчения ...

Существует опция монтирования, nodatacowно она не влияет на уже существующие файлы.
Поскольку у вас уже есть разумные файлы на вашем диске, эта запись часто задаваемых вопросов btrfs вам тоже не поможет.
Тогда есть debugfs. Это только для файловых систем ext, но есть патч, который может сработать. Вы можете использовать его, чтобы узнать адреса затронутых блоков, а затем перезаписать их непосредственно в / dev / sdXY. Но это очень опасно и может не сработать (особенно если есть больше снимков файла)
Напишите патч btrfs, который позволяет модифицировать (или уничтожать) определенные снимки или целый файл.
Самая чистая попытка (для действительно очень важных данных) будет:
- купите другой диск (если у вас недостаточно свободного места для копии поврежденного раздела на первом)
- настроить полное шифрование диска и ваши файловые системы на нем
- скопировать все с диска а на б
- загрузиться в систему b и уничтожить весь диск ...
Это может быть не самый дешевый подход, но с учетом сегодняшних низких затрат на хранение и проблем, которые могут возникнуть у вас с другими вариантами, он может быть самым дешевым (с точки зрения рабочего времени).

— mreithub
источник

nodatacowустанавливает статус Cфлага по умолчанию для вновь создаваемых файлов. Конечно, кто-то мог просто chattr +C ~/.browser/logins.sqliteи тогда shredэто?

— JamesTheAwesomeDude

-6

Есть shred(1)для Unix / Linux (должно быть в пакетах вашего дистрибутива). Я то, что рекомендует EFF .

— vonbrand
источник

3

Если вы дважды проверите вопрос, то увидите, что я упомянул клочок и почему этого недостаточно для работы

— goncalopp

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

— vonbrand

2

«Во многих файловых системах программа уничтожения обеспечивает такое безопасное удаление. Однако в файловой системе CoW, такой как btrfs, этот подход бесполезен». Там тоже есть две ссылки.

— goncalopp