Hi, Can anyone please tell me if I am right in assuming that ext3 does not care about file slack? Specifically I am thinking about the use of the secure_delete utility which, includes "sfill" to do secure overwriting of the unused diskspace on the harddisk. I quote from the secure_delete README below for its modus operandi (I appreciate that some of this will not apply to sfill). Thanks, Geoff --- HOW THESE PROGRAMS WORK The deletion process goes like that : 1. The overwriting procedure, in the secure mode, does a 38 times overwriting. After each pass, the diskcache is flushed. 2. truncate of the file, so that an attacker don't know which diskblocks belonged to the file. 3. renaming of the file so that an attacker can't draw any conclusion from the filename on the contents of the deleted file. 4. finally deleting the file (unlink). Note that with v2.0 all secure_delete utilities work in secure mode (38 special passes). To lower the security and make it faster, you may add -l (one random pass, on 0xff pass) or -ll (one 0xff pass) to the parameters. The secure overwrite mode works that way: 1x overwrite with 0xff 5x random passes 28x overwriting with special values to make the recovery from MFM and RLL encoded harddisks hard/impossible - see Gutmann's paper on that which is also included. 5x random passes __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts uk.my.yahoo.com
Stephen C. Tweedie
2002-Nov-08 17:25 UTC
Re: ext3 and secure deletion of files and file slack
Hi, On Fri, Nov 08, 2002 at 03:57:20PM +0000, Geoff wrote:> Can anyone please tell me if I am right in assuming that ext3 > does not care about file slack?What do you mean, exactly? --Stephen
On Nov 08, 2002 15:57 +0000, Geoff wrote:> Can anyone please tell me if I am right in assuming that ext3 > does not care about file slack? Specifically I am thinking about > the use of the secure_delete utility which, includes "sfill" to > do secure overwriting of the unused diskspace on the harddisk.I don't see anything below related to "file slack", by which I assume you mean the disk space after the end of the file size. That space is already overwritten at initial write time with 0x00, but your program would have to be smart enough to figure the filesystem blocksize and then write up to the end of the last full block to overwrite this space. Even so, that is not critical, because presumably nothing important was stored there.> HOW THESE PROGRAMS WORK > > The deletion process goes like that : > > 1. The overwriting procedure, in the secure mode, does a 38 times > overwriting. After each pass, the diskcache is flushed. > > The secure overwrite mode works that way: > > 1x overwrite with 0xff > 5x random passes > 28x overwriting with special values to make the recovery from MFM > and RLL encoded harddisks hard/impossible - see Gutmann's paper > on that which is also included. > 5x random passesFinally, a secure delete program which _actually_ does secure deletion, instead of this "the US DOD says overwriting with 0x00, 0xFF, and random once is secure" (not that I am particularly keen on using this sort of thing myself, but if you are doing something, do it right).> 3. renaming of the file so that an attacker can't draw any > conclusion from the filename on the contents of the deleted file.On ext3 with htree support, renaming the file will still leave the old filename in the directory, and just create a new entry with the new name. In ext2 it may well be the same, even if the filenames are the same length (have never looked at the code with this in mind).> 4. finally deleting the file (unlink).Presumably only when the link count is 1 ;-). Actually, the better way to do it is probably to open the file, then unlink it and verify that the link count == 0 before destroying it, so as to avoid races. Cheers, Andreas -- Andreas Dilger www-mddsp.enel.ucalgary.ca/People/adilger sourceforge.net/projects/ext2resize