5

I am new to real system administration but have been running Linux servers at my home for years. I haven't cared too much about security because the few servers I maintained at work have always been on the intranet and all of the information stored on the servers was accessible by all employees anyway, so this is my first foray into truly securing a system.

I know quite a bit (or can find it on the Internet) about locking down a system for production use, but I can't seem to find a whole lot of documentation about securely deleting a file on a Linux machine that is using a journaled file system.

From what I have read, due to the journalling process, even using tools such as srm or shred leave you vulnerable to data recovery.

So, what is the best method you have found to securely delete files on Linux? Does using LVM make any differences?

Thanks very much!

Edit 1: To add a bit of clarification, the server I want to secure will contain other users' data, so whilst I can delete (or shred) the files, I can't do so with the entire partition as it will contain data still important to other users. I'm not worried about securing the drive when it's time is up; I can stick it in front of a huge magnent and toss it in a volcano if I need to, I'm worried about securing it from remote access. The physical site is fairly secure, although encrypting the drive may still be a good idea.

Edit 2: Edited title to be more descriptive of exactly the problem I am facing.

5 Answers 5

5
+100

If you're using ext3, it's quite possible that only the metadata is journaled, this is the default behaviour of ext3. If you check the manual page for shred:

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).

And then, you check your /proc/mounts to see what the mount-flags for your mounted filesystems are.

An example:

$ grep -i data /proc/mounts
/dev/root / ext3 rw,data=ordered 0 0
/dev/sda4 /stash ext3 rw,data=ordered 0 0

On both my /stash and / filesystems, shred should do an adequate job of securely deleting data.

1
  • +1 and solved! Thanks very much, I wasn't expecting an answer that was correct and let me do less work :-) Oct 9, 2009 at 14:49
2

You can say this: shred is useful for partitions, not individual files. While turning off journaling temporarily will prevent some issues, it's still possible that bits of your file exist elsewhere that they can be recovered from other journaled transactions made on the file previously. So if you want to be safe, shred the file. If you're paranoid, shred the partition.

That perhaps isn't the answer you wanted, but journaling and RAID are somewhat out of shred's ability to correct for. As far as I know, LVM won't matter though.

1

If you are going to be storing data that must be secured against someone if they get physical access to the drives. Then you may be better off simply encrypting the filesystem so that data stored on the filesystem is secure by default and you don't have to worry about securely deleting things.

1
  • 1
    Unless the data is really sensitive. Then I'd still shred the partition and/or physically destroy the drive prior to disposal. Never fully trust encryption alone. Oct 1, 2009 at 19:44
1

I think fundamentally if you are trying to secure against someone going through /dev/sd? with dd or hexdump and recovering deleted files there isn't much you can guarantee on any modern filesystem. The best you could do would be to fill up the disk periodically with a dummy file so that all unused space is overwritten and of course you can use any one of the available linux partition encryption schemes. Encryption will mainly protect against offline attacks though, someone stealing the drive and going through it, the data is obviously readable while the system is running.

0
dd if=/dev/urandom of=$FILENAME
rm $FILENAME

might do the trick. overwrite the file with random bits and then delete it. for added security/paranoia, you could do a few overwrites, alternating between /dev/urandom and /dev/zero.

WARNING

I have not actually used 'dd' on files, only hard drives. read the man page and test it out on a drive you DO NOT CARE ABOUT first. I've nuked a few hard drives by screwing up 'dd' commands.

OBLIGATORY WARNING

'dd' is a seriously dangerous tool. do NOT run this on a production environment without first testing extensively, studying the man page, praying to your deity of choice and re-reading your commandline. think twice before pressing enter.

4
  • +1 Also clear out any tmp files for maximum coverage. I would run the command on the same line to minimize any delay in service due to a full filesystem, use a semi-colon in between.
    – kmarsh
    Oct 2, 2009 at 11:52
  • 2
    My apologies for not being up-to-date, but how is this any different than what shred or srm do? Oct 2, 2009 at 14:09
  • 1
    Just fyi this will not stop when it reaches the end of the file, dd will copy the entirety of the source until it runs out of room. Since /dev/urandom is a virtually unlimited source it will just fill up all the space on a drive. As Topher mentioned shred is a much better solution. Oct 9, 2009 at 13:57
  • 1
    This is part of what shred does/can do, so it has the same potential problems on a journaled filesystem. Oct 9, 2009 at 14:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .