updated migration section
|Deletions are marked like this.||Additions are marked like this.|
|Line 96:||Line 96:|
|ThierryCarrez - The obvious objection to this will be the potential performance drop on disk-intensive operations in /home that don't require privacy (think unpacking and compiling sources). The addition of a pass-through system that allows to designate unencrypted directories (that won't suffer from any encryption performance penalty) would be nice to counter that objection. We would go from a setup in Intrepid where nothing is encrypted except the directories that you link in Private (opt-in encryption) to a setup in Jaunty where everything is encrypted except the directories you specify (opt-out encryption). That's a much better "secure by default" approach.
Packages affected: adduser, ecryptfs-utils, gnome-system-tools, Graphical Installer(s), Alternate Installer
Based on the delivery of EncryptedPrivateDirectory in Ubuntu Intrepid, this specification describes the next steps to extend that work to provide a seamless mechanism for encrypting a user's entire home directory, mounting it on login, and un-mounting it on the last logout.
The Ubuntu Jaunty Jackalope (9.04) release will enable per-user home directory encryption, automatically mounting it on login, and un-mounting it on the last logout of the user.
The EncryptedPrivateDirectory work proved the usefulness and stability of the Linux kernel's ecryptfs cryptographic filesystem. Encrypting only ~/Private directory, however, requires Ubuntu users to consciously store sensitive data in that location, and manually linking that data to traditionally locations.
See the use cases for:
Encrypted home directories will provide a more complete solution to encrypting all of the user's unique data, while not requiring the performance penalty of encrypting all of the data on the entire system and not requiring a passphrase to boot an unattended system.
Users of encrypted home directories are willing to pay the minor performance penalty incurred by encrypting/decrypting their data in the home directory in exchange for data security on the disk.
- We should get some formal filesystem benchmarks against an encrypted home directory.
Users will record their mount passphrase in a safe location, such that they can retrieve their data manually if necessary.
- We need to state this clearly on user creation, and provide a graphical utility for retrieving said mount passphrase and allowing the user to print/record it.
Swap space will be encrypted.
The eCryptfs Linux kernel cryptographic filesystem was chosen as the implementation mechanism for several reasons:
This is the same technology developed and proven in the Intrepid release in the EncryptedPrivateDirectory specification.
- The underlying cryptographic data is encrypted on a per-file basis, and as such, it is possible to incrementally sync changes to the encrypted data to remote backup systems.
- Since it is an overlay virtual filesystem, no predetermined disk allocation is necessary for the encrypted mountpoint. Rather, the same amount of available disk space available to a normal home directory is available to the encrypted home directory.
The functionality for bootstrapping a user's home directory for encryption has been released in the upstream ecryptfs-utils-67 release. This needs to be merged into Ubuntu Jaunty.
Following the merge of ecryptfs-utils-67+ into Jaunty, the adduser utility should be patched to support a --encrypt-home option. A patch is attached to 302870.
Similar to the patch for adduser, the graphical user adding tools need to be enhanced to support the adduser --encrypt-home option.
The Ubuntu alternate/server installer already supports creating an encrypted ~/Private directory on install. This debconf text should be modified to prompt for an encrypted home directory (encrypted ~/Private will still be available post-install). And the adduser call should be enhanced to use --encrypt-home (and not call ecryptfs-setup-private).
Ubiquity should be modified to add a check-box to the user creation page, reflecting the --encrypt-home option. Note that this option will need to be mutually exclusive of the Auto-Login option.
Most of the UI changes involved should be handled by a separate, but related blueprint:
Migration of data from a non-encrypted home directory to an encrypted home directory is a dangerous operation. As such, I will carefully document the procedure for doing so, but I do not believe it safe to provide a script to do so automatically.
This will be discussed at UDS San Francisco.
As of 2008-12-02, you can test this by:
Install the adduser and ecryptfs-utils packages in the following PPA:
- Add a user with an encrypted home directory as root, with:
# adduser --encrypt-home testuser
Login as testuser on the console, through the GUI, and via ssh. Ensure that all programs work as expected. Log out of the console/GUI/ssh. Ensure that the home directory is not mounted and that the data stored in /home/testuser/.Private is encrypted.
There are two other specifications, solving related issues:
- Encrypting Swap Space
- GUI for eCryptfs
Please post questions to:
ThierryCarrez - The obvious objection to this will be the potential performance drop on disk-intensive operations in /home that don't require privacy (think unpacking and compiling sources). The addition of a pass-through system that allows to designate unencrypted directories (that won't suffer from any encryption performance penalty) would be nice to counter that objection. We would go from a setup in Intrepid where nothing is encrypted except the directories that you link in Private (opt-in encryption) to a setup in Jaunty where everything is encrypted except the directories you specify (opt-out encryption). That's a much better "secure by default" approach.