Bug 448665
| Summary: | mkinitrd overrides /dev/urandom encrypted swap | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jason Farrell <farrellj> |
| Component: | mkinitrd | Assignee: | Peter Jones <pjones> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 9 | CC: | dcantrell, mike.cloaked, redhat-bugzilla, redhat-bugzilla, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-11-27 23:55:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Confirmed in F9 using keyfile (held in encrypted root) for unlocking swap. In my case I allowed the f9 install to create an encrypted swap and encrypted root partition. Once the install was complete then in the early boot phase the luks passphrase for root is requested, followed immediately by the request for the luks passphrase for the swap partition. Creating a keyfile that is stored in /root, and adding this (luksAddKey) to the swap partition, and then adding the 3rd field to /etc/crypttab with the path to the keyfile does not allow the swap partition to be opened without a passphrase prompt at boot. Manually executing mkinitrd to create a new initial ramdisk file still gives a passphrase prompt for the swap partition during boot. Presumably a modified mkinitrd would bypass this in a newly created initrd? So there would need to be an additional search on /etc/crypttab # where field #3 is /dev/urandom and #4 is "swap" (or blank?) and then exclude the swap partition when running mkinitrd? In comment #2 # where field #3 is /dev/urandom and #4 is "swap" (or blank?) Should perhaps be # where field #3 is /dev/urandom OR !NONE and #4 is "swap" (or blank?) Any filename replacing /dev/urandom, and within the /root area or other place in the root partition would make sense provided the root partition is also encrypted. I've just been bitten by this bug. Only encrypted partition I have is for swap. Entry in /etc/crypttab is swap1 /dev/sda6 /dev/urandom swap,cipher=aes-cbc-essiv:sha256 so I was somewhat perplexed that after rebooting to a new kernel, I was prompted for the LUKS passphrase! The /etc/fstab entry corresponding to this is: /dev/mapper/swap1 swap swap defaults 0 0 mkinitrd version is mkinitrd-6.0.52-2.fc9.x86_64. Is this still an issue with mkinitrd in rawhide? (In reply to comment #5) > Is this still an issue with mkinitrd in rawhide? I wasn't able to reproduce with mkinitrd.6.0.62-1 in rawhide, no. I don't see /etc/crypttab being parsed for exclusions, but neither did I see dm-crypt added or the new emit plymouth cryptsetup added to the initrd this time. When "Looking for driver for device mapper/luks-VolGroup00-LogVol01", it's no longer found. A quick look at the old vs new diff doesn't tell me if that's a fix, or a happy coincidence. fixed in f10. I've converted my swap as above, re-ran mkinitrd, and am not prompted for a password, as expected. |
Description of problem: Manually setting up encrypted swap post-install using "/dev/urandom" as the key, and "swap" as an option in /etc/crypttab to reformat it works fine (supported by /etc/rc.sysinit) until a kernel update comes along and does its mkinitrd, which then overrides this by using the first swap in /etc/fstab as an encrypted swsuspdev resume device. You're then prompted to manually enter the luks password, which doesn't exist in this case, because encrypted swap is being recreated with a random key on each boot. Version-Release number of selected component (if applicable): mkinitrd-6.0.52-2.fc9.x86_64 How reproducible: After installing a kernel update Steps to Reproduce: 1. Do a default F9 install (without any disk encryption) 2. Convert LogVol01 swap to luksFormat encrypted swap using /dev/urandom as key: a. swapoff /dev/mapper/VolGroup00-LogVol01 b. cryptsetup -d /dev/urandom create luks-VolGroup00-LogVol01 /dev/mapper/VolGroup00-LogVol01 c. mkswap /dev/mapper/luks-VolGroup00-LogVol01 d. swapon /dev/mapper/luks-VolGroup00-LogVol01 e. echo "luks-VolGroup00-LogVol01 /dev/mapper/VolGroup00-LogVol01 /dev/urandom swap" >> /etc/crypttab f. modify /etc/fstab to use "/dev/mapper/luks-VolGroup00-LogVol01" as the new encrypted swap device (which needs to be the first swap in fstab for mkinitrd to use it) 3. Reboot and "swapon -s" to verify that encrypted swap was automatically setup using /dev/urandom as key per /etc/crypttab. 4. Update the kernel, or manually run mkinitrd: mkinitrd -v -f /boot/initrd-$(uname -r).img $(uname -r) 5. Reboot once more Actual results: the newly generated initrd is now doing its own early cryptsetup for swap and prompting for a non-existent luks password. Expected results: mkinitrd should parse /etc/crypttab and exclude doing cryptsetup for swap if the user is using /dev/urandom, /dev/random, or /dev/hw_random as a reinitialization key. (akaik, /dev/urandom can't exist in initrd so excluding it is the best option) Additional info: there might be similar issues if using a keyfile VS /dev/urandom As a temporary workaround I've just hacked /sbin/mkinitrd to exclude my specific swap device: emitcrypto() { # parse /etc/crypttab instead at some point and exclude any entry # where field #3 is /dev/urandom and #4 is "swap" # also: add "export noresume=1" to /etc/sysconfig/mkinitrd if [ "$2" != "luks-vgr10-swapcrypt" ]; then emit "echo Setting up disk encryption: $1" emit "cryptsetup luksOpen $1 $2" fi }