5

What exactly happens when an application deletes a file?

Is there any way to control this behavior? Basically I want to shred instead of rm in all cases, but of course applications do not make calls to rm, I am guessing they interact directly with the kernel?? Would I have to modify the kernel to implement this feature?

Braiam
  • 35,380
  • 25
  • 108
  • 167
jsj
  • 1,400
  • 1
  • 16
  • 28
  • 3
    Deleting a file ends up in the kernel's `unlink` system call (`man 2 unlink`). When you try to intercept that one, you need to watch out for specials (link count, file is still in use) before starting to wipe it. – ott-- Feb 26 '13 at 15:28
  • @ott-- you should put this as an answer below. I was just about to submit something similar to this, and then saw this. – sparticvs Feb 26 '13 at 15:43
  • 1
    I'd suggest that instead of writing your own fs, or attempted to do this in the C library somehow, patch an existing filesystem. E.g., maybe take a look at http://lwn.net/Articles/462398/ – derobert Feb 26 '13 at 16:03
  • 1
    What are you trying to achieve? For journalling filesystems, shredding data is well nigh impossible; same for SSDs. – Deer Hunter Feb 26 '13 at 16:19
  • @derobert nice link, I guess I'm not the only person to have thought of this – jsj Feb 26 '13 at 16:19
  • @DeerHunter I want deleted files to be unrecoverable, given that an adversary has decrypted the filesystem. – jsj Feb 26 '13 at 16:21
  • @trideceth12 “I want to survive even if someone cuts off my head.” The answer is not to have your head cut off. – Gilles 'SO- stop being evil' Feb 27 '13 at 01:15
  • This may be a stupid suggestion, but why not make "rm" an alias for "shred"? – Devyn Collier Johnson Nov 16 '13 at 21:29

3 Answers3

4

Rather than trying to intercept all filesystem calls, what about encrypting the filesystem your data is stored upon? Then, all of your data gains the benefit of being securely encrypted, including that which was deleted.

Rob Gibson
  • 476
  • 2
  • 6
  • 1
    Encryption is vulnerable to social engineering. But yes I get your point. – jsj Feb 26 '13 at 14:58
  • 2
    @trideceth12 Not encrypting is vulnerable to technical engineering. [`shred` is useless in most circumstances](http://unix.stackexchange.com/questions/50079/effectivity-of-shred-on-different-file-systems/66238#66238). – Gilles 'SO- stop being evil' Feb 27 '13 at 01:14
  • Okay from research it seems the consensus position is to encrypt the sensitive info separately, and then destroy the key when the information is to be deleted. This prevents being compelled to reveal the key. – jsj Feb 28 '13 at 00:20
2

You would have to go in to the C libraries as well as the filesystem kernel modules in order to catch all cases. Applications most often call a library routine that then calls a routine inside the filesystem module.

In short, the only reliable way to control this behavior is to write and use your own filesystem. I don't think you want to go there - I know I wouldn't.

John
  • 16,759
  • 1
  • 34
  • 43
  • 1
    Better than writing your own filesystem would be to patch an existing one, or [help one of the existing attempts](http://lwn.net/Articles/462398/) – derobert Feb 26 '13 at 16:12
0

The chattr s attribute might work on ext4-filesystems. I did not bother up until now.

I used wipe in important cases manually up until now.

Nils
  • 18,202
  • 11
  • 46
  • 82