Rm does not permanently delete files(medium.com) |
Rm does not permanently delete files(medium.com) |
Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs, and it's also not guaranteed to work on filesystems with copy-on-write semantics. If you're really concerned with this, you should be doing full-disk encryption.
That's only true for GNU-based userlands, not BSD-based ones.
> Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs
And if the system properly TRIMs it might not be necessary at all, though that greatly depends on the SSD.
Sure, but installing (a subset of) GNU coreutils is probably going to pull in a lot fewer dependencies than this JavaScript command line tool. Plus, you can use ports, no need to mess with a seperate package manager (npm) and the associated package verification foibles.
> And if the system properly TRIMs it might not be necessary at all, though that greatly depends on the SSD.
The "depends on the SSD" is a big one. Various recent forensic papers have shown that it can take a while until a TRIM'd sector is actually erased by the firmware.
I still think that if this kind of thing causes worries, full-disk encryption is really the only sensible solution.
RM(1) BSD General Commands Manual RM(1)
-P Overwrite regular files before deleting them. Files are
overwritten three times, first with the byte pattern 0xff,
then 0x00, and then 0xff again, before they are deleted."rm -P" with the same caveats as the GNU implementation.
I bet one could even shred a network socket.
dtal@reepicheep:~$ cat /dev/urandom | shred -
shred: -: invalid file typeThough, on second thought, this cloud service idea has some nice potential for evil :)
// quoting https://blog.codinghorror.com/the-principle-of-least-power/
>Files are overwritten three times, first with the byte pattern 0xff, then 0x00, and then 0xff again, before they are deleted.
Plus the -P flag is available on both GNU and BSD versions of rm. Somehow I fail to see the user-friendliness factor.
Edit: formatting
As an aside, it has never been demonstrated that multiple overwrites improve overwriting. In other words, it's never been demonstrated that data overwritten just once can be recovered. Until that happens I'll agree with other folks that multiple overwrites are a waste of time and electricity, and that FDE is a much more reasonable (not fool-proof, just reasonable) way to make data unavailable to unauthorized persons.
[pritam@PritePad ~]$ cat /etc/lsb-release
LSB_VERSION=1.4
DISTRIB_ID=Arch
DISTRIB_RELEASE=rolling
DISTRIB_DESCRIPTION="Arch Linux"
[pritam@PritePad ~]$ touch t
[pritam@PritePad ~]$ rm -P t
rm: invalid option -- 'P'
Try 'rm --help' for more information.
I also wonder what happens if the file is deleted before the zeros are flushed. Is there some implicit flush, triggered by metadata changes, which saves the day? No idea.
I pity the fool that tries to use this programmatically with a unset or null var, eg.
skrub /$imfuckedWhy? This is already provided by the shell.
Should have used /dev/random, and done it 7 times, then you could sell this to enterprise customers!
That's not quite true. TRIM simply tells the SSD that the corresponding block is not in use anymore, it doesn't tell the SSD what to do with it.
The controller will usually unmap the physical block and schedule it for erasure but usually not erase it immediately unless it doesn't have any free block to remap. And it will return zeroes if the block is read.
The data is recoverable at that point (until the block is actually erased) and can remain so for a fairly long time[0] if the attacker can either bypass the SSD controller or can physically access the raw flash memory.
[0] depending on storage pressure and the exact make and recycling strategy of the SSD
Is this still true with SSDs?
Yes they are. As a user, I see a file, type rm file, then it is gone. The file has been removed.
Yes those parts of that file are possibly recoverable back into the original file, even without much work, but the file has been removed.
/proc/
And with that in mind you can use a combination of lsof, grep, sed or any other tool to still read the file as it was.
Neither this tool nor GNU shred nor BSD `rm -P` can do anything about it.
Note also "Since writing the above, I have noticed a comment attributed to Gutmann conceding that overwritten sectors on "modern" (post 2003?) drives can not be read by the techniques outlined in the 1996 paper, but he does not withdraw the overwrought claims of the paper with respect to older drives."
(the comment is at http://seclists.org/bugtraq/2005/Jul/464)
As for SSD's, it's harder to say because of wear leveling and bad sector replacement. They internally have their own translation layers, and so the overwritten data may not end up where the original data was (this is itself a complicated topic. http://codecapsule.com/2014/02/12/coding-for-ssds-part-3-pag... is a reasonble intro)
However, one neat thing about them is that there are plenty of SSD's that do hardware encryption by default. When they get init'd, they set the key. You can reset the key, and then, pretty much, assuming the SSD's have not been backdoored by our security agencies, it doesn't matter what you do ;)
This assumes you just want to destroy all the data though, not just some of it.
That wasn't true. But, since we can't prove it's not true precaution says you should over-write drives a few times with pseudo random data.
SSDs are a bit more worrying because end users don't have full control.
But with physical drives or SSDs if the data is that important you should be looking at physical destruction, rather than just over writing.
No objection here. Though the original note is right, you just pointed to the wrong tool:
> I still think that if this kind of thing causes worries, full-disk encryption is really the only sensible solution.
And full agreement there.
You need to point stdout to an actual file, like this:
shred > /my/secret/file.txt