Hapus file dengan aman pada sistem file btrfs

22

Terkadang, ada kebutuhan untuk menghapus file dalam sistem file, dan memastikan bahwa file tersebut benar-benar hilang. File yang berisi kata sandi sensitif, misalnya, harus dihapus dari disk secara menyeluruh.

Mengeluarkan sederhana rmpada sistem file biasa menghapus inode ("pointer") ke file, tetapi tidak menghapus konten file dalam disk fisik - ini dibiarkan di sana sampai ditimpa ketika filesystem membutuhkan ruang kosong.

Pada banyak sistem file, program yang rusak memungkinkan penghapusan yang aman. Namun, pada sistem file CoW seperti btrfs, pendekatan ini tidak berguna . Masalahnya diperburuk oleh fakta bahwa file tersebut mungkin ada pada snapshot volume.

Apakah ada cara untuk menghapus file dengan aman pada sistem file btrfs? Apakah cukup untuk menghapus semua petunjuk (pada semua volume) dan mengisi ruang kosong dengan nol ?

filesystems security data-recovery btrfs goncalopp
sumber
2
Pertanyaan bagus, saya belum memikirkan masalah itu sebelumnya. Salah satu cara untuk mengatasi masalah itu adalah dengan mengenkripsi file tersebut. Anda juga dapat mengenkripsi seluruh disk tetapi jika penyerang mendapatkan akses root ke sistem yang sedang berjalan, itu tidak akan membantu Anda ...
mreithub
@mreithub Memang, mengenkripsi file seperti itu selalu merupakan ide yang baik, seperti halnya FDE. Meskipun demikian, ia tidak dapat merenungkan semua kasus penggunaan (sistem tertanam, misalnya - meskipun dapat diperdebatkan apakah sistem tersebut akan menjalankan btrfs ...). Saya sebenarnya menanyakan ini karena saya lupa mengatur enkripsi sebelum menyalin file sensitif, tetapi saya ingin menghindari menghapus seluruh partisi
goncalopp

Jawaban:

9

Penghapusan aman adalah proposisi yang sulit pada sistem file apa pun. Kecuali jika filesystemnya sangat aneh dan menjamin bahwa tidak ada salinan lain dari file tersebut, Anda perlu membersihkan semua ruang kosong pada perangkat. Walaupun Anda lebih cenderung menemukan banyak bit file pada sistem file copy-on-write, bahkan lebih banyak sistem file "statis" tidak memiliki jaminan ini dalam praktiknya, karena banyak file dapat diedit, sehingga ada bit dari versi sebelumnya File tergeletak di sekitar.

Perhatikan bahwa menghapus dengan nol sama baiknya dengan menghapus dengan byte acak, dan Anda tidak perlu beberapa lintasan. Menghapus dengan nol meninggalkan data residual yang dapat dipulihkan sebagian dalam kondisi lab dengan teknologi hard disk 1980-an; ini tidak berlaku lagi hari ini. Lihat Mengapa menulis angka nol (atau data acak) pada hard drive beberapa kali lebih baik daripada hanya melakukannya sekali?

Anda dapat menyingkirkan data rahasia cleartext dengan mengenkripsi semua yang ada di disk. Atur volume ecryptfs di atas sistem file itu dan pindahkan semua file (rahasia) Anda ke sana. Kemudian timpa semua ruang yang tidak digunakan pada sistem file. Anda dapat menghapus sebagian besar dengan mengisi sistem file dengan cat /dev/zero >zero. Mungkin masih ada beberapa informasi yang tersisa di blok yang tidak lengkap (blok yang berisi potongan file terakhir, diikuti oleh beberapa sampah - yang bisa jadi sisa dari file rahasia). Untuk memastikan bahwa tidak ada blok yang tidak lengkap, pindahkan semua yang ada di sistem file ke ecryptfs (file ecryptfs menggunakan seluruh blok, setidaknya pada pengaturan tipikal di mana blok adalah 4kB). Pastikan untuk menerapkan ini pada semua volume dan untuk menghapus semua snapshot yang berisi data rahasia plaintext.

Mungkin masih ada beberapa informasi yang tersisa di jurnal. Saya tidak tahu cara menggosok itu.

