Blueprint changed by Dustin Kirkland:
Whiteboard changed to:
Discussion Points:
* 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
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
