Re: Secured RM ? (source)

["Josh M. Osborne" <stripes@va.pubnix.com>]

In message <Pine.LNX.3.91.800121064335.1068A-100000@HellSpawn.gate.net>, root w
rites:
>
>OK ... here we go.. Based on discussion on this list this is what I 
>hacked out to (hopefully) more securely remove a file under unix. 
>I'd really apreciate any input, but my main interest is in the security of 
>the protocol in general and not the sloppy and embarassing C 
>programming.. :) 

Well it seems to assume that it only needs to write 1024 bytes past the
end of the file.  You either don't need to write any bytes at all past 
the end, or you need to write one "block" past the end (normally 8K,
but it varies), you can use fsstat(2) on many systems to find the block
size for a filesystem.

Secondly you need to flush the data out to the file (use fflush(3), and
fsync(2) if available, otheruse call sync(2) *twice*).  If you don't some
small set of Unix systems may notice that you are writing to a file that
no longer exists, and not do the writes at all.

Thirdly you should make several passes over the file, writing diffrent
patterns on each pass (and remember the flush & sync after each pass -
while it is uncommon for Unix systems to supres writes to unlinked files
it is extreamly common for them to detect multiple writes to the same part
of a file, and only do the last one).

Forth - and this is the kicker - there is no gaurentee that the filesystem
itself won't keep a copy of the old data for some reason.  Three examples:

 * a compressed filesystem may write the new data elsewhere because it
 compresses diffrently from the old data - you should be able to defeat
 this by filling the disk several times with random paterns

 * the log structured filesystem (LFS) *will* write the new data elsewhere,
 and the space the old data is on will not be overwritten untill the
 cleaner comes and examines the part of the disk it is on - again filling the
 disk several times with random patterns should cause an overwrite

 * NetApp's NFS appliance ("the toaster") can (and normally is) configured
 to take "snapshots" of the filesystem at various times, this makes the
 blocks the file is currently on read-only, and any ovewrites will merely
 allocate new space.  The old copy of the file will be readable for some
 peroid of time (frequently up to a week) under a diffrent name - here you
 will be unable to fill the disk (unless you are the NetApp admin - then
 you can delete the appropriate snapshots and fill the disk...)


While we are at it you probbably want to use stat(2) to find the length
of the file, and you can get far more I/O if you allocate a sizeable
chunk of memory (say 1K, or 8K) and use writev(2) to shove multiple copies
of it out per syscall...    and some indenting on the code would make
it more readable (and simpler for you to write as well).

>While we're here..  I havn't been able to find anyone on the planet who's 
>seen or heard of a linux un-remove, which makes testing my code very 
>tricky.  If anyone can point me at it I'd apreciate it. Hell, if someone 
>can definitively say they've /seen/ such a thing it'd be nice. So far 
>i've found one person who insists that his system admins sisters 
>boyfriends cousin from Saint Petersburg has been using un-rm for unix for 
>years. *sigh* 

I don't know of a real un-rm.  In "the old days" there was a fsdb (filesystem
debugger) that could be used to alter the filesystem at a low level.  If
you knew enough you could "un-rm" a file.  It had to be a very valuable
file to be worth it!).  At some sites they alias rm to do something like
"mv $1 .$1.deleted", making an un-rm is left as an exercize for the
intrested reader.