I want to make one thing clear. You need to use multiple overwrites strategy ONLY when you’re dealing with a file, or a bunch of files, size of which doesn’t equal capacity of the storage device. Multiple overwrites strategy is a legacy approach that made much sense back in the day, and to some extent today too, but largely it took on a size of an urban legend.
It’s true, though, that if you want to completely destroy a single file you should rather use this multiple overwrites strategy to stay on the safe side. There are a couple of reasons for this is, one would be that, theoretically, underlying storage device logical addressing system (LBA) could remap sectors with data (think bad blocks recovered by hard drive semi-intelligent firmware known as error correction mechanism) to some other place and thus remains of the files, or sometimes even copies could be found on the drive despite the fact that the file(s) was deleted.
Keep in mind that in most cases recovering these remnants is not a trivial task, so if your adversary is your girlfriend or geek friend with mild degree in Geekinness, you may consider yourself reasonably safe when deleting files with rm. If you’re up against cyber police or underground hackers perhaps it won’t hurt to use the method described in this post down below.
Also, please note, that on SSD drives multiple overwrites strategy should really be embraced due to the technical design of this type of storage device (read more about it in stackoverflow thread).
Bottom line is, if you need to destroy all data on a drive you don’t have to overwrite it multiple times, just once will be enough but ONLY IF you’re sure you’re overwriting every single sector on the drive (think dd if=/dev/random of=/dev/sda). It won’t hurt but you really shouldn’t.
Here’s a nice starting point if you’re interested in deeper details of the discussion:
Here’s the deal, in most cases, on most popular distributions, on most standard Linux setups removing a file via GUI file manager or in your terminal window, including by rm command, isn’t secure at all. A file removed in such a fashion can be relatively easily recovered.
If you’re donating your old computer to a younger sister and don’t want to blush when she recovers your Inkscape drawings of Pokemon characters and posts them up on Facebook, you need to know how to delete those files for good. Securely, so that not even Interpol can recover them with expensive hardware.
If you doubt how much this is serious, google “securely delete file linux” up and look at the numerous warnings written by many people all across the web — rm is not enough!
Even more, the filesystem type and its options may prevent you from successfully deleting a file for good even with shred. So, how do we do it?
shred is the command line utility that does the job. There are a few interesting command line options that are often omitted elsewhere on the various pages on the Internet.
Here’s what I’ve come to believe is a good way to use shred:
% shred -f -n 30 -z -u testfile
forces the deletion by setting write permissions on the given file
overwrites the file n times, default value is 3
makes a final overwrite with zeroes to hide the act of shredding
finally deletes a given file for good
Now, if you want to play around with it add -v to see shred talk back to you about what it does:
% shred -f -n 30 -z -u -v testfile shred: testfile: pass 1/31 (random)... shred: testfile: pass 2/31 (111111)... shred: testfile: pass 3/31 (a49249)... shred: testfile: pass 4/31 (124924)... shred: testfile: pass 5/31 (249249)... shred: testfile: pass 6/31 (ffffff)... shred: testfile: pass 7/31 (bbbbbb)... shred: testfile: pass 8/31 (cccccc)... shred: testfile: pass 9/31 (492492)... shred: testfile: pass 10/31 (888888)... shred: testfile: pass 11/31 (random)... shred: testfile: pass 12/31 (222222)... shred: testfile: pass 13/31 (b6db6d)... shred: testfile: pass 14/31 (777777)... shred: testfile: pass 15/31 (555555)... shred: testfile: pass 16/31 (db6db6)... shred: testfile: pass 17/31 (aaaaaa)... shred: testfile: pass 18/31 (000000)... shred: testfile: pass 19/31 (666666)... shred: testfile: pass 20/31 (6db6db)... shred: testfile: pass 21/31 (random)... shred: testfile: pass 22/31 (800000)... shred: testfile: pass 23/31 (444444)... shred: testfile: pass 24/31 (dddddd)... shred: testfile: pass 25/31 (5b6db6)... shred: testfile: pass 26/31 (eeeeee)... shred: testfile: pass 27/31 (333333)... shred: testfile: pass 28/31 (924924)... shred: testfile: pass 29/31 (999999)... shred: testfile: pass 30/31 (random)... shred: testfile: pass 31/31 (000000)... shred: testfile: removing shred: testfile: renamed to 00000000 shred: 00000000: renamed to 0000000 shred: 0000000: renamed to 000000 shred: 000000: renamed to 00000 shred: 00000: renamed to 0000 shred: 0000: renamed to 000 shred: 000: renamed to 00 shred: 00: renamed to 0 shred: testfile: removed
Note: keep in mind that the larger the given file’s size the longer the overwrites will take, and the higher -n value the longer it will take to actually delete the file. If national security agents or your enemies are knocking on the door time may be of essence (to put things in perspective it took 27min to shred a single file of 590Mb size on a Core Duo 1.73Ghz powered machine). So, choose values for the options wisely.
If you thought that is suffice to wield security magic, think again. Most modern Linux setups use either ext4, ext3 or ext2. With ext4 and ext3 make sure you’re not running it with data=journal option. To see how your filesystem is currently configured in regards to this aspect try to grep dmesg like this:
% dmesg |grep EXT3 EXT3-fs (sda3): recovery required on readonly filesystem EXT3-fs (sda3): write access will be enabled during recovery EXT3-fs: barriers not enabled EXT3-fs (sda3): orphan cleanup on readonly fs EXT3-fs (sda3): 42 orphan inodes deleted EXT3-fs (sda3): recovery complete EXT3-fs (sda3): mounted filesystem with ordered data mode EXT3-fs (sda3): using internal journal
Now, see man mount and search for “writeback” keyword to learn a little more about various ext3/ext4 data modes.
Also, see the end of
% man shred
It explains that ext3 and ext2 are usually conducive to a safe deletion with shred, however data=journal mode on ext3 and ext4 introduces a second write of the actual data (the contents of your file too!) to the journal alongside with the meta-data, which ultimately allows to potentially recover even the shred‘ed file. This is so because shred assumes there’s no write to the journal happening on your filesystem, so it doesn’t bother to wipe that data off at all.
If you’re curious these are the characteristics of filesystem types that shred dislikes:
* log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.) * file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems * file systems that make snapshots, such as Network Appliance's NFS server * file systems that cache in temporary locations, such as NFS version 3 clients* compressed file systems
So, if you figured your filesystem has a journal and you don’t want one henceforth you could safely remove the journals on ext4 and ext3 block devices by running the following command:
% tune2fs -O ^has_journal /dev/sda3
Check to see if everything has worked as expected, “has_journal” must not be seen now in part of “Filesystem features:” field output of:
% tune2fs -l /dev/sda3 | grep features
Now, to explicitly and permanently set the journal mode use /etc/fstab to specify data=[ordered|writeback] option for a given partition with ext4 or ext3 filesystem:
/dev/sda3 / ext3 rw,noatime,barrier=0,data=ordered
Remount the device, or reboot the computer, then grep dmesg for EXT3 again. If everything looks fine you’re set to safely delete your file(s).
A final touch, create an alias for shred to save keystrokes. Add this to either your local ~/.bashrc or /etc/bash.bashrc:
alias shred='shred -f -n 30 -z -u'
Save the file, and either “reload” it:
% source ~/.bashrc
or logout and login to your console session again. If running X you may have to restart the session too. Now you can simply run:
% shred /home/user/images/pokemons.svg
and rest assured that it’s highly improbable that your sister will be able to see that file, even if she befriends people with powerful gadgets.