Perhaps it would be better to just remove the feature given that it has never worked and that it is impossible to make it work in all situations (sector remapping, most SSDs, old sectors, network block devices).
It would be much better for distributions to "standardise" on an easy to use encrypted store for applications.
Something like a more generic version of AegisFS which Nokia made for the N9/N950 could be ideal:
Posted Oct 13, 2011 4:08 UTC (Thu) by idupree (subscriber, #71169)
[Link]
Do you have more information on AegisFS? I could tell from your link and Google that it's a FUSE filesystem that cryptographically hides data, and that it has an (unrelated?) affinity with .zip files. If the documentation doesn't say it does everything that this ext4 secure-delete feature does for you, then it probably doesn't.
This deletion feature already goes beyond what you get from using either of two popular Linux crypto filesystems:
If you use LUKS/dm-crypt and you "rm" a file. If you securely delete it then no one can ever read it (except by physical surgery on the hard drive or other copies of the data). If you plainly delete it, the data persists, and if someone breaks your encryption* then they might still be able to read it. (*via live system compromise, or someone guessing your encryption password, or your mind having a fit of remorse (or coercion) and wanting to read the data even though your company or past self wanted it deleted, etc.)
If you use eCryptfs, it currently doesn't even attempt to hide the filenames. ( http://ecryptfs.sourceforge.net/ecryptfs-faq.html#filenam... ). This article's secure delete does attempt to delete the filenames. I don't see anything about secure deletion in this eCryptfs FAQ either, so relying on eCryptfs may also have the same risks I described under LUKS/dm-crypt.
Even a single pass of overwriting with zeroes, even on a drive with sector remapping, would prevent casual electronic attacks: someone would have to physically obtain and open the drive to get the data out. (Or the drive could have firmware bugs. Alas. Is this common?) Neither layers that stack under the filesystem (dm-crypt) or over (eCryptfs; maybe AegisFS) quite have the ability to make a file impossible for root-with-all-the-passwords to access again (well, dm-crypt can do it by removing the whole filesystem at once...).
Securely deleting files from ext4 filesystems
Posted Oct 13, 2011 4:29 UTC (Thu) by idupree (subscriber, #71169)
[Link]
Actually, perhaps eCryptfs allows encrypting filenames now; that FAQ looks out of date. I am trying to find if there is a current, authoritative or thorough, source of documentation.
Securely deleting files from ext4 filesystems
Posted Oct 13, 2011 16:58 UTC (Thu) by bronson (subscriber, #4806)
[Link]
Maybe the FAQ meant "shared encryption of filenames is a planned feature?"
File sizes and directory structure, however, are not. They can still leak a fair amount of information. For me that's no big deal... I don't mind too much if someone figures out where I store my financial documents as long as they can't read the names and numbers.
Securely deleting files from ext4 filesystems
Posted Oct 13, 2011 5:02 UTC (Thu) by lemmings (subscriber, #53618)
[Link]
Unfortunately there is not much in the way of docs available. The source code is at:
ecryptfs could work great for applications with a little bit of magic to provide a C library which would mount a ecryptfs directory into the process's name space (using unshare(2)). Would need to figure out how to do key management though.. Not sure if there is a freedesktop.org standard yet..
Securely deleting files from ext4 filesystems
Posted Oct 13, 2011 7:09 UTC (Thu) by djwong (subscriber, #23506)
[Link]
The use of the adverb "securely" is a bit unfortunate. As you point out, ext4 can't control the behavior of the underlying hardware, which means that it can't guarantee that the deletion is actually secure. You might have a SCSI bus analyzer that records every write sent to the drive, in which case ext4 tells you that the deletion is "secure" ... but someone else can easily reconstruct the file.
A better name would be "make this file difficult to recover or undelete at the /dev/sdX block device interface level" delete, but that's clunky. I suspect that this attribute is sort of an opposite to chattr +u, if you will.