EncryptedPrivateDirectory

Differences between revisions 65 and 66
⇤ ← Revision 65 as of 2008-08-07 16:50:04 →
Size: 18838
Editor: cpe-66-68-158-133
Comment: added fingerprint read bug
← Revision 66 as of 2008-08-07 17:00:54 → ⇥
Size: 19494
Editor: cpe-66-68-158-133
Comment: responses to Emmet's question
Deletions are marked like this. Additions are marked like this.
Line 182: Line 182:
  * Good idea. See: Bug:247421   * Good idea. See: Bug:247421 -- DustinKirkland
Line 185: Line 185:
  * One issue with encrypting /home/user/ is collision with bind-mounting with schroot: if this becomes a common option, it may be worth investigating schroot (and possibly sbuild as well) to try to reduce requirements for additional passphrase entry for the encrypted /home/user. -- EmmetHikory   * Good comments, Emmet. At UDS, I advocated encryption of all of each user's $HOME directory for these reasons. That was deemed a bit too ambitious for Intrepid, and this work was scaled back to a single directory, ~/Private. It is surgical work, but it's not difficult to move particular directories into ~/Private and symlink them to their traditional locations. I would like to build on the technology we've implemented and tested in Intrepid, and revisit encrypting /home/* in Intrepid+1. -- DustinKirkland
   * One issue with encrypting /home/user/ is collision with bind-mounting with schroot: if this becomes a common option, it may be worth investigating schroot (and possibly sbuild as well) to try to reduce requirements for additional passphrase entry for the encrypted /home/user. -- EmmetHikory
    * Agreed, that's one of several issues that we would need to work through. -- DustinKirkland
Line 188: Line 190:
  * Good idea, I added a wishlist bug for it, wiki:Bug:255799. Unfortunately, I do not have a fingerprint reader on my Thinkpad, so it might be a bit difficult for me personally to implement.   * Good idea, I added a wishlist bug for it, wiki:Bug:255799. Unfortunately, I do not have a fingerprint reader on my Thinkpad, so it might be a bit difficult for me personally to implement.  -- DustinKirkland

