28

Sometimes, there's the need to delete a file in a filesystem, and make sure that the file is truly gone. A file that contains sensitive passwords, for example, should be throughly wiped from the disk.

Issuing a simple rm on a typical file system deletes the inode ("pointer") to the file, but it doesn't delete the file's content in the physical disk - these are left there until they are overwriten when the filesystem needs the free space.

On many file systems, the shred program enables such secure deletion. However, on a CoW filesystem such as btrfs, this approach is useless. The problem is exacerbated by the fact that the file may be present on volume snapshots.

Is there a way to securely delete a file on a btrfs filesystem? Is it sufficient to delete all pointers (on all volumes) and fill the free space with zeros?

Improve this question
2
  • 2
    Good question, I haven't thought of that issue before. One way to work around that issue would be to encrypt such files. You also may encrypt the whole disk but if an attacker gains root access to the running system, that won't help you...
    – mreithub
    Commented Jan 24, 2013 at 1:36
  • @mreithub Indeed, encrypting such files is always a good idea in the first place, as is FDE. It cannot contemplate all use cases, though (a embedded system, for example - though it is arguable if such a system would be running btrfs anyway...). I'm actually asking this because I forgot to setup encryption before copying sensitive files, but I'd like to avoid wiping the whole partition
    – loopbackbee
    Commented Jan 24, 2013 at 13:57

3 Answers 3

Reset to default
11

Secure deletion is a tough proposition on any filesystem. Unless the filesystem is very peculiar and guarantees that there aren't other copies of the file lying around, you need to clear all the free space on the device. While you are more likely to find many bits of the file on copy-on-write filesystems, even more “static” filesystems don't have this guarantee in practice, because many files get edited, so there are bit from former versions of the file lying around.

Note that erasing with zeroes is as good as erasing with random bytes, and you don't need multiple passes. Erasing with zeroes left residual data that could be partially recovered in lab conditions with 1980's hard disk technologies; this is no longer applicable today. See Why is writing zeros (or random data) over a hard drive multiple times better than just doing it once?

You can get rid of the cleartext confidential data by encrypting everything on the disk. Set up an ecryptfs volume over that filesystem and move all your (confidential) files to it. Then overwrite all the unused space of the filesystem. You can erase most of it by filling the filesystem with cat /dev/zero >zero. There may still be some information left in incomplete blocks (blocks that contain the last chunk of a file, followed by some garbage — which could be leftovers from a confidential file). To ensure that there are no incomplete blocks, move everything on the filesystem to ecryptfs (ecryptfs's files use whole blocks, at least on typical setups where blocks are 4kB). Make sure to apply this to all volumes and to erase all snapshots containing plaintext confidential data.

There may still be some information left in the journal. I don't know how to scrub that.

On SSD, due to block reallocation, there may be data left that can't be read by normal software means but may be recovered by hacking the firmware or with physical access. There your only recourse is a full wipe of the SSD.

Improve this answer
4
  • 4
    Zeroes have the disadvantage that they can be compressed or entirely omitted (a SSD may TRIM instead of writing zeroes, as TRIM'd sectors return zeroes when you read them). That makes zeroes unsafe nowadays. Using random data forces the filesystem and disk to actually write out the data as is.
    – frostschutz
    Commented Feb 3, 2013 at 17:37
  • @frostschutz Would writing any character other than 0 be ok, and not subject to TRIMing, say writing all 1's instead? Or do some drives use compression on everything?
    – Xen2050
    Commented Jan 23, 2019 at 0:00
  • @frostschutz If you're filling an ecryptfs volume with zeroes (which is what I thought the answer is proposing here, though, on further inspection, I see his phrasing is actually ambiguous), then you'll be writing essentially random (uncompressible/uncheatable) data to the disk, no?
    – JamesTheAwesomeDude
    Commented Aug 14, 2019 at 13:42
  • @JamesTheAwesomeDude No, I was proposing writing the zeros to the unencrypted part, but I did mention that this wasn't enough on an SSD further below.
    – Gilles 'SO- stop being evil'
    Commented Aug 14, 2019 at 17:05
7

Hmmm, btrfs seems to defeat all usual shredding methods...

  • There is a mount option called nodatacow but that doesn't seem to affect already existing files.
  • As you already have sensible files on your disk this btrfs FAQ entry won't help you either.
  • Then there's debugfs. It's only for ext filesystems but there's a patch for it that might work. You could use it to find out the affected block addresses and then overwrite them directly on /dev/sdXY. But that's very dangerous and might not work (especially if there are more snapshots of the file)
  • Write a btrfs patch that allows one to modifiy (or shred) specific snapshots or a whole file

  • The cleanest attempt (for really really sensitive data) would be to:

    • buy another disk (unless you've got enough free space for a copy of the affected partition on the first one)
    • setup full disk encryption and your file systems on it
    • copy everything from disk a to b
    • boot into system b and shred the whole disk a...

    This might not be the cheapest approach but considering today's low storage costs and the trouble you'd have with the other options it might actually be the cheapest one (in terms of labor hours).

Improve this answer
1
  • nodatacow sets the default status of the C flag for newly created files. Surely one could just chattr +C ~/.browser/logins.sqlite and then shred it?
    – JamesTheAwesomeDude
    Commented Aug 14, 2019 at 13:40
-7

There is shred(1) for Unix/Linux (should be in your distribution's packages). I's what the EFF recommends.

Improve this answer
3
  • 5
    If you double-check the question, you'll see that I mentioned shred, and why it's not enough for the job
    – loopbackbee
    Commented Jan 24, 2013 at 13:54
  • All I find are suggestions to use encryption of sensitive files, for the reason you mention.
    – vonbrand
    Commented Jan 24, 2013 at 14:08
  • 3
    "On many file systems, the shred program enables such secure deletion. However, on a CoW filesystem such as btrfs, this approach is useless.". There's two links there, too.
    – loopbackbee
    Commented Jan 24, 2013 at 14:17

You must log in to answer this question.

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