[ale] erasing ext3 filesystems securely
Michael B. Trausch
fd0man at gmail.com
Tue Jun 7 04:57:27 EDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
John Wells wrote:
>
> You don't actually mount the partition...you just tell shred the partition
> (/dev/hda1) or the entire drive (/dev/hda).
>
Then you are fine. Read this quote from the info manual carefully, it
follows the section stating what filesystems this does and does not work
on. Please note that it's talking about shredding regular files *on a
mounted filesystem* in the section previous to this:
" If you are not sure how your filesystem operates, then you should
assume that it does not overwrite data in place, which means that shred
cannot reliably operate on regular files in your filesystem.
" Generally speaking, it is more reliable to shred a device than a
file, since this bypasses the problem of filesystem design mentioned
above. However, even shredding devices is not always completely
reliable. For example, most disks map out bad sectors invisibly to the
application; if the bad sectors contain sensitive data, `shred' won't
be able to destroy it."
Now, since you're shredding a device (presumably an entire hard disk
drive device), you have no problems. Shred will work just fine for it;
it makes no difference what the file system is.
A little bit of background to help make understanding easier: Since
UNIX treats everything as a file, there are more things that you can do
with different devices. For one, you can directly access them, if you
have the sufficient privilege levels. In this case, you can directly
access the entire hard disk, and overwrite it by default 25 times (the
default number of passes specified with shred's documentation, if you do
not specify a number of passes).
I would personally recommend that you ensure that at least 4 passes have
been done if you're not terribly worried, 8 - 10 if you're worried, and
the full 25 (or more) if you're truly paranoid. Also, you may be
interested in the -v option to shred, which will give you more
information (showing what passes it is on and everything else. Here's
an example of what it's output is when I shred a file on my FS (which I
know doesn't work on regular files in my situation; I use ext3):
mtrausch at ibm-mtrausch:~$ shred -v weather.png
shred: weather.png: pass 1/25 (random)...
shred: weather.png: pass 2/25 (ffffff)...
shred: weather.png: pass 3/25 (eeeeee)...
shred: weather.png: pass 4/25 (999999)...
shred: weather.png: pass 5/25 (111111)...
shred: weather.png: pass 6/25 (b6db6d)...
shred: weather.png: pass 7/25 (249249)...
shred: weather.png: pass 8/25 (492492)...
shred: weather.png: pass 9/25 (6db6db)...
shred: weather.png: pass 10/25 (666666)...
shred: weather.png: pass 11/25 (777777)...
shred: weather.png: pass 12/25 (cccccc)...
shred: weather.png: pass 13/25 (random)...
shred: weather.png: pass 14/25 (dddddd)...
shred: weather.png: pass 15/25 (aaaaaa)...
shred: weather.png: pass 16/25 (924924)...
shred: weather.png: pass 17/25 (db6db6)...
shred: weather.png: pass 18/25 (555555)...
shred: weather.png: pass 19/25 (444444)...
shred: weather.png: pass 20/25 (888888)...
shred: weather.png: pass 21/25 (333333)...
shred: weather.png: pass 22/25 (000000)...
shred: weather.png: pass 23/25 (222222)...
shred: weather.png: pass 24/25 (bbbbbb)...
shred: weather.png: pass 25/25 (random)...
mtrausch at ibm-mtrausch:~$
The patterns used therein are all discussed in the paper cited in the
shred documentation. If you go out and do some more research on data
recovery and erasure, you may be suprised at what you find.
- Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCpV6VPXInbkqM7nwRAwN5AKCVSSd4PhsCvvqDmr1GX38NBG/igQCcCW5s
Eg0VPkKk3poGaB3bpNc8P+A=
=NN7f
-----END PGP SIGNATURE-----
More information about the Ale
mailing list