Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on an .net app within aws. Basically our app pulls "generic" data from another organization for the purpose of building customized reports. The data is sent to us via ssl/tls and sent back the same...the processing is all conducted in RAM. It's only when the reports need to go into specific formats is there a period of time where the file is written to local disk and then sent back out. When this transfer is completed, the file is deleted.

Does it make more sense from a security / design perspective to have some program overwrite this file space, encrypt the data locally or on s3. Access outside of this transaction for management purposes is tightly controlled. It seems if there was some way to force the file into a specific container then have some program do a wipe function would be easier than encryption?

This isn't classifed data in terms of pci/hipaa, etc but may contain confidential customer information. Is something like this really a major obstacle from a security perspective as well?

Other thoughts?

share|improve this question

I assume you need a temp file to feed an external formatting program that only offers a file-based interface (perhaps something like Crystal Reports or Adobe Acrobat, or whatever.)

One general approach might be to limit your exposure. You could mount the temp file on a separate dedicated partition or drive, and restrict access to that even further. If you keep the temp partition small as possible, deleted sectors will be more quickly re-allocated and overwritten. You could use an encrypted partition.

Even better, you could implement that dedicated temp drive with a RAM disk (aka RAM drive) so the bytes never actually hit durable physical storage media. A power-off or reboot of the machine will ensure it's wiped.

share|improve this answer
John - I like the RAM drive idea...we just need to figure out how much we need.;) Thanks – Travis Howe Aug 26 '13 at 21:35

Writing over files in-place is hard and nigh impossible with current day operating systems. Here is the caution blurb given by the venerable shred command:

CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective: ...ext3...RAID−based file systems... NFS


There are a few things you could do minimize your exposure. You could:

Clean Up Properly

When utilizing temporary files many programmers will make the following mistake:

tmp_file = generate_tmp()    


rm -f tmp_file

This unfortunately won't guarantee clean-up. If do_something() exits out of your program/script, the temporary file will persist until some sort of clean-up process gets it.

The better approach is to use something like BASH's trap or Java's finally to ensure temporary files are clean-ed up properly during any condition. So an acceptable approach would be something like:

tmp_file = generate_tmp()

try {
finally {
  rm -f tmp_file

Write out to volatile storage

As John noted, write the contents to a volatile disk such as tmpfs/ramfs which would be cleared on system shut/powerdown. Though this is obviously limited by the size of your RAM, in which case you might as well do all the generating/processing in memory as well.

share|improve this answer
Thanks all...we're going to give the RAM idea a go, it's kind of what we had been thinking. Thanks again! – Travis Howe Aug 27 '13 at 14:58

It is hard to tell what OS you are running on, maybe it is UNIX or Linux.

Assuming you are doing that, you can immediately open() a temp file, then remove() it. It remains open for the duration of the process that opened the file. Or until that pocess explicitly calls close() on the file descriptor. UDP sockets will transfer file descriptors between processes. The transferred descriptor is valid for both processes.

Since your question is a little vague, this may be completely off base from what is needed. It is however an old and useful security feature.

Refer to Stevens & Rago 'Advanced Programming in the UNIX Environment' or Michael Kerrisk 'The Linux Programming interface' There are relevant examples for all of this in both books.

share|improve this answer

Your Answer


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.