Securely Delete files - Ubuntu

So recently there was a lot of talk at work about keeping our customer data secure. Each of us was fully responsible for the customer data that we had on disk.

I use Ubuntu 12.04 with a ton of Virtual machines. Here's what I ended up doing to do my bit to keep all our customer data safe.

a) Set a BIOS password - If your laptop gets stolen and someone wants to boot off a USB, this makes it harder. Obviously though, they can just take your hard disk out and plug it into another laptop..

b) Full Disk Encryption - Sure ..they can plug your disk into another machine. If all your data is encrypted (Ubuntu allows you to encrypt data while installing it) and you have a reasonably strong passphrase (Greater than 10 characters + Capital letters, small letters, digits and special characters) it's going to be really hard to try and crack.

c) Do not store any customer data on your laptop - It's hard to do this, but really it's the best way. Let customer data be stored on secure servers inside a server room or datacenter, where it can't be stolen that easily. Some customer data storage though might be unavoidable...

d) Use Truecrypt if you must store Customer data - Whatever data there is on your laptop, encrypt that again using Truecrypt and a strong passphrase. So even if someone cracks your full disk encryption passphrase, all they will find is a Truecrypt file.

e) Securely delete content all the time - Using rm -rf or Shift + Delete is no good, as forensics tools will be able to recover data. Use the secure-delete suite of tools to delete data securely. I added an alias to my rm command so I don't ever accidentally only use 'rm' instead of 'srm'.

alias rm = 'srm -rv'

This overwrites files 38 times before deleting them by default. Each file :D. It's probably overkill. So I'd recommend doing something like srm -rfvl filename (The l does just 2 passes instead of 38) and doing an rm filename at the end of every project.

f) I also plan to read up on the other tools that the secure-delete suite offers and run those to clean up my RAM (Run sdmem -v as root)and fill (Run sfill -v MountPoint as root. You can identify your mount points either by running the mount command, or by running df -kh and looking at the Mounted On column) up all my unused space with random data. This is needed because I've been deleting insecurely for a long time now. As of now, I also plan to never delete from Nautilus because adding commands to the context menus using various guides is proving to be an utter pain.

g) Formatted all my flash drives and created a Truecrypt volume on the only flash drive that I plan to use to store customer data. So even if the flash drive gets lost, the data is still reasonably hard to get at.

Truecrypt - Permission and Mount problems

I use Truecrypt files all the time on top of my Full Disk encryption for all my sensitive customer data. I also use sshfs to mount a remote filesystem over SSH and then transfer files from my Truecrypt volume to the server.

What tended to keep happening was that when I copied files onto the server, the files would be editable only by me and not by other members of the group. This was a problem as multiple people work on a single project.

After a bit of research I found out that my local truecrypt volume was being mounted with permissions of rwx --- --- meaning just I, the owner had access. Then, when I copied files from that volume to the server, those permissions were being retained.

The solution to this was to mount my local truecrypt volume with a umask of 017. This would mean that the owner and group would be able to edit the files after I uploaded them. Problem solved.

One day though, I needed something from an older truecrypt volume and found that I couldn't mount it. I kept getting an error which said - mount: wrong fs type, bad option, bad superblock on /dev/mapper/truecrypt1

Huh? Corrupt volume? I restored the truecrypt volume header from the backup it stored internally (look at the Truecrypt docs for how to do this) and tried mounting again. It still failed. After a little Googling to no avail, I started thinking what I'd changed.

Mount options. Umask. Removed the Umask mount option. Tried mounting. Works. Ha. So apparently, since I didn't use the umask option when I created the old volume, it wouldn't let me mount it if I used it. Probably a good reason for it...don't know what :)

So now, I mount Volume 1 without the Umask and Volume 2 with the Umask and both work. You can set and unset the Umask in Settings - Preferences - Mount Options and type umask=017 there.

There's another way to do it. While mounting the volume without the Umask, you can click on Options at the time of entering the password and set/unset the Mount options there. Doing this means the default mount options will be with the Umask.