EncryptedPrivateDirectory

Revision 29 as of 2008-06-11 18:53:50

Clear message

Summary

Provide a default location for users to securely store sensitive data using filesystem encryption.

  • ~/Private for each human user, permission 700 and an ecryptfs mountpoint

Improve the user experience of filesystem encryption.

  • Hook PAM to use login password to unwrap an ecryptfs mount passphrase and automatically mount on login

Rationale

Ubuntu has support LVM+LUKS encryption of entire partitions--an encompassing method of encrypting an entire disk. However, there are several drawbacks:

  • performance penalties for encrypting/decrypting all data, even non-sensitive data, such as /lib and /usr
    • painful for systems with intense i/o to such data (e.g. compilations of open source code)
  • a passphrase must be entered at every system restart, thereby disabling unattended boots
    • painful for server users
  • all content is encrypted using a single passphrase
    • per-user encrypted content would be nice
  • incremental backups of encrypted data is basically impossible with LVM+LUKS encryption
    • would be nice to sync encrypted changes on a per-file basis to untrusted remote backup systems
  • sensitive data should not be saved on remote stored (samba, cifs, nfs, etc)
    • would be more secure to encrypt all sensitive data written to remote storage

Powerful [http://en.wikipedia.org/wiki/Cryptographic_filesystems filesystem-level encryption] technology has been present in the Linux kernel since 2.6.19, including the ecryptfs filesystem and the kernel keyring. Userspace components, such as ecryptfs-utils, have been present in Ubuntu universe since Gutsy. Encrypted filesystems can now leverage advanced key management technologies (e.g. openssl, tpm, pkcs#11). to The tools exist for users to cobble together encrypted filesystems.

This specification defines the remaining tooling and missing pieces required to provide a cryptographic storage location for each user on an Ubuntu system automatically and by default.

Use Cases

  1. Lindsy uses her SSH keys for authentication, but does not lock them with passphrases since she uses them for a number of automatic operations (backups and such). Lindsy wants a simple location where she can securely store her private SSH key without using an ssh-passphrase, protected cryptographically in case her laptop is stolen.
  2. Leigh frequently uses her system to compile non-sensitive open source code. While she has data on the system that she would like to cryptographically protect, she does not want to pay the encryption performance penalty on highly intensive i/o operations such as her kernel compiles. She would like to only encrypt some of her documents she stores in /home/leigh, rather than all of /.
  3. Donna administers a small office server where several users have shell accounts. She would like to provide a simple mechanism whereby each of them have their own private directories where they can store their own sensitive files, which are readable to them when logged in, but encrypted on the disk and unreadable once they log out.
  4. Donna also administers a desktop system similar to the office server, where several users have their own account and unique desktop environment. She would like to provide a simple mechanism whereby each of them have their own private directories where they can store their own sensitive files, which are readable to them when logged in, but encrypted on the disk and unreadable once they log out.
  5. Kim uses Linux on her corporate desktop/laptop workstation, and mounts Samba/CIFS/NFS/(other-network-storage) for performance/redundancy/replication/data-integrity. She would like to ensure that all data written to the remote storage is encrypted, but available in clear-text on her workstation.
  6. Steph is very diligent about incrementally rsync-ing her home directory to her remote co-lo backup system. Since other people have physical access to her co-lo, she would very much like to incrementally sync encrypted copies of each file to her remote backup system.
  7. Gerri has an ecryptfs ~/Private mountpoint, but now wants to remove the ecryptfs-utils package and eliminate the filesystem-level encryption on ~/Private (she's a huge fan of DAC, apparently). She wants a way to undo the crytographic mountpoint.

In all use cases, the proposed functionality provides cryptographic protection (beyond normal UNIX [http://en.wikipedia.org/wiki/Discretionary_Access_Control discretionary access controls]) for each user not-currently-logged-in, but would absolutely protect the confidentiality of the ~/Private data in the event of physical theft of the system.

Scope

The current scope is to create a per-user encrypted mountpoint at ~/Private (which contrasts nicely with a ~/Public directory).

[https://wiki.ubuntu.com/UDS-Intrepid/Report/Server#head-9c87f7689e8500581dd5999d2dcd3510fa5ff90c As demonstrated within the sessions at UDS Prague], encryption within Ubuntu is a somewhat charged topic. The goal is to scope this specification to something realistically achievable within the Intrepid development cycle.

Additional items outside of the current scope include:

  • Encrypted swap (perhaps this should be promoted?)

  • Other encrypted mountpoints (/root, /etc, /var, /home/*)
  • UI tools for creating/managing/automounting encrypted mountpoints (e.g., Nautilus integration)

Design

Provide a default location for users to securely store sensitive data using filesystem encryption.

  • Create ~/Private for each human user
    • Maintain permissions of 700
    • Mount cryptographically (ecryptfs) on top of ~/.Private (also permission 700)

Improve the user experience of filesystem encryption.

  • Hook PAM to use login password to unwrap a mount passphrase
  • Automatically mount ~/Private on shell and desktop logins
  • Automatically unmount ~/Private on last shell/desktop logout
    • Change permission to 500 to protect against inadvertent writes
  • Move a few selected sensitive user data to ~/Private, and symlink to traditional location
    • ~/.ssh/
    • ~/.gnupg/
    • ~/.mozilla/

Implementation

Scripts used to configure, mount, and unmount these ~/Private cryptographic mountpoints are under development in cooperation with the upstream ecryptfs-utils project. The project is active, and the Debian package maintainer closely tracks upstream releases.

Currently, the following 3 scripts in the ecryptfs-utils package (Ubuntu universe) can be used to setup a ~/Private ecryptfs mountpoint:

Outstanding Issues

  • ecryptfs-utils needs to be promoted from Universe to Main (see: MainInclusionProcess)

  • As a related item, the adduser configuration files should be documented better, showing how admins can set home dirs to 700 by default. Along these lines, we could probably document how an admin could expand ecryptfs usage beyond ~/Private (perhaps to all of ~).

  • ecryptfs-setup-confidential could probably use an --undo mechanism.

  • The adduser utility needs to be hooked to optionally setup a ~/Private directory.

  • A user changing their password needs to re-encrypt and update the ecryptfs wrapped passphrase.

Outside of the scope of this spec:

  • Encrypted swap space would make this feature more secure, as keys and passphrases stored in memory could be swapped to disk.

Getting Involved

If you are interested in helping with this Blueprint, here are the things you can do to help.

  1. [https://wiki.ubuntu.com/EncryptedPrivateDirectory?action=subscribe Subscribe to changes of this page]

  2. Join the Server Team's IRC channel and mailing lists, as described in ServerTeam/GettingInvolved.

  3. Make sure you are aware of the IntrepidReleaseSchedule.

  4. At the very least, install ecryptfs-utils and run ecryptfs-setup-confidential and make use of your ~/Private directory, [https://bugs.launchpad.net/ubuntu/intrepid/+source/ecryptfs-utils filing bugs] as you see them.

Testing

The most important thing you can do to help develop this item is to use the scripts that create and maintain your Encrypted Private Directory, and [https://bugs.launchpad.net/ubuntu/intrepid/+source/ecryptfs-utils file bugs] against ecryptfs-utils.

Here are step-by-step instructions for setting up an Encrypted Private Directory:

  • You should have a completely updated/upgraded Ubuntu Intrepid system (KVM's work great!)

  • sudo apt-get install ecryptfs-utils - (version 46-1 has a broken ecryptfs-umount-confidential, run "sudo dos2unix /usr/bin/ecryptfs-umount-confidential" in the meantime, argggh)

  • sudo ecryptfs-setup-confidential

    • Enter your login passphrase - the password you use to login to the system

    • Enter your mount passphrase - a different passphrase used to encrypt the mount; you should only need this if you ever have to recover your data; in general, this passphrase will be decrypted using your login passphrase by PAM each time you login

    • Enter the confidential mountpoint - upstream defaults to /home/user1/Confidential, in Ubuntu, we're going to use /home/user1/Private

    • Enter the encrypted directory - unless you want the encrypted directory elsewhere (ie, on remote NFS or Samba storage), take the default (a hidden /home/user1/.Private directory)

    • The script will now create the directories, test the encrypted mount, setup PAM, setup /etc/fstab, and setup your bash profile and logout scripts
  • You should now logout, and log back in as user1

  • Run mount and see if you have an ecryptfs mounted directory

  • Check the permissions on the mounted /home/user1/Private directory (should be 700)
  • Put some data in /home/user1/Private and ensure that you can read/write cleanly
  • Open another tty or ssh and login as a different, non-root user while the first is logged in. Make sure the second user cannot read/write /home/user1/Private or /home/user1/.Private

  • Logout all instances of user1, and run mount as the second user. Check to make sure /home/user1/Private was unmounted. Ensure that user2 still cannot read/write /home/user1/Private or /home/user1/.Private

  • Log back in as user1, and make sure that Private is mounted again, and the data is readable.

  • As user1, force an unmount of Private with umount /home/user1/Private. Now cd to that directory and make sure you cannot inadvertently write to it. Listing that directory should show a single file with an informative name:

    • NOT MOUNTED - Run ecryptfs-mount-confidential to mount this directory

  • As user1, with ~/Private not mounted, try reading ~/.Private. Contents should be encrypted. This is what a malicious user should see if they stole your hard drive and booted a rescue cd.
  • For that matter, boot a rescue cd, and ensure that your encrypted data is encrypted
  • Try logging in as a desktop user into Gnome. Autostart should mount ~/Private. Test some of the same things as above.
    • We need to add support for KDE's Autostart as well

Development

DustinKirkland of the ServerTeam is handling most of the development. If you're interested in assisting:

BoF agenda and discussion

References