Secure Erase in UNIX	SLAC Computing UNIX at SLAC
	Updated: 16 Oct 2006

Contents

• Introduction
• Securely Erasing files
• Securely Erasing free space
• Securely Erasing an entire partition or disk

Disclaimer

This information is provided to the SLAC community to provide advice consistent with the mission of an open science lab. We are happy if others also find this page useful, but we cannot claim that techniques described here are applicable to any other enviroment. We cannot offer direct advice or support to others who are not faculty, staff, or users of SLAC.

Introduction

Normally when one removes a file, the blocks containing the file's data are freed up but not actually erased. Thus, all or part of the file's contents may remain on disk until its blocks have been allocated to new files and overwritten. With relatively simple tools, this information can often be recovered, which can be a serious problem if the data were supposed to remain private. Even after a file's blocks have been overwritten it may be possible to recover previous versions of the data using much more sophisticated (and expensive) tools.

There are several utilities available for UNIX systems that attempt to help with this problem, with various degrees of success. These tools provide one or more of the following functions:

• Erase (i.e., overwrite) the contents of a file, optionally removing it afterward.
• Erase the free space in a disk partition.
• Erase an entire partition or disk.

Most overwrite the blocks several times, using a variety of different bit patterns, to help protect against more sophisticated attacks. The usual technique for erasing a partition's free space is to allocate all the space to a new file then erase (and optionally remove) that file.

One major problem with all of these utilities is that most modern file systems use techniques called "journaling" or "logging" to help prevent file system corruption. Unfortunately, these techniques can also make it nearly impossible to ensure that all traces of a file's data get overwritten unless you are willing to completely wipe out all data on the disk. Operating system buffers, hardware caches, "bad block" lists and file system corruption (e.g., orphaned inodes which are neither in a file nor in the disk's free space) can also interfere with the proper operation of these utilities.

SCCS has done some testing of a few of these utilities and makes some suggestions below about what should work in a few common situations. However, the only method that we believe is certain to overwrite all the blocks that might contain private information is to overwrite the entire disk.

If you need to erase private data on SLAC-owned media, and your situation does not appear to match the ones described below, please contact SCCS for assistance by sending mail describing what you need to do to unix-admin@slac.stanford.edu.

Securely Erasing files

Linux

Red Hat Enterprise Linux (RHEL) includes a GNU utility called shred(1), which attempts to securely erase one or more regular files. The default file system in RHEL is named "ext3" which is, in fact, a journaling file system. However, by default it only journals a file's metadata, so file erasing tools should be effective. In particular, our limited testing suggests that shred should work on an ext3 file system in default mode.

The command to erase and remove a list of regular files would be:

Warning: shred follows symbolic links, which can have surprising and probably unintended results. Make sure you only list regular files on the command line.

Since shred does not have a recursive mode you will need to use a find(1) command to erase a directory full of files. Here's an example:

For more information about shred(1), please see the man page.

Solaris

The GNU shred utility is available on our Solaris systems as /opt/TWWfsw/bin/gshred. However our testing of gshred on the default, journaled file system in Solaris 10 indicates that it is not effective. On the other hand, we did find a utility that is effective at erasing the free space in such a file system (see the next section). Thus, you should be able to erase files in Solaris by first using the rm(1) ccommand to remove them and then running the free space erase utility described below.

Securely Erasing free space

We have installed an open source utility named scrub(1) in /usr/local for both Linux and Solaris. This utility was developed at LLNL and includes a mode for erasing the free space in a disk partition (it can also erase single regular files, but is somewhat less convenient to use than shred).

To erase free space, you must invoke scrub with the -X flag and specify a single new file within the partition on the command line. scrub creates the file, extends it to use all the free space, and then erases it. It does not automatically remove the file when it's done, so you have to remember to do this yourself. Here's an example:

Warnings:

• Depending on the amount of free space in the partition, this can be a lengthy operation. During this time, the file system will appear to be full, so other processes running on the system may hang or crash. It is best to run scrub when no one else is logged in and the system is inactive.
• Some file systems reserve a small percentage of the space in a partition for critical system needs, which can prevent scrub from erasing all the free blocks unless it is run as root (or via sudo(8)).
• Orphaned inodes will also be missed, so it's a good idea to run fsck(8) first.

For more information about scrub(1), see the man page and the Scrub home page at LLNL.

Securely Erasing an entire partition or disk

There are a number of utilities that can be used to completely erase a disk partition (including scrub(1), described above) or an entire disk. However, these are fairly dangerous programs. Moreover, they require unmounting the file system, which often means that they must be run from a bootable floppy or CD-ROM, or after physically installing the disk in a different computer.

If you need to erase an entire disk partition or disk on SLAC-owned media, please contact SCCS for assistance by sending mail to unix-admin@slac.stanford.edu.