Re: secure erasure of files?

[Andreas Ferber <aferber@techfak.uni-bielefeld.de>]

On Tue, Feb 12, 2002 at 02:41:19PM +0100, Davidovac Zoran wrote:

(srm maintainer cc'ed)

> there is srm (secure rm) somewhere on the net
> here srm.sourceforge.net
> srm - secure file deletion for posix systems

Broken as designed, it simply /can't/ work reliably (not to mention
the other comments that you can even recover data overwritten multiple
times).

Nothing stops the kernel (or the filesystem for that matter) from
shuffling around disk blocks while you are overwriting the file. You
may end up overwriting other disk blocks than the data you want to
hide lives in if the filesystem decides that your file may fit better
into other blocks, which leaves the original data completely intact.

I don't know if any filesystem currently relocates blocks if you
overwrite a file, but it's certainly possible and allowed (everything
else except the filesystem itself simply must not care where the data
actually ends up on the disk).

In addition to the design breakage, the current implementation of srm
is simply crap. Here is the part actually overwriting the file:

---------- snip ----------
  int i = 0;

  lseek(file, 0, SEEK_SET);
  while (i < file_size - buffsize)
    i += write(file, buffer, buffsize);
  write(file, buffer, file_size - i);
---------- snip ----------

Guess what happens if you try to srm a file longer than INT_MAX bytes?
And what if write() returns an error? Ghee, overwriting the file
backwards from the beginning, until infinity? Impressive...

Ah, and look at rename_unlink(): it tries to "overwrite" the
original filename with random characters. It does this by generating a
new 14 character random filename and rename()ing the file to that name
(keeping it in the same directory). Well, for example on plain stupid
(no pun ;-) ext2fs there are /many/ situations where the new directory
entry ends up in a totally different place than the old one (e.g. a
filename shorter than 14 characters if there is no free space around
the old direntry).

Well, enough for now...

Andreas
-- 
       Andreas Ferber - dev/consulting GmbH - Bielefeld, FRG
     ---------------------------------------------------------
         +49 521 1365800 - af@devcon.net - www.devcon.net