[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ext3 and secure deletion of files and file slack

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.

> 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 passes 

Finally, 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]