Encrypted home directories!
I have two packages available for beta testing in my PPA:
- adduser
- ecryptfs-utils
- adduser --encrypt-home foo
I've tested this pretty thoroughly with both command-line, server logins, as well as graphical desktop logins. It's working really well, and I'm quite excited about it! This is going to be far easier and more secure than moving bits and pieces of data in ~/Private, and manually symlinking files and directories around.
Caveats...
- Encrypted filenames have landed in the upstream Linux -mm kernel; but they're not in the Ubuntu Jaunty kernel yet. I think they should make in time for the Jaunty release.
- Migrating an existing, non-encrypted home directory to an encrypted one is not something that we can do automatically--there's quite simply too much that can go wrong. I will, however, provide a wiki page describing how to do it as the root user, in a recovery shell. Basically, bad things can happen if any other processes running as the user try to read or write data in their home directory during the migration.
I've released the code necessary to setup the encrypted home directory in ecryptfs-utils-67. As soon as Debian pulls that release into unstable, I'll merge it into Jaunty (and then you can skip the PPA step).
After that, I hope to add "Encrypt Home" as an option to both the graphical and server installers, when creating the administrator user. We should be able to do this in the Server Installer easily by Alpha-2, and the Desktop Installer by Alpha-3.
Also, we need to modify the graphical "User Settings" program as provided in system-tools-backends to support the --encrypt-home option.
Miscellaneous
Separate, but related to this work item are two other blueprints for Jaunty:
:-Dustin
I work with sensitive data and I work with Ubuntu. I would love to see this easy addition of encryption running. I would also love to see how it affect the general performance of the system...
ReplyDeleteCould it be possible to optionally do an automatic migration upon reboot (or even restart of X)?
ReplyDeleteAfter such a big change, I think it's ok to ask for a reboot to complete the process. :)
I've done a number package builds in an encrypted home directory, with little or no performance penalty.
ReplyDeleteHere, I built the qemu package from Jaunty Universe 3 times:
a) in a non-encrypted directory in a ramdisk (28m14.601s)
b) in a non-encrypted directory on disk (28m15.348s)
c) in an encrypted home directory on disk (28m34.856s)
So at least in this workload (compiling software), there's less than a 1% performance hit.
I'm looking for a more scientific filesystem performance analysis, if there's anyone out there with such expertise.
:-Dustin
WOW, then performance doesn't seem to be a problem.
ReplyDeleteNow I wonder what US Customs and TSA will think about encrypted data (I'm actually waiting for the answer of the IT guy in my company )
Thanks Dustin for all the information
Diego-
ReplyDeleteRight, at least in this one test case (compiling source code), there's no significant performance hit.
This really wasn't a very scientific test, though, so let's await a more thorough performance analysis ;-)
:-Dustin
Encrypted home directories make a lot more sense than the private directory idea. It avoids the usability nightmare of having to expose the mounting and authentication in the desktop UI.
ReplyDeleteIt's good to see you following through with this. And Its great to see you pushing changes upstream.
Question how do you handle resetting the password for the encrypted volume?
Does that happen when a user resets their login passphrase? Is that sort of feature on the roadmap?
And will you be able to mix and match this with other pam authentication modules other than the standard pam_unix module? On login and user creation?
For example can you mix in pam_ssh module? or pam_ldap? instead of pam_unix?
It would stellar if you could create an ldap user with an ecrypted home directory.
-jef
Jeff-
ReplyDeleteThere's a pam_ecryptfs module where I handle all of this magic.
It handles your password changing just fine. Basically, your login passphrase and your mount passphrase are two different entities. The mount passphrase is "wrapped" or encrypted using your login passphrase. When you login to the system, your login passphrase is then used to "unwrap" or decrypt your mount passphrase, and then perform the mount. If you change your login passphrase, pam_ecryptfs simply unwraps, and then re-wraps your mount passphrase. That way, we don't have to go through the excruciating process of re-encrypting every file.
To your other question, this automatic unwrap-and-mount works on any PAM login--desktop, console, ssh, etc. The common-session, common-auth, and common-password stacks all include pam_ecryptfs.
:-Dustin
:-Dustin
Ideally I would like to have a long encryption passphrase and a shorter user password for sudo usage.
ReplyDeleteThe encryption passphrase needs to be pretty long to prevent a dictionary attack. I currently use encrypted LVM with a passphrase of over 20 characters.
I don't really want to have to type 20+ characters every time I do sudo (or gksu).
Maybe I'm being overly paranoid, but it would be nice to separate the two ...
Like the previous commenter, I also currently use encrypted LVM with a passphrase over 20 characters. I'd be willing to type it every time I wanted to use sudo, but I'd rather not have to.
ReplyDeleteAnyways, keep up the awesome work!