How to prevent data leak from /tmp without ramfs or tmpfs?

Is there a simple way to configure automatic mounting of /tmp during boot, in a way that files are written to the disk withoug leaving recoverable data after the computer is turned off? Like ecryptfs with a random key for instance...

I'm using Ubuntu 10.10.

I don't use Full-Disk Encryption because unattended boot is important for me. I'm OK with the system files being unencrypted. My concern is that personal data, internet browsing, etc, eventually touches the disk unencrypted because is written to /tmp by some applications.

I cannot use tmpfs or ramfs because I am short of RAM (I don't want to use swap).

Application-level solution are not acceptable because I cannot guarantee (and don't want to) that every single applications will be configured so as not to write to /tmp.

  • You might want to look at setting up an encrypted LVM.
    – user78584
    Apr 27, 2011 at 15:04
  • Thanks for answering. Could you be more precise? I would like /tmp to have a new random key every time the computer boots, or something like that. Whether there is a primary or logical partition, or just a stacked filesystem, doesn't matter for me. Just that it doens't ask for input from the user and doesn't use swap.
    – user39559
    Apr 27, 2011 at 15:40
  • 1
    You need to provide a password to decrypt the disk, don't you? Otherwise, if it boots and loads the whole system without my intervention, how could system data be protected from my adversary and not from myself? I am unaware of such setup, please le me know if it is possible.
    – user39559
    Nov 14, 2011 at 15:57

4 Answers 4


May or may not work, but... you could try setting /tmp to not be writable by users, and set export TMPDIR="$HOME/tmp" (assuming $HOME is encrypted) somewhere that will be used in the env of all sessions (like, /etc/profile, perhaps?). I think many things should respect the TMPDIR environment variable, but all of them won't necessarily honor it.


You could try to run firefox in a selinux sandbox which will not only prevent /tmp from other users but will also prevent your home files from firefox :-)

Not sure how useful would that be on Ubuntu but after some customization works fine on my Fedora (15).

  • Sorry, I'm not worried about other users. My concern is that data gets written to the disk, in which case it can be recovered by someone having physical access to my computer.
    – user39559
    Dec 2, 2011 at 20:37
  • sandbox creates /tmp by default in tmpfs, but it has an option to create /tmp anywhere you want - for example in your encrypted home.
    – Martian
    Dec 4, 2011 at 8:57
  • I see... thanks! But I would like it to be automatic, that all the applications behave the same except that what they write to /tmp doesn't reach my disk. It's not only for Firefox and it should be automatic, nor relying on the user remembering to call sandbox each time they launch an application.
    – user39559
    Dec 5, 2011 at 13:13

all the applications behave the same except that what they write to /tmp doesn't reach my disk

In order for data in /tmp to not reach the disk, you need to put it in RAM (ramfs or tmpfs). On the other hand, as those are not options for you, you have two more choices (with data on disk):

  1. Change the default shortcuts or create aliases to the commands you fear that can leak information, like for example:

    alias vi='sandbox -M -H sehome/ -T tmp/ vi'

    So the user (or you) shouldn't remember to run a sandbox every time the app is launched.

  2. Automatically empty /tmp when there are no more locked files in it (a cron job that could run every 1 to 30 minutes) or on logout. This is my personal choice:


Add this line to your ~/bash_logout file. rm -rf /tmp/* 2>& /dev/null

Or, you could fiddle around using /dev/zero and dd to actually wipe the data from your /tmp

  • 1
    Thank you. But yet, I'm looking for something that works with all applications, without the need of an exaustive list of aliases. As for the auto-empty, in this case the data actually did touch the disk, even if it will be cleared afterwards (which depends on the storage technology etc etc).
    – user39559
    Mar 2, 2012 at 18:48

You can use an overlayfs, or a bind mount, etc.

Also if after /tmp is created and mounted, you just mount over it any path that is an encrypted container, it will do the trick.

Also you can do something really weird and maybe enter in panic mode.

You can mount /dev/null over /tmp, so any write to /tmp goes nowhere.

Why a lot of people think o so complex solutions that do not meet what you really want...

You said you want data do not hit the HDD... just mount over the path the /dev/null

Of course, data will not be readable after written... it is lost as is it being written... that is what is for /dev/null designed.

But if you want data hit the disk, but not in plain (aka, encrypted)... just do this:

  1. Create a file to hold the data
  2. Create a LUKS container on it (see --header parameter)
  3. Mount it over the path

So any write will go to the disk, but will be encrypted.

I must warn you about this:

  • Do you know each source code line off all parts (kernel, apps, etc) that will be run on the PC? If answer is no, you need a 100% disk encryption solution (including /boot, etc)... Grub2 + LUKS (multi-layer) is really great, see how to edit initramfs scripts to mount such LUKS, and be ready to type twice on each boot the passphrases... do not do what stupids does, store a KEY file inside the initramfs to avoid typing twice... cool boot attack will se it in plain and is really easy to find it.

If you are sure all your apps only write to "controlled" paths, try first with mount over a path that has a mount on it (it overrides the mount until unmount).

Sometimes, people search for a complex solution and do not see the easy one.

I mean, this will work:

  1. mount /dev/sda1 /mnt/MyHDD
  2. mount /dev/sdb2 /mnt/MyHDD
  3. umount /mnt/MyHDD
  4. umount /mnt/MyHDD

After 1 the files/folders seen on /mnt/MyHDD are on drive sda on first partition, after 2 the files/folders seen on /mnt/MyHDD are on sdb partition 2, after 3 the files/folders seen on /mnt/MyHDD are on drive sda on first partition, after 4 ¿? it depends on what was mounted there before 1.

So you can mount:

  • /dev/null --- will cause all data lost
  • /dev/mapper/crypto --- or whatever you call the LUKS (data will be encrypted)

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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