Originally Posted by brianmcgee
ext3 - and all journal based filesystems - have issues with securely deleting single files from the hard disk.
From man page of the tool "shred".
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:
bcwipe -Ibvmg /dev/mapper/VolGroup00-LogVol01
mkswap -c /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?