What is the best secure file deleting tool for ext3?
 

My distro comes with a desktop file shredder, it works, but is it good for ext3? I also have wipe installed. I need to know which is the best for my ext3 file system. Thanks.

ext3 - and all journal based filesystems - have issues with securely deleting single files from the hard disk.

From man page of the tool "shred".

Installed bcwipe.
 

Just install bcwipe-1.7-5. This program is supposed to work very well with ext3. After installing the program, I created a kde konqueror service menu file. Just copy and paste what is below with kwrite to a new text document . Then save the document under .kde/share/apps/konqueror/servicemenus


[Desktop Entry]
Version=1.7-5
ServiceTypes=all/all
Actions=Destroy

[Desktop Action Destroy]
Name=Securely Delete File/Folder
Icon=/opt/kde3/share/icons/hicolor/32x32/apps/clanbomber.png
Exec=bcwipe -rvf %U



Now when you right click on ANY file, you can choose "action" - securely delete file/folder. The chosen file/folder will be randomly overwritten 35x. Works great for me! I also placed a shortcut to my firefox cache folder on my desktop. From time to time I securely delete all the temporary internet files the same way. Just select all then select action, then securely delete. NOTICE> I chose an icon from my /opt/kde3/share/icons/hicolor folder. This icon is a bomb. You can use whatever image you like, just make sure the full path is placed next to Icon=. I use Suse 10.3 which comes with a desktop shredder, but supposedly it is not so secure for ext3. That is why I switched.

That still leaves open the question of backups. If you shred a file on disk, what happens later is you restore a backup? Is the shredded file restored from the backup?

Have no idea what you mean.
 

Once it is shredded, it is gone forever! You can't restore it. I just looked for a file I shredded with bcwipe using magicrescue and no traces were found. What about backups?

Oh, I know what your talking about.
 

I have a complete image file backup of my ( / and /home) partitions on another backup partition. If I use bcwipe now and use the commands (bcwipe -F /) , then do the same for /home, then every unused space/free block on the hard drive will be overwritten 35x. After this is done, then make your backups. Then in the future whenever you need to delete a file securely, you do it. Nothing can be restored that way.

Also, I would recommend that during the shredding process, you would remount the desired partition as ext2. Since all ext3 partitions are backwards-compatible with ext2, this is possible. All that will happen is that the journal will be unused.

bcwipe works FINE with ext3 (if you're careful)
 

I'd like to challenge the traditional logic about secure file deletion while using ext3 journaling. Bcwipe of EXT3 should offer ALMOST no worries.

There are 3 structures you need to erase. (1) the data, (2) the inode blocks, and (3) the journal itself, usually in /.journal (or RAM) or the like.

PREAMBLE: I do any required secure wiping in single user mode.

(1) Bcwipe will do in situ overwrite of ext3 files just fine if your ext3 is set at level 2 journaling i.e. "metadata journaling". And that is the default. EXT3 metadata journaling was specifically designed to handle safe in-situ overwrites. So overwriting definitely happens. HOWEVER: If your hardware disk cache can contain the entire file (nothing to do with EXT3), then you will be overwriting only the hardware cache 35x with the Guttman wipe...not good! So just make sure you are wiping more files than can fit in any cache you might be using anywhere along the line. Or another fix to this problem, just use the -n1 keyword in bcwipe and wipe two files that are widely separated on disk. Each will be flushed to disk with each wipe pass, round-robin. You can hear it if you put your ear next to the drive. Just watching the disk access light MIGHT be good enough. Try it! (If you can't hear it, try wiping more/bigger files or give up and remount as EXT2)

(2) The inode blocks are metadata, and they are cached, often in RAM. The inode blocks will not get wiped (I don't think) more than once during a deletion. This will PROBABLY be ok since those blocks with their information will (at best) point to wiped disk space after deletion. I'm GUESSING that if you use -n1 again you should be ok. The reason is that the default ext3 metadata journaling can only hold ONE block of inodes at a time. So every time you go to a new inode block, things get flushed to the disk inode block, and that's a good thing.

Finally, (3) the disk commit journal itself. It lives in RAM most of the time. It too is fairly small (128k?). And its a circular list. So if you wipe a few hundred files, you'll wrap the circular list several times and overwrite any previous disk update. ALSO: every time you dismount/remount an ext3 volume, the entire journal is wiped with zeros ONCE. So unless you're a terrorist or have national secrets on your drive, people are unlikely to be able to recover anything but disk commit commands about space that has been wiped 35x.

In conclusion, if you want to delete a small number of files, use a command like this.
bcwipe -vrmg -n1 private-file.txt test-file.txt

And another way to wipe LOTS of private files is this...just
rm -R big-directory-of-files/ other-stuff.txt anythingUwant.dump
bcwipe -Fvrmg .
This bass-ackwards way should work fine. It first does a nearly useless recursive deletion of some private directory (could even be a single file). That file or directory of files are then returned to freespace. The bcwipe command then does a 35x pass wipe of the entire free space. This will take several hours. (You might prefer -md here instead of -mg) But it does the job. (There's one caveat here. DON'T add some big mpg movie you just copied from somewhere in between the rm and the bcwipe. The likelyhood there is that the movie will live on top of the files you just returned to freespace. And the freespace wipe will just overwrite innocent freespace. FAIL!)

For a really clean machine, don't forget to wipe slack space and swap space. I use the following for swap wipeing:
swapoff -a
bcwipe -Ibvmg /dev/mapper/VolGroup00-LogVol01
mkswap -c /dev/mapper/VolGroup00-LogVol01
swapon /dev/mapper/VolGroup00-LogVol01
You'll likely need to change the swap file name to whatever the swap file(s) is/are named on your system.

And for slack space wiping:
bcwipe -ISvrmz /
This does just one pass wiping of any slack space. Its better than nothing. BUT it will wrap-wipe the entire journal metadata cache many-many-many times!!! This command is probably better for directly wiping the journal than anything else, second only to ext2 remounting.

Put all the above commands in a script for full brain-dead operation.

DISCLAIMER: Lots of things can invalidate the advice above. If you're using very smart hardware cacheing, or multi-disk striping, or cross volume inode lists, or...or...or... then things won't work. Remounting things as EXT2 is always dumb and simple and has a very high likelihood of success in single user mode.

FINAL PLEA FOR HELP: If I've said anything wrong here, please correct me. I've done a fair amount of reading on this...including a forensics manual on disk recovery. (Google for that for more info.) And all the above seems to hold up on my machine. But I'm not perfect. Your help is appreciated.

QUESTION: What is/are the simplest command(s) to put in a script to remount my volumes in ext2?

One more VERY IMPORTANT caveat on EXT2 volumes. As most people know, its very much easier to lose an entire EXT2 inode structure, hence the entire volume. This was why EXT3 was invented...to be bulletproof in power outages, bcwip crashes, etc. etc. So, IMHO, I prefer to wipe EXT3 volumes with journalling running.