How to safely shred unlinked files on a Unix-based file system?

Question

Scenario:

After working with a confidential file (e.g. PDF a bank statement), you typed:
```
rm my-confidential-file
```
(or the famous Shift-Delete action in a GUI-based file browser such as nautilus)
You realize "Ooops, I should have used the shred utility first".
You run your file recovery tool and you are "lucky enough" to recover the block at which your secret file resides as well as its size. Moreover, your deleted file seems intact (i.e. non-overwritten by other data).

Now, is there a safe and secure way of deleting such an unlinked file from your file system, i.e.:

you don't mess up other files, preferably not even the journal
recovery tool can no longer find the file (i.e. it's overwritten by garbage data)

?

I am specifically interested in the ext4 file system, but a more general approach is even more welcome.

Note: I guess a robust solution would require an assumption of how big the deleted file is, so you can assume it's up to a few MBs.

What he said. Zero, or to be even more safe, random fill it. It's extremely time consuming, but it will work, and it's safe. You're not erasing that file, you're erasing all the files that have ever been deleted. Look here: superuser.com/questions/19326/… — unkilbeeg, Oct 3 '14 at 20:24
@Zoredache: Well, this works in theory. How can you do this operation in sync with the filesystem? You would need to ensure that throughout this lengthy operation you are doing absolutely no writes to files or journal / metadata, right? Could you mount the partition as read-only and somehow perform this zero/random fill on a low level? Doesn't seem that much practical... — leden, Oct 3 '14 at 21:48
Honestly I have never worried about it that much. If you are worried enough about security that you think you would need to regularly shred files, then you probably should just encrypt the data in the first place. — Zoredache, Oct 3 '14 at 22:50

yhammad · Accepted Answer · 2014-10-03 20:32:54Z

-1

check the scrub command (you may need to install the scrub package): http://linux.die.net/man/1/scrub example: scrub -r /location/to/file.txt

answered Oct 3 '14 at 20:32

yhammad

1

Did you read the fact that the file is unlinked. By that I also meant there are no more I-nodes / pointers to it. So from a file system perspective the path (location/to/file.txt) does not exist. – leden Oct 3 '14 at 21:51
@leden: I have never heard of this "scrub" before, so I'm not vouching for it, but, according to the linked man page, the -X option (a.k.a. --freespace) will create files until the filesystem is full and then scrub them. This has the effect of scrubbing all the free space on your filesystem, as the other folks have suggested, in a way that doesn't require writing directly to the filesystem (which can be tricky to do safely). – G-Man Says 'Reinstate Monica' Oct 3 '14 at 22:47

add a comment |

1 Answer 1