Ask Your Question
1

How to securely delete files on Fedora 27 (ext4)?

asked 2017-12-23 21:04:39 -0600

paranoid_security gravatar image

I have some confidential files that I did encrypt, but there are still the original, unencrypted files on my HDD. What I want to do is overwriting these 25+ times with random data junk, making them absolutely and totally unrecoverable. The shred man-page says shred is not guaranteed to work on journal file systems, like ext. Is this statement correct? So I am looking for alternatives to shred for Fedora 27 (64-bit or architecture-independent).

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
2

answered 2017-12-24 02:56:26 -0600

Rabin gravatar image

updated 2017-12-24 03:01:02 -0600

I think you OK, with shred and/or just dd /dev/null on to this files.

Are you worry some one will take the plates out of drive to a forensic lab to try and restore your data, where do you draw the line ?

I guess you will have this problem on SSD's where the controller will write the new data on a new block (wear levelling), and the old data will still be on the memory chips (but not mapped)

Another option you have is to create a tmp file to fill all free space on the drive, and then use dd or shred, so there won't be other places for the drive to relocate the content.

  1. https://lwn.net/Articles/462437/
  2. https://stackoverflow.com/questions/3...
edit flag offensive delete link more
1

answered 2018-10-19 12:10:59 -0600

wallyk gravatar image

The issue with an ext3/4 filesystem from a shred perspective is that the journal has a copy of the old data (for awhile). To use shred effectively, alter the /etc/fstab entry for your system from (showing home for an example):

/dev/mapper/fedora-home /home                   ext4    defaults                     1 2

to

/dev/mapper/fedora-home /home                   ext4    defaults,data=ordered        1 2

where the only change made is to the fourth item.

Reboot and shred as required. Then, if there is no cause to shred for awhile, change the filesystem table back and reboot.

The source for my suggestion is from man shred near the bottom:

In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness) only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default) and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the data=something option to the mount options for a particular file system in the /etc/fstab file, as documented in the mount man page (man mount).

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2017-12-23 21:04:39 -0600

Seen: 443 times

Last updated: Oct 19