LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Secure Delete for linux? (http://www.linuxquestions.org/questions/linux-security-4/secure-delete-for-linux-193765/)

meindlj 06-15-2004 11:00 AM

Secure Delete for linux?
 
Anyone know a good secure erase app for linux?

Crunch 06-15-2004 11:04 AM

Shred
 
I've heard of shred... I've never used it, but it came pre-compiled on my Slackware box (after installing everything). I'm sure you could try that out.

Code:

$man shred
Hopefully that will explain what you're looking for.

overlord73 06-16-2004 03:01 AM

another good programm is secure delete (by van hauser, www.thc.org).
compared to others it uses bigger blocksizes.
secure_delete is fast with big files but slower with many small
ones.

links:
wipe.sourceforge.net
berkewipe.sourceforge.net
mysite.verizon.net/vze1ypud/linux/software/fwipe.html

iainr 06-16-2004 03:49 AM

KDE 3.2 comes with a Shredder icon : just drag files onto it to securely delete them.

Sebboh 06-17-2004 01:41 AM

Shred, afaik, does not support journaled filesystems..

dalek 06-17-2004 04:09 AM

Quote:

Originally posted by Sebboh
Shred, afaik, does not support journaled filesystems..
I use Shred but you are right. It likely can be retrieved. Journalized file systems are more redundant I guess so it is actually harder to get rid of something. Maybe NSA came up with that to catch people. :scratch: Big government, bad government.

Later

:D :D :D :D

bun_zee 06-22-2004 11:26 AM

Hi,

Shred is a secure delete utility that comes with RH Linux. The shred man page say that it does not work well with filesystem that use journaling.

I read a few articles in journaling. One of the article said "When metadata on the disk is updated, the updates are recorded in a separate area of the disk reserved for use as a journal. Filesystem transactions which complete have a commit record added to the journal, and only after the commit is safely on disk may the filesystem write the metadata back to its original location. Transactions are atomic because we can always either undo a transaction (throw away the new data in the journal) or redo it (copy the journal copy back to the original copy) after a crash, ac-cording to whether or not the journal contains a commit record for the transaction."

From this article, I dont quite understand how journaling is an issue in shred.

Journaling is meant for recovery when the system loss power abruptly. When this is the case, the file won't be overwritten properly which is true with or without journaling. It is not like journalling is going to "write data in a different data blocks" or something.

Many articles claimed that journaling is an issue in shred without any real in depth explanation.

QUESTION:
Could any one please explain why journaling is an issue in secure delete? (it's not like with journaling the system end up writing data to different blocks or anything).
A sample scenario would be nice!
Also, if journaling is indeed pose complication, then would this help at all:
mount -t ext3 -o data=writeback /dev/sda2 /jdisk
(Basically this mount the with the writeback mode for ext3).

Any response is appreciated.

Thank you,

BunZ

v00d00101 06-22-2004 08:05 PM

Theres a app called scrub available somewhere on the lawrence livermore website. But the secure tools thc offers are way more advanced. 38 pass wipes using urandom, not sure if you get any better than that. For safetys sake if i need to wipe something i use scrub first, then sswap/sfill/srm.

So if your really paranoid, use 2 diff apps, or consider the use of a ramdisk for working in (net cache, temp viewing area for files). Even on ramdisk i multiwipe it before rebooting. Maybe beyond that encrypt your swap partition.

Beyond that make sure some of your partitions are ext2, mainly things like /tmp, /var, possibly /home as well. Anything you want to effectively wipe.

bun_zee 06-23-2004 10:31 AM

v00d00101

I think scrub and any other secure delete software still run into the journaling issue.

My question remains, how exactly does journaling cause a problem in secure delete? Is it because in ext3, the journaling end up writing modified data to a new data block then re-reference the inode and left the old data block untouched? Or because journaling might keep a copy of the old data block in the journal (must be HDD not RAM) and no one knows when exactly that old data is deleted?

Your reply raise a question.
Peter Gutmann said that data in RAM "set" an image and it can be recovered after powerup. I am using RedHat. How do I force the system to put all one's in any unused RAM (for instance, when a c code free or delete dynamic memory or when a statically allocated memory is no longer needed).

thank you,

BunZ


All times are GMT -5. The time now is 09:42 AM.