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

Question

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.

Answer 1

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.

Answer 2

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).

Answer 3

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:

http://www.linuxquestions.org/questions/linux-general-1/script-to-empty-tmp-folder-415361/

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

Answer 4

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.