Loopback & crypt: a filesystem, within an encrypted partition, within a file

So here we are, 2012 and physical media are going away really fast. We won’t even talk about CDs which have been relegated to the role of plastic dust collectors; hard drives even are being abstracted by a myriad of cloud based solutions. Their purpose is shifting towards a container for the OS and nothing else. Filesystems & their hierarchies become hidden in a bid to remove any need to organize files, rather, you are supposed to throw it all up in the cloud and search on metadata.

While moving away from physical media is convenient and inevitable, I like the hierarchical organization that directories provide. What’s more intuitive than a labeled container with stuff in it?

How can we detach our hard drives from their physical shells, move them around in an omnipresent cloud and keep them secure?

By creating a file, attaching it to loopback & creating an encrypted partition in it!

Here’s how to do it
  • Create a file that will be your soft hard drive with:
dd if=/dev/zero of=/tmp/ffs bs=1024 count=524288

This will create a 512MB file (524288/1024).

  • Make sure that the loopback device #0 is free:
losetup /dev/loop0

You should see something telling you that there is “No such device or address”.

  • Attach the soft hard drive to the loopback device:
sudo losetup /dev/loop0 /tmp/ffs
  • And then make sure it was indeed attached by re-running:
losetup /dev/loop0
  • Create an encrypted partition on your attached soft hard drive:
sudo cryptsetup --verify-passphrase luksFormat /dev/loop0 -c aes -s 256 -h sha256
  • Open your encrypted partition:
sudo cryptsetup luksOpen /dev/loop0 ffs
  • Create a filesystem in it:
sudo mkfs.ext3 -m 1 /dev/mapper/ffs
  • And mount it like a regular disk:
sudo mount /dev/mapper/ffs /mnt
  • When you are done using your encrypted soft hard drive you will want to umount it:
sudo umount /mnt
  • Close it:
sudo cryptsetup luksClose ffs
  • Detach it from loopback:
losetup -d /dev/loop0

These steps can be automated of course. As a quick reminder, using the drive goes “loopback attach -> crypt open -> mount” and when you’re done it’s “umount -> crypt close -> loopback detach”.

That’s it! media-less & secure storage.

Tested on: Ubuntu 12.04 64b

Add fault tolerance to cron noise

Not all cron jobs are created equal, and some of them can afford to fail sporadically before we need to worry about them. Maybe they rely on a third party server, and we don’t want the occasional fail to pollute our inbox.

Here is a little cron job wrapper I created that will suppress stderr but keeps track of the job’s returned exit codes. Above a certain threshold of consecutive abnormal exits it doesn’t suppress stderr anymore.


# if the counter file doesn't already exist we create/initialize it
if [ ! -f /tmp/counter_ri7g3 ] ;
then
    echo 0 > /tmp/counter_ri7g3 ;
fi ;

# we pull the current counter
counter=`cat /tmp/counter_ri7g3` ;

# if the counter is still small, we send stderr to /dev/null
if [ $counter -lt 5 ] ;
then
    $1 > /dev/null 2>&1 ;
# otherwise stderr will follow its normal path and find its way to email
else
    $1 > /dev/null ;
fi ;

# lastly if running the $1 resulted in an abnormal exit, the counter is incremented
if [ ! $? = 0 ] ;
then
    counter=`cat /tmp/counter_ri7g3` ;
    echo "$counter+1" | bc > /tmp/counter_ri7g3 ;
# and if $1 exited normally, we reset the counter
else
    echo 0 > /tmp/counter_ri7g3 ;
fi ;

a cron entry calling it looks as such:


30 * * * *      root      /usr/local/bin/cron_wrapper "/path/to/script arg_1 arg_2"