[Blueprint server-karmic-encrypted-swap-as-an-option] Encrypted Swap as an Option

[Daniel T Chen]

Blueprint changed by Daniel T Chen:

Whiteboard changed to:

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.

-- 
  Encrypted Swap as an Option
  https://blueprints.edge.launchpad.net/ubuntu/+spec/server-karmic-encrypted-swap-as-an-option