Encrypted Swap as an Option

= Status =
 * Marking this blueprint "superseded", as we have implemented this in a different way, encrypting swap only when necessary (encrypted-home).
-- Dustin Kirkland

Discussion Points:
 * UDS Buy-in (main use case is hibernate):
  * karmic implementation:
    * encrypted home in installer -> setup swap encryption (ecryptfs-setup-swap), document hibernation incompatibility
    * randomly generate key on boot (no passphrase wrapping)
    * open wishlist bug for hibernation resume support
    * need UI changes to Applications> Accessories> Passwords and Encryption Keys
  * post-karmic implementation (hard):
    * algorithm: wrap randomly generated password with PAM system passphrase on login (for multiple users), store in LUKS keyslot
    * teach resume scripts to prompt for user's wrapping passphrase on resume, decrypt swap, resume
  * possible regressions and workarounds:
    * /tmp contents are still viewable, worked around in short term by using tmpfs for /tmp when system has some amount X of RAM, worked around in long term by moving /tmp into ~/.tmp
 * additional notes:
  * see who is using encrypted home and encrypted swap

 * Original suggested design:
  * encrypt swap, using a randomly generated key every boot
  * by default, use a static wrapping password like "ubuntu", and store the wrapped swap key in LUKS
  * teach hibernation resume (init?) to try this static default passphrase first
  * if that doesn't work, then prompt the user for the wrapping passphrase
  * in System->Administration, provide a utility that allows the administrator switch from the insecure default "ubuntu" wrapping passphrase to a PAM-based wrapping passphrase
   * teach PAM to take a successful login passphrase and re-wrap the randomly generated swap passphrase with the login passphrase if "secure swap" is enabled, (possibly populating 1 or more of the LUKS keyslots)
   * On "hibernate" event, ensure that the current user's passphrase has been used to wrap the swap passphrase in one of the LUKS keyslots
    * would need to prompt for a passphrase here, if this was an auto-login and the user wants secure-swap
-- Dustin Kirkland

(steve.langasek) When I migrated my laptop from hardy to intrepid, I turned on encrypted swap at the same time (swap LV on top of LVM+encryption). Anything that makes heavy use of swap on my desktop now brings the whole system to its knees. Please be cognizant of performance issues when implementing this - I fear this may be untenable as a default for desktop systems.

(Roderick Greening) It would never be expected to encrypt a swap file which exists in a LVM encrypted drive. Given that to build a LVM system, you have to use the alternate cd, the user would be in total control of these choices. Via the regular live CD/DVD, LVM is not a option (that I recall), so encrypting the swap by default should not be problematic.

(Paul Klapperich) As far as encrypted swap working with hibernate, it sounds like this goes nicely on computers that have a TPM as per the second link. I don't have one to test. For computers without a tpm, I don't know how ecryptfs works, but for luks we could perhaps use a pam module to hold the user account password for the duration of the login and set it as an alternate key for the luks swap partition (which previously had a random key only) if the user initiates a hibernate. Alternatively a global "swap password" could be created instead of (or somehow in addition to) random key encryption, but that's an extra password that now all users of the system would be required to know. It would, however, allow a resume from hibernate followed by a switch user if the person who hibernated is not present.

(Przemysław Kulczycki) Will this block the system's ability to write crash dumps to swap partition and to save it from swap partition to file after a reboot?

(Jerone Young) How can we start talking about something like this being by default when it has not even had field testing. If Jaunty is about stability this is not the way to go. Also since (from what I know) this is not being done in the kernel but rather in userspace, which is going to cause big performance issues when writing to swap. Another thing is where are the keys kept to decrypt the swap? How is a machine going to wake up from hibernation? This also will not work with the grub fast hibernation patches. Not a good idea to do at this time.

Got sign off from Dustin on the content of the specification, ready for review -- evand