Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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. Big government, bad government.
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.
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).
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.
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).