Pada SSD, karena memblokir realokasi, mungkin ada data yang tersisa yang tidak dapat dibaca oleh perangkat lunak normal tetapi dapat dipulihkan dengan meretas firmware atau dengan akses fisik. Di sana satu-satunya jalan Anda adalah penghapusan penuh SSD.

Gilles 'SANGAT berhenti menjadi jahat'
sumber
3
Nol memiliki kelemahan bahwa mereka dapat dikompres atau dihilangkan seluruhnya (SSD dapat TRIM alih-alih menulis nol, karena sektor TRIM akan mengembalikan nol ketika Anda membacanya). Itu membuat nol tidak aman saat ini. Menggunakan data acak memaksa filesystem dan disk untuk benar-benar menuliskan data apa adanya.
frostschutz
@ frostschutz Apakah menulis karakter selain 0ok, dan tidak tunduk pada TRIMing, katakan saja menulis semua 1? Atau apakah beberapa drive menggunakan kompresi pada semuanya?
Xen2050
@frostschutz Jika Anda mengisi volume ecryptfs dengan nol (yang saya pikir jawabannya mengusulkan di sini, meskipun, pada pemeriksaan lebih lanjut, saya melihat frasa itu sebenarnya ambigu), maka Anda akan menulis pada dasarnya acak (tidak terkompresi / tidak dapat dihapus) data ke disk, bukan?
JamesTheAwesomeDude
@JamesTheAwesomeDude Tidak, saya mengusulkan untuk menulis nol ke bagian yang tidak terenkripsi, tetapi saya menyebutkan bahwa ini tidak cukup pada SSD lebih jauh di bawah.
Gilles 'SANGAT berhenti menjadi jahat'
6

Hmmm, btrfs tampaknya mengalahkan semua metode merobek-robek yang biasa ...

  • Ada opsi mount yang dipanggil nodatacowtetapi tampaknya tidak mempengaruhi file yang sudah ada.
  • Karena Anda sudah memiliki file yang masuk akal pada disk Anda, entri FAQ btrfs ini juga tidak akan membantu Anda.
  • Lalu ada debugfs. Ini hanya untuk sistem file ext tetapi ada patch untuk itu yang mungkin berfungsi. Anda dapat menggunakannya untuk mengetahui alamat blok yang terkena dampak dan kemudian menimpa mereka langsung di / dev / sdXY. Tapi itu sangat berbahaya dan mungkin tidak berfungsi (terutama jika ada lebih banyak snapshot file)
  • Tulis patch btrfs yang memungkinkan seseorang untuk memodifikasi (atau menghancurkan) snapshot tertentu atau seluruh file

  • Upaya terbersih (untuk data yang benar-benar sangat sensitif) adalah dengan:

    • beli disk lain (kecuali Anda punya cukup ruang kosong untuk salinan partisi yang terpengaruh pada yang pertama)
    • buat enkripsi disk lengkap dan sistem file Anda di atasnya
    • salin semuanya dari disk a ke b
    • boot ke sistem b dan rusak seluruh disk ...

    Ini mungkin bukan pendekatan termurah tetapi mengingat biaya penyimpanan yang rendah saat ini dan masalah yang Anda miliki dengan opsi lain itu mungkin sebenarnya yang termurah (dalam hal jam kerja).

mreithub
sumber
nodatacowmenetapkan status default Cbendera untuk file yang baru dibuat . Tentunya salah satu bisa saja chattr +C ~/.browser/logins.sqlitedan kemudian shreditu?
JamesTheAwesomeDude
-6

Ada shred(1)untuk Unix / Linux (harus ada dalam paket distribusi Anda). Itulah yang direkomendasikan EFF .

vonbrand
sumber
3
Jika Anda memeriksa ulang pertanyaannya, Anda akan melihat bahwa saya sebutkan rusak, dan mengapa itu tidak cukup untuk pekerjaan itu
goncalopp
Yang saya temukan hanyalah saran untuk menggunakan enkripsi file sensitif, untuk alasan yang Anda sebutkan.
vonbrand
2
"Pada banyak sistem file, program rusak memungkinkan penghapusan yang aman. Namun, pada sistem file CoW seperti btrfs, pendekatan ini tidak berguna." Ada dua tautan di sana juga.
goncalopp