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

Іноді виникає необхідність видалити файл у файловій системі та переконатися, що файл справді зник. Файл, який містить чутливі паролі, наприклад, слід ретельно витирати з диска.

Випуск простого rmв типовій файловій системі видаляє inode ("покажчик") у файл, але він не видаляє вміст файлу на фізичному диску - вони залишаються там, поки вони не будуть перезаписані, коли файловій системі потрібен вільний простір.

У багатьох файлових системах програма shred забезпечує таке безпечне видалення. Однак у файловій системі CoW, такі як btrfs, такий підхід марний . Проблема посилюється тим, що файл може бути присутнім на знімках гучності.

Чи є спосіб безпечно видалити файл у файловій системі btrfs? Чи достатньо видалити всі покажчики (на всі томи) та заповнити вільний простір нулями ?

Безпечне видалення - сувора пропозиція для будь-якої файлової системи. Якщо файлова система не є дуже своєрідною і не гарантує відсутність інших копій файлу, вам потрібно очистити весь вільний простір на пристрої. Хоча ви, швидше за все, знайдете багато біт файлу у файлових системах копіювання під час запису, навіть більше "статичних" файлових систем на практиці не мають такої гарантії, оскільки багато файлів редагуються, тому в попередніх версіях файлів файл, що лежить навколо.

Зауважте, що стирання з нулями так само добре, як і стирання з випадковими байтами, і вам не потрібно кілька пропусків. Стирання з нулями залишило залишкові дані, які можна було частково відновити в лабораторних умовах за допомогою технологій жорсткого диска 1980 року; сьогодні це більше не застосовується. Див. Чому записувати нулі (або випадкові дані) на жорсткий диск у кілька разів краще, ніж просто робити це один раз?

Ви можете позбутися конфіденційних даних Cleartext, зашифрувавши все на диску. Налаштуйте том шифрувальної файлу над цією файловою системою та перемістіть до неї всі (конфіденційні) файли. Потім перезапишіть весь невикористаний простір файлової системи. Ви можете видалити більшу частину, заповнивши файлову систему cat /dev/zero >zero. У неповних блоках може залишитися деяка інформація (блоки, які містять останній фрагмент файлу, а потім - сміття - яке може залишитися від конфіденційного файлу). Щоб переконатися у відсутності незавершених блоків, перемістіть усе у файловій системі до ecryptfs (файли ecryptfs використовують цілі блоки, принаймні, у типових установках, де блоки розміром 4 кБ). Не забудьте застосувати це до всіх томів і стерти всі знімки, що містять конфіденційні дані в простому тексті.

У журналі може залишитися деяка інформація. Я не знаю, як це очистити.

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

Гммм, btrfs ніби перемагає всі звичні способи подрібнення ...

• Існує параметр монтування, який називається, nodatacowале це, схоже, не впливає на вже наявні файли.
• Оскільки у вас вже є чутливі файли на вашому диску, запис btrfs FAQ також вам не допоможе.
• Тоді є debugfs. Це лише для файлових систем ext, але для неї може працювати патч . Ви можете використовувати його, щоб дізнатися адреси порушених блоків, а потім перезаписати їх безпосередньо на / dev / sdXY. Але це дуже небезпечно і може не спрацювати (особливо, якщо є більше знімків файлу)
• Напишіть патч btrfs, який дозволяє змінювати (або подрібнювати) конкретні знімки або цілий файл

• Найчистішою спробою (для дійсно чутливих даних) було б:

  • придбайте інший диск (якщо у вас недостатньо вільного місця для копії пошкодженого розділу на перший)
  • налаштування повного шифрування диска та ваших файлових систем на ньому
  • скопіюйте все з диска a на b
  • завантажтеся в систему b і подрібніть весь диск ...

  Це може бути не найдешевшим підходом, але враховуючи нині низькі витрати на зберігання та проблеми, які ви матимете з іншими варіантами, він може бути насправді найдешевшим (з точки зору трудових годин).

Є shred(1)для Unix / Linux (має бути в пакетах вашого дистрибутива). Це те, що рекомендує EFF .