Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm trying to make a service that keeps as little data on its users as possible. To that end, I want to make sure that someone using forensic tools won't gain any more information than I would by looking at my database or filesystem. In other words, you shouldn't be able to go through my hard drive with a hex editor and find a message that a user deleted yesterday.

Measures I've taken already:

I delete logfiles with identifying info within 30 minutes. I have swap turned off. I have /tmp, /home, /root, and /var/log mounted on a RAM-disk. I've removed rm, and put a hardlink to srm in its place.

Problems with my system currently:

  1. If a sensitive file is modified and made smaller, that will (AFAIK) deallocate a sector, which will then not be shredded, even if srm is called on the file.
  2. Changing rm does nothing for programs that call unlink directly.
  3. I have rows in MySQL that contain sensitive data. I delete those rows, but I'm concerned that MySQL keeps them around somehow.
    Edit: It appears that SQLite has a config setting called secure_delete. I'll use SQLite instead.

Possible improvements:

  • Set the chattr attribute s (secure deletion) I don't have this set now because the chattr manual says that ext2/3/4 ignores this flag. I found conflicting information about whether ext4 supports it. Which filesystems respect it?
  • Wipe free space. Seems like kind of a sledgehammer approach, but I can't figure out a way to solve #1 otherwise. Also, the ways I've seen for doing this involve making a really big file, then deleting it. I'm concerned that it might make a program crash when this system is almost out of space.
  • I could make text backups of the MySQL database (which definitely don't contain the deleted rows) delete the originals, then restore them.
  • Switch to a different SQL daemon?
  • Reboot to clear the RAM disk. However, I don't want frequent downtime. Also, it wouldn't do anything to clear out data lingering on the hard drive.

What's the best way to fix these three two problems? I'm currently using Arch Linux with ext3 and MySQL SQLite. I'm willing to change out any of those.

Thanks for your attention!

share|improve this question

migrated from unix.stackexchange.com Oct 13 '13 at 6:46

This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems..

    
What exactly are you asking about? Most of your text are just statements. –  peterph Oct 12 '13 at 8:10
    
Sorry about that! Does my edit clarify the question? –  Nick ODell Oct 12 '13 at 10:23
    
Nick, you forgot to mention @peterph to attract his attention to your edit. –  Joseph R. Oct 12 '13 at 12:23
    
@NickODell before trying to reopen, some things are still a bit unclear to me: what confidential data in your setup is not in RAM, having /home, /tmp and /var mounted there. Usually there's not much more, apart from the system itself. Are you using SSD or old-fashioned spinning plate HDD? –  peterph Oct 12 '13 at 15:32
add comment

1 Answer

Destroying data properly without physically damaging the media is quite a difficult task, especially since HDDs have started coming with block reallocations. This is orders of magnitude more difficult (if not impossible) with SSDs, since there the firmware does literally magic with what is really stored in the flash. As my comment asking for more detailed information about your setup went without an answer, let's assume an SSD is involved.

Since you can't really destroy the data, the next best thing is making them inaccessible. Which is what encryption is usually rather good at (when done right). Hence your generic solution is to encrypt all the data you want to be able to forget easily and throw away the key once such a time comes.

Implementation for various services may differ a lot and may (or may not) require substantial changes to your infrastructure. In all cases however, two rules will apply:

  1. use good encryption algorithm and configuration (mode of operation, IV generation)

  2. make sure you will be able to discard the key really properly - this basically mandates storing it in RAM and remembering to overwrite it with something else.

A simple example (on Linux) concerning users' home directories

  • Create a regular file - its size will determine the size of user's home, fill it with (pseudo)random data (one way to do it is to write zeroes to a dm-crypt device backed by that file)

  • Create a dm-crypt device backed by the file, keep the password stored only in RAM and make sure the key and/or crypto module setup doesn't get swapped out1. If you used a dm-crypt device for "randomising" the backing file in the previous step, use a different password now.

  • Create a file system on the crypto device;

  • Mount at user's home;

  • When you decide to remove the home, unmount it, throw away the key, remove the file (possibly fill it with random data again, but remember this doesn't make that much sense for SSDs).


1This might actually be the hardest part (unless it is already handled in the kernel). Even if it got swapped to an encrypted swap storage, it would still be accessible as plaintext for anybody able to read the swap on a running system until the swapped out page would get overwritten by something else.

share|improve this answer
    
None of these solutions apply here as presented: the question is how to achieve secure partial deletion. The answer is to use a separate encryption key per item, and wipe that encryption key. –  Gilles Oct 15 '13 at 22:00
    
@Gilles IMHO the question is rather blurry regarding what exactly needs to be done. The "encrypt then throw away the key" approach is quite generic and has to be adapted to a particular problem. The solution for user home I have offered is just an example - and the need for it is actually implicitly contained in the question. –  peterph Oct 15 '13 at 22:07
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.