Overview

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 supported 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 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 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).

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
  • Other encrypted mountpoints (/root, /etc, /var, /home/*)
  • UI tools for creating/managing/automounting encrypted mountpoints (e.g., Nautilus integration)

Design

Provide a 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 login (console, ssh, desktop, etc)
  • Automatically unmount ~/Private logout

In the Intrepid time frame, no information will be automatically written to ~/Private. Users may be encouraged to move a few selected, sensitive files/directories to ~/Private and symlink to their traditional locations. Some candidates might be:

  • ~/.ssh/
  • ~/.gnupg/
  • ~/.mozilla/

In a future release of Ubuntu (beyond Intrepid), we can consider automatically writing such sensitive date to ~/Private, or perhaps encrypting all of a user's $HOME.

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 scripts in the ecryptfs-utils package (Ubuntu universe) can be used to setup a ~/Private ecryptfs mountpoint:

The following C program produces a binary that, when setuid root, allows a non-privileged user to mount/unount their ~/.Private directory onto ~/Private, using the AES algorithm, and their 16-byte passphrase in the keyring.

The pam_ecryptfs module captures the user's login password and uses that to unwrap their encrypted ~/Private mount passphrase. It also executes mount.ecryptfs_private on login, and umount.ecryptfs_private on logout.

A complete set of manpages are now package with ecryptfs-utils 53-1.

MIRs have been approved and all necessary packages are in main.

The pam_ecryptfs.so module handles rewrapping of mount passphrases on password change.

Outstanding Issues

Necessary for Intrepid

  1. MIRs:

Hopefully by Intrepid

  1. Translation of "Private" (xdg-user-dirs?)?
    • See: bug:247421

  2. The adduser utility should be hooked to optionally call ecryptfs-setup-private

    • 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 ~).

  3. ecryptfs-setup-private could perhaps use an --undo mechanism.
  4. PAMConfigFrameworkSpec should be used as the long term solution, rather than auth-client-config

Outside of the scope of this spec, but hopefully in Intrepid:

Getting Involved

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

  1. 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, 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 file bugs against ecryptfs-utils.

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

  • These instructions are current as of version 53-1ubuntu1 (2008-08-04)
  • You should have a completely updated/upgraded Ubuntu Intrepid system (KVM's usually work well)

  • sudo apt-get install ecryptfs-utils auth-client-config

  • sudo auth-client-config -p ecryptfs_standard -t pam-auth,pam-session,pam-password

    • eventually, this should be solved with slangasek's upcoming pam-config utility in the packaging on installation

  • ecryptfs-setup-private

    • note that "sudo" should not be used for this operation

    • Enter your login passphrase

      • the password you use to login to the system

    • Enter your login passphrase (again)

    • Enter your mount passphrase [leave blank to generate one]:

      • a different passphrase used to encrypt the mount; you should only need this if you ever have to manually recover your data; you should record this in a safe location; this passphrase will be decrypted using your login passphrase by PAM each time you login; I think we're going to randomly generate this by default

    • The script will now create the directories and test the encrypted mount
  • 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.ecryptfs_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:

    • THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA -- Run mount.ecryptfs_private to mount again

    • This should be a symbolic link to /sbin/mount.ecryptfs_private

    • Try running (or double-clicking) on THIS DIRECTORY HAS BEEN UNMOUNTED...

  • 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/KDE/XFCE. PAM should automatically handle the mounting like login and ssh.

Development

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

BoF agenda and discussion

  • I like the idea of moving selected sensitive user data to ~/Private and symlinking to traditional locations in order to ensure sensitive data is kept encrypted. But what happens if the user decides they don't want this new 'Private' directory which appears when they install / upgrade to Intrepid? -- MarkRowan

    • My intention for Intrepid is to promote the utilities from Universe to Main, and develop the key pieces of infrastructure required to make an Encrypted Private Directory possible, simple, and relatively transparent to Ubuntu users. That is, I'd like to provide an encrypted private directory in each user's home directory which is mounted at login and any data written below that directory is cryptographically written to disk. I don't intend on moving any of the user's data to ~/Private--that will be entirely their decision in the Intrepid release. Based on the relative success and feedback, we can discuss what data could/should be written to ~/Private by default. Personally, my .ssh/, .gnupg/, and .mozilla/ directories are in my ~/Private, and symlinked to their traditional locations. -- DustinKirkland

      • Surely if automatically encrypting things is implemented later, it can be achieved with a separate hidden encrypted directory?
  • To the user, it doesn't usually matter if they delete or alter the default structure (e.g. by removing 'Music' or any of the other default directories which are created by xdg-user-dirs after each upgrade), but by removing ~/Private they will find themselves inadvertently deleting their sensitive data. This is made worse by the fact that the sensitive data in ~/Private is all contained in dot files or dot dirs, and so ~/Private will appear to be empty, unused, and therefore unimportant, even when it is not.

    • I respectfully disagree with this. As I said in response to the previous question, no data will automatically be written to ~/Private. A user would need to consciously write or move files/directories to ~/Private. -- DustinKirkland

      • Thank you for clarifying this. To me, it seemed that the specification implies that data will be moved without user knowledge during upgrade to Intrepid (at least, this is what I assumed from reading the Design section above). I just wanted to be sure that user data wasn't being moved into ~/Private without the knowledge or permission of the user. On the other hand, some upgrading users will need assistance in moving this data to ~/Private if they can be persuaded that it's a Good Thing. Could this be prompted during a post-Intrepid upgrade, perhaps? -- MarkRowan

  • I'd like to know whether you've thought about a way of translating the name of this directory? It would be good if this 'Private' dir was included in the XDG User Dirs specification, since it is a common use case. But waiting for this, you may need something like a patch for xdg-user-dirs update to achieve this. -- Milan71

  • While some data (encryption keys, etc.) are clearly private, I suspect that many users will find that many of the files they keep in their home directories are also private. In some cases (e.g. local mail repositories, etc.) moving this information to ~/Private/ is time consuming, as either each application must be modified to do that by detault, or hooks for every application must be installed for all users with ~/Private. Encrypting each of /home/user/ separately avoids this, and saves further configuration of applications that may have private data. -- EmmetHikory

    • Good comments, Emmet. At UDS, I advocated encryption of all of each user's $HOME directory for these reasons. That was deemed a bit too ambitious for Intrepid, and this work was scaled back to a single directory, ~/Private. It is surgical work, but it's not difficult to move particular directories into ~/Private and symlink them to their traditional locations. I would like to build on the technology we've implemented and tested in Intrepid, and revisit encrypting /home/* in Intrepid+1. -- DustinKirkland

      • One issue with encrypting /home/user/ is collision with bind-mounting with schroot: if this becomes a common option, it may be worth investigating schroot (and possibly sbuild as well) to try to reduce requirements for additional passphrase entry for the encrypted /home/user. -- EmmetHikory

        • Agreed, that's one of several issues that we would need to work through. -- DustinKirkland

  • It does not seem currently possible to use this solution in combination with a fingerprint reader, since the pam module has to intercept the login password. Is this going to be a possibility in the future? -- woutersj

    • Good idea, I added a wishlist bug for it, wiki:255799. Unfortunately, I do not have a fingerprint reader on my Thinkpad, so it might be a bit difficult for me personally to implement. -- DustinKirkland

References

EncryptedPrivateDirectory (last edited 2010-02-17 19:53:05 by cpe-66-69-226-228)