Backing up database data from a Crypt server

This is really just a step-by-step version of what's available in the July 2015 update doc, which links to Django dumpdata and loaddata.

If you want back up your Crypt server database, this is how you can dump the data out:

docker ps
to find the name of your docker container, in case you forgot it? Let's just assume, for the next command, that the container's name is Crypt.
docker exec -it Crypt bash
This gets you to a bash prompt inside the Crypt docker container.
cd /home/docker/crypt/
Change to the docker crypt directory.
python manage.py dumpdata > db.json
Dump the data out into a .json file.
exit
Exit out of the docker container bash shell.
docker cp Crypt:/home/docker/crypt/db.json .
Copy the .json file to where you are outside the docker container.

If you want to get back into the docker container to delete the original .json (since there is no docker mv, only docker cp), you can do

docker exec -it Crypt bash
rm /home/docker/crypt/db.json
exit

P.S. Thanks to Graham Gilbert for the tip about not needing to chmod the manage.py file.

P.P.S. This data dump method will work regardless of whether you're using the built-in sqlite3 database or an external postgresql database.

Basics of Crypt 2 and Crypt Server

Graham Gilbert created a pretty cool project called Crypt 2, which forces client machines to enable FileVault2 encryption, and then sends the recovery key to a Crypt Server.

So far the documentation on Crypt 2 is rather sparse, so this is what I was able to piece together based on the README, some asking around, and a lot of trial and error.

The server

The server bit was tricky for me to figure out. I happened to have a Ubuntu 16.04 LTS server I wanted to try it out on, but the Ubuntu 14.04 and Ubuntu 12.04 instructions did not work for 16.04. I got this error when trying to run the command to get the requirements:

Collecting django-extensions==1.6.8 (from -r
crypt/setup/requirements.txt (line 4))
Could not find a version that satisfies
the requirement django-extensions==1.6.8 (from -r crypt/setup/requirements.txt (line 4)) (from versions: 0.4, 0.4.1, 0.5, 0.6, 0.7, 0.7.1, 0.8, 0.9, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.3.0, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.3.8, 1.3.9, 1.3.10, 1.3.11, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.6.1, 1.6.2, 1.6.3, 1.6.5, 1.6.6, 1.6.7, 1.7.0, 1.7.1, 1.7.2, 1.7.3, 1.7.4, 1.7.5, 1.7.6, 1.7.7)
No matching distribution found for django-extensions==1.6.8 (from -r crypt/setup/requirements.txt (line 4))

It seems a lot of people go the Docker route. I'm not really an experienced Docker user, but most of the instructions are fairly straightforward.

After you install Docker, you just pull Crypt Server:

docker pull macadmins/crypt-server

Then, to test Crypt out, try the sqlite instructions from the docs.

And then, when you're ready to go full production, scrap that container, get a proper postgresql database and then follow the Using Postgres as an external database instructions.

Special notes based on things Graham Gilbert (primary developer on Crypt) told me:

  • You should not use the sqlite3 database for production. Nor should you use grahamgilbert/postgres as a docker container for a postgres database to link up. For a production Crypt server, you should link up to an external postgres database, preferably Amazon RDS or Google Cloud SQL.
  • For an external postgres database (whether self-hosted or hosted in the cloud), all you need is a database name, a username, and a password. Crypt will do the rest (creating tables and populating them).
  • If you decide to host the postgres database on the server that's running the docker container, localhost (or 127.0.0.1) is the actual Crypt docker container—it is not the host running docker. So you should specify the host as the actual fqdn or IP address.

Whether you ran the test Crypt with sqlite3 or a proper production Crypt with postgres, you should be able to see your site at 0.0.0.0:8000.

There are ton of ways, apparently, to get the site more secure. Since I'm most familiar with using Apache, I just put in a :443 VirtualHost entry with

ServerName SUBDOMAIN.MAINDOMAIN.COM:443
ProxyPass / http://0.0.0.0:8000/
ProxyPassReverse / http://0.0.0.0:8000/
and then that worked out for getting SSL going (as long as you've got SSL going for SUBDOMAIN.MAINDOMAIN.COM... that's too much to go into for one blog entry).

Once you have that set up, go to https://SUBDOMAIN.MAINDOMAIN.COM and log in with admin and password, and then immediately change the password to a new one.

You'll then have the option to add other users with various types of permissions.

The client

The Crypt 2 client is a standard .pkg you can deploy with whatever you're using to manage your client machines. You can configure your clients' Crypt 2 preferences before deploying the .pkg.

When the user who's okay to enable encryption (one not in the SkipUsers array) logs in, a window will pop up that says This machine must be encrypted. It will reboot shortly after clicking continue.

Crypt will write a file to /var/root/crypt_output.plist with values for EnabledDate, EnabledUser, HardwareUUID, LVGUUID, LVUUID, PVUUID, RecoveryKey, and SerialNumber.

After that, probably nothing will happen for some time. Crypt 2 runs a Launch Daemon that invokes /Library/Crypt/checkin every 900 seconds (15 minutes) 120 seconds (2 minutes). After around that time, you should see the client machine show up in the web interface the admin sees.

If you're using a self-signed certificate on your Crypt server, the curl command in the checkin script will fail when escrowing the recovery key. To avoid that (thanks to Graham Gilbert for the tip), you can add the .pem somewhere on the client machine and modify the .curlrc file for root to point to it.

If you click Info... ...and then Info / Request... ...and then Retrieve Key... ... you should be able to see the recovery key.

You may have to ask permission of yourself to view the recovery key (presumably if you have users with different permission levels, a user with lesser permission would ask an admin user for temporary permissions to view the recovery key).

Other options

This isn't a comprehensive list: