Secure delete with rm on OS X | Hacker News Reader

Secure delete with rm on OS X

paksoy.net

24 pointsmustpax26 comments

There is no guarantee this goes on the same sectors on the disk. I think that would only be guaranteed by a "secure delete call" to the drive's firmware.

The only way I know to securely erase the empty space on the drive is a call like "cat /dev/urandom > file; rm file". This will error once the drive is full, then be deleted.

Disk Utility can overwrite empty space on a device with zeros. It also has the dubious 7 and 35 pass overwrite options.

Why dubious?

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

"In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, 'A good scrubbing with random data will do about as well as can be expected'. This was true in 1996, and is still true now."

Interesting. But that would only be true for journaling file systems right? Or are there consumer hard disk drives that transparently journal writes a la ssd's?

Newer generations of SSD's have a command called "TRIM". It is meant as a way to speed up SSD drives by alerting the drive to blocks that are no longer in use by the file system and can be pre erased so to speak which makes future writes to that location faster. Windows 7 and newer versions of the Linux kernel support it.

That doesn't necessarily mean it will be erased, it just gets put back in the list of unallocated blocks.

No. Flash memory is sort-of write-once in the sense that a page starts with all bits in one state. From there, you can flip individual bits to the other state, but to flip them back, you have to flip back all of them. So, to update a single bit, you may have to read a block, erase it, update the in-memory block, then write the in-memory block.

The trim command will do the 'erase block' part of this procedure before the block is actually needed for data. That speeds up a future write to that block.

It's not just journaling that is a problem. Some filesystems and/or operating systems will move files or parts of files to improve performance. For example OS X does some automatic defragmentation of files. Some systems move files that are frequently accessed together to be near each other on the disk.

When the system does such an automatic move of a file or part of a file, does it clear out the source block on the disk, or just mark it free? If the latter, then a secure erase that just overwrites the current blocks of the file will leave those other blocks untouched in the free space.

If you have a file that you must truly be able to get rid of without destroying your whole hard disk, that file should be kept encrypted on the disk, and the plaintext version should never be stored on disk. Getting rid of the file is then a simple matter of forgetting the encryption key.

"cat /dev/urandom > file" may fail before the disk is full. I have seen a system do that because it wants to have room on the disk for e.g. log files or in-file-system swap.

Also, this will not work with disk quota, and you will have to make sure that you write to the same disk as where the original files lived (think mount points)

Full-disk encryption will not work in all countries, as law enforcement could imprison you if you do not give them the keys (recently happened in the UK). It also would not enable you to point at your drive and say "take a look. That file isn't there"

I think the only way to do this would be with support from the file system. It would have to support two things: overwriting file data (including that in on-disk snapshots), and removing evidence that a file or directory existed with a given name.

Edit: I just realize that the disk must support this, too. It could have written your data, verified the write, seen it to be unreliable, and rewritten it somewhere else on the disk. I doubt disks would keep track of links to these unreliable copies. So, in short, I doubt there is any 100% reliable way to erase data from a disk. Copying what you want to a different drive and destroying the drive probably is your best option, but that may be a bit time-consuming and expensive if you want to safely erase a single file frequently.

Know what's easier?

Right click the trash bin, and hold Command. You'll see "Secure Empty Trash". You can also do the rm -P from the trash bin, which I wish they allowed you to do under normal circumstances. (dterm makes this easy.)

Thanks. I knew you could hold "alt" when left-clicking on the volume control to select inputs, but I didn't know about that one. Very useful, much better than going in the Finder's preferences...

For what it's worth, holding down Option/Alt will empty the Trash without confirmation.

Also, from the menu you can select:

    Finder > Secure Empty Trash

You can even give it a keyboard shortcut, if you like. Or, as you mentioned, there's an option to always securely empty the Trash in the Finder Preferences.

Holding alt / control / command to modify a right-click menu is one of the most useful and worst UI decisions in OSX (IMO). Easily 95% of people I've encountered on Macs don't even know it exists, and when they do, they don't know how many places it exists.

I really wish there were some kind of hinting to help people discover this.

This isn't an OS X specific feature, it's a feature from the FreeBSD userland that Apple borrowed into OS X.

Secure delete is not reliable with modern filesystems. Just use full-disk encryption -- it's free.

Good thing HFS+ is not a modern filesystem. Also, I'm not sure what FDE has to do with recovering unlinked files.

With secure delete, someone with your disk can't read deleted files. With an encrypted filesystem, they can't read the non-deleted files, either.

SSDs with FDE...

http://www.computerworld.com/s/article/9131684/Full_disk_enc...

I haven't been able to find a free bootable full-disk encryption solution for the Mac. TrueCrypt is free but doesn't support bootable whole-disk encryption for the Mac. The only solution I found was PGP Whole Disk Encryption which isn't free.

I've generally seen full disk encryption on a OS volume as a moot point. Why is there a need to have full disk encryption on a bootable volume, when the only thing you should be protecting from prying eyes is your content? Full disk encryption makes sense in a data volume, not in a bootable volume where just having a ~ directory and it's children encrypted covers mostly everyone's need for security.

So you know for a fact that every application you ever use doesn't write data outside of ~?

You may feel comfortable about that, but I don't. /tmp, for example, can contain plenty of sensitive data.

It doesn't if I don't give it permission to, but if you're concerned about it encrypt /tmp also or symlink it to ~/tmp (provided you're the only user).

Nevertheless, I do understand that you have different requirements, but in the case someone really values the option of having his entire boot volume encrypted, the one time only price tag of PGP is a moot point and shouldn't be a deterrent. In fact, I'm now tempted to buy PGP's whole disk encryption thank you very much. In any case, I think it's generally overkill, but if you really needed, who am I to stand in your way! :)

http://www.pgp.com/products/wholediskencryption/index.html

I use Linux, so full-disk encryption was just a checkbox (erm, line that you select?) in the installer.

Like I said, it's free, so why not?

Oh silly me, I kind of assumed you where using OSX because someone made the comment that there's no option for full disk encryption. My bad. If I had an option to encrypt my whole disk that easily in OSX I'd take in a heart beat, not necessarily because I think it's better but because it's a solution and it's simple... because I can so to speak.

Or use srm.

Reply on news.ycombinator.com