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.

I have a hard drive that does not reallocate blocks, unless there is a bad sector.

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
    
@peterph That SQLite database is on disk. I don't want it to vanish if there's a power hit. PS, /var/log, not /var –  Nick ODell Sep 5 at 15:54

2 Answers 2

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 (actually any sensitive plain text data for that matter!) really properly - this basically mandates storing it physically in RAM and remembering to overwrite it with something else when not needed any more1.

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 (see 1). 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).


1Rather tricky part and your mileage may vary (as always with security). The point is, that even for a server there are case when that key (or other sensitive data) may be present in memory when it should not. In your case this can be for example when a service (database...) crashes (or is just stopped for maintenance) or, as suggested in a comment, in the case of a power-off, especially a forced one - i.e. the attacker physically removing the server from its place for analysis.

The first case could be solved by kernel wiping any memory pages belonging to an application after it frees them (thus including any for of application stop).

The second one is even trickier. You may ask why you should bother with RAM after a power-off and you wouldn't be the first one - read on Data remanence, Cold boot attacks and check e.g. Are there volatile memory chips which dont retain data after power off?. General answer: there's not much you can do without a specially designed hardware that would erase the RAM on power-off. And even then - can you exclude a possibility of an attacker hooking onto a running the machine on hardware level?

While this sounds paranoid, it is just a hint about what you may want to consider when implementing such a service. You have to decide what makes sense, what threats you don't really want to spend resources on and what trade-offs are acceptable. For example if you want to be able to reboot the machine unattended, then you're pretty much out of luck, since that requires it to have access to at least some unencrypted sensitive data (let's say the encryption key), which in turn breaks the whole privacy chain.

Another problem is, that you need to make sure it doesn't get swapped out - at least not an unencrypted swap storage.

To sum it up: question is not whether you can make it impossible for an attacker to get the data - it is how difficult you make it. You have to specify the how much part to see what makes sense.

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
    
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. I should clarify that this is on a server, and thus will be on all the time. So, if it's seized, and the key is in memory, then this solution doesn't do anything. Additionally, what if there's a power hit? –  Nick ODell Sep 5 at 15:52
    
Does the updated answer explain the it a bit better for you? –  peterph Sep 8 at 10:19
    
@peterph "Does literally magic" interesting... –  Griffin Nowak Sep 9 at 13:23

The best solution is really the simplest.

Don't save the information you don't want to end up in someone else's hands in the first place. Don't want your logs to be recoverable after deletion? Don't log. Don't want your cookies to be used to track you? Don't use cookies. Don't want deleted messages to be recoverable later? Well, that's a tough one, because the message had to be saved before it was deleted, so I can't help you there.

This is the method that web browsers with a "privacy mode" use. Their tracks aren't recoverable because they never leave them in the first place. No cache is used, no history is saved, no passwords remembered. Of course, they also warn you that the data you send can still be intercepted once it leaves your computer, so there's always a third party whose actions you can't control.

share|improve this answer
    
And I do that as much as possible. I'm specifically asking about what do do about data that I have to store at some point. –  Nick ODell Sep 10 at 18:42

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.