Gradually encrypting my work environment

When work is outsourced to a freelancer or agency, the client needs to have reassurance that the external developer will respect any data or intellectual property that must needs escape their personal control, however briefly. While it's all very well to encapsulate this in contractual liabilities, it's also a great service to be able to offer your clients peace of mind.

Enter encryption. The ideal scenario - total encryption of one's entire work environment - is probably not achievable by most people overnight, certainly not without sacrificing a lot of their existing system's configuration (or at least running the risk.) And in this specific context of reasonable liability, it's almost not worth discussing things like NSA-instigated back doors.

All that aside, there's still a lot of simple quick wins you can achieve with incremental encryption, piece by piece, of the code and data you work with. Piecewise encryption won't guarantee your liability in super-confidential environments, but it will dramatically minimize your exposure to difficult situations, should you lose your laptop or become the victim of a theft.

Here's a few simple encryptions I've implemented on my work environment which might be of interest to other people working similarly with a third party's electronic property.

Remote storage

Encrypting a USB stick in Ubuntu is trivial: here's a wiki page about how to encrypt removable storage. It's arguably the first and biggest thing you can do, because even if you keep your laptop in a vault at home, you might still be exposed to risk through losing tiny bits of electronics like USB sticks. With an encrypted stick you can visit a client's office environment, and if they want to give you some files to take home, you can do so while showing clear consideration for theirr data.

Note that if you initialize the encryption, but don't then create the filesystem at that point, you have to start again: it won't mount properly if you bail half-way through. Also, the GUI is a bit fiddly: I found that it would neither let me start with the stick unmounted, nor actually encrypt when mounted. It's probably best to follow the above steps using the command line.

Home folder including documents folders

You should encrypt your home folder if your client sends you commercially sensitive documentation; and then actually store it there, obviously!

Ubuntu offers encryption of the home folder as an option when you're installing. Retrofitting such encryption at a later date is a little bit trickier, but possible. To do so, you need a temporary, separate admin user and and it's mostly straightforward, but here's a few extra notes: 

• Before encrypting, consider moving large files elsewhere, and maybe symlinking the directories in. "du --max-depth=1" can help you gradually drill down to large files, although simply moving any big VM boxes out would be a good first step!
• Your own account should be both logged out and also have no more processes running: check "ps aux" for any processes owned by that user, and kill them with "kill -kill". These processes could be accessing files in your home directory, which blocks conversion to encrypted.
• The temporary user shouldn't have their own home folder encrypted, as it seemed to confuse at least one of the sudo commands (I can't remember which.) But it's a temporary user anyway.
• You might also encounter this gvfs bug but I don't think that it actually blocks, as long as you've done the above.)

Codebases: web root

Specific folders can be encrypted using encfs. This encrypts any folder, which you'll typically hide, then use the Linux "mount" command to turn it into a separate decrypted folder while your owner-user account is logged in. libpam-encfs extends encfs so that it will automatically mount and decrypt as you log in. Here's a few pointers:

• You need to specify the --public option to encfs whenever it runs, so that your webserver user (www-data if you're using Apache) can see in the folder(s).
• Both encfs and libpam-encfs are available in Ubuntu's package repositories: sudo apt-get install encfs libpam-encfs
• Add yourself to the fuse user group, by editing /etc/group if you need to
• Ensure /etc/fuse.conf is group-owned by the same group: sudo chgrp /etc/fuse.conf && sudo chmod g+r /etc/fuse.conf

In /etc/security/pam_encfs.conf, you should make the following changes:

• remove "drop_permissions" so that --public is respected
• remove --idle=1 from encfs_default unless you want detaching on idle - not sure what the criteria for "idle" are, so if you can't see a reason to detach, I'd keep it connected.
• Give fuse allow_other privileges, not allow_root, as that conflicts with giving encfs the --public permissions
• Add the mount point to the list at the end of the file.

At this point you can probably reboot to test whether or not this works. Rather than logging into graphical Unity, GNOME or similar, you should press CTRL-ALT-F1 and log in at the terminal; that'll give you more feedback in case any of the configuration is wrong. Incidentally, the documentation for pam-encfs is idiosyncratic to say the least, and I feel your pain, but: it's actually a lot more straightforward than it seems.

Databases: don't encrypt; cleanse instead

In theory you could also encrypt your database storage folders too: for example, MySQL stores all of its files in /var/lib/mysql. However, a much safer practice is to not rely on encryption at all, and instead cleanse the database as you import it; better, ask the client for cleansed copies, so you never have sensitive data on your machine. Obviously if you're doing e.g. a data migration then cleansing the database is often not feasible.

However, once the data is clean of anything sensitive or personal, the only remaining issue is if your client considers the database schema to be their intellectual property. This isn't likely to arise if the schema is created e.g. by third-party software like Drupal, but you should probably confirm it with the client if you're worried.

Summary

One of the down sides of freelancing, or becoming your own boss generally, is that the liabilities which used to fall on your employer's shoulders - leaving you with the maximum liability of losing your job - now fall squarely on yours and yours alone. While there's a feeling of pride in representing yourself or your own company, there's also considerable risk involved when iit's just you versus the world. Implementing small amounts of encryption here and there can quickly provide peace of mind for your clients, but also for yourself and your business.