This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 496753 - Encrypted swap requires a password
Encrypted swap requires a password
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-20 18:37 EDT by Matt Anderson
Modified: 2009-06-09 10:20 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-08 15:56:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Anderson 2009-04-20 18:37:34 EDT
Description of problem:
During the installation of a system with the Fedora 11 Beta I selected that swap should be encrypted.  The installer prompted me with a password dialogue box, but did not give me the option to select random.

Version-Release number of selected component (if applicable):


How reproducible:
Every time.

Steps to Reproduce:
1. Install Fedora
2. Select modify existing disk layout
3. Select encrypt this partition for the swap partition
  
Actual results:
The system forces you to supply a password or disable encryption on the partition.

Expected results:
A checkbox for random would be nice.  If the installer checked that the partition in question was swap it could assume random password by default, and allow the user to uncheck it to supply a fixed password for the swap partition.

Additional info:
Comment 1 Chris Lumens 2009-06-08 15:56:32 EDT
We don't really see this as a high priority, so it's unlikely to get any attention from us in the next release or two.  If you have a patch to add this support, we would be happy to review it for possible inclusion.
Comment 2 Peter Jones 2009-06-08 16:00:15 EDT
I can't see how this provides anything really beneficial.  Unless we're just storing the password on the disk, which is effectively as bad as not encrypting it, we're better off just using the same passphrase as encrypted root.
Comment 3 Eric Hopper 2009-06-08 16:09:37 EDT
Umm, here is the crypttab entry I want for swap...

luks-swap /dev/mapper/nvidia_cebgegbdp3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

I want swap to have a randomly generate password each and every time I use it.  It would be very nice to be able to set this up in Anaconda.

I would also like this for /tmp, though I've actually just gone to using tmpfs for /tmp since I would also like a special filesystem for /tmp in which the concept of syncing to disk is completely ignored since for /tmp it's not relevant.

I don't like the 'CLOSED DEFERRED' designation since I want to see when it _is_ implemented and that requires I hunt through the bug list periodically looking for the new bug for it so I can track.
Comment 4 Matt Anderson 2009-06-08 18:59:19 EDT
(In reply to comment #2)
> I can't see how this provides anything really beneficial.  Unless we're just
> storing the password on the disk, which is effectively as bad as not encrypting
> it, we're better off just using the same passphrase as encrypted root.  

The idea is to use a random key with swap each and every time you boot, which has the effect of wiping the swap partition on reboot.
Comment 5 Peter Jones 2009-06-09 10:00:47 EDT
> The idea is to use a random key with swap each and every time you boot, which
> has the effect of wiping the swap partition on reboot.  

This plan breaks hibernation completely, so it really isn't something we should be doing.
Comment 6 Eric Hopper 2009-06-09 10:20:18 EDT
(In reply to comment #5)
> This plan breaks hibernation completely, so it really isn't something we should
> be doing.  

So, because some people want hibernation, you are going to leave a feature I find indispensable for the security such that I have to hand edit configuration files and do a bunch of fiddling after I boot my newly installed system.  What if I want this as a corporate policy when installing onto new machines?

And with that reasoning, I really hope someone doesn't decide to randomly edit /etc/rc.sysinit so that crypttab entry will no longer work because it breaks hibernation.

Shouldn't I be the one to choose where to make the security vs. convenience tradeoff?

Note You need to log in before you can comment on or make changes to this bug.