From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.6) Gecko/20040312 Epiphany/1.1.12 Description of problem: I am interested in seeing Fedora support encrypted root filesystems. I wrote a patch for mkinitrd that adds this ability. Eventually, I would like to see support for setting this stuff up using anaconda. Right now it has to be done by hand. Here are the steps to using this new feature: 1. Install cryptsetup 0.2, which includes the new libcryptsetup. This package is available at: http://www.saout.de/misc/dm-crypt/cryptsetup-0.2-pre1.tar.bz2 2. Add -lselinux to cryptsetup's main Makefile, as this is needed on Fedora. 3. Create a VFAT filesystem on a memory stick and mount it at /<mntpt>. 4. Create a filesystem key using: dd if=/dev/random of=/<mntpt>/efsk bs=1 count=32. 5. Prepare the encrypted device using: cat /<mntpt>/efsk | cryptsetup -h plain create root /dev/<realrootdev>. 6. Create the encrypted filesystem: mkfs.ext3 /dev/<realrootdev>. Populate the filesystem. 7. Create your initrd: mkinitrd --keydev=/dev/<memorystickdevice> --keypath=efsk --keymat-fstype=vfat --initrd-fstype=<realrootfstype> -f <locationofinitrdimage> <kernelversion>. Version-Release number of selected component (if applicable): mkinitrd-3.5.22 How reproducible: Always Steps to Reproduce: Notice that mkinitrd does not support encrypted root filesystems. Additional info:
Created attachment 100700 [details] Patch to add support for encrypted root filesystems to mkinitrd
Anything like this has to be done generically, so it would work for all supported system configurations. Hard-coding like 'mknod $MNTIMAGE/dev/mapper/control c 10 63' is a complete no-no. Ought to sort out the required generic functionality first - e.g. what options for entering keys are reasonable in a boot-up situation for different people to choose between? Does cryptsetup 0.2 still pull in an unnecessary(?) libgcrypt dependency? Is it simpler to use dmsetup directly sometimes?
Note that hard-coding /dev/mapper/control like that is unnecessary with nash's mkdmnode function. But I agree that there are a lot of unanswered questions before applying this makes sense -- we need to have the whole system-wide picture of how encrypted filesystems works.
My plan is to continue working on this patch to make it more generic, etc. Whether this work serves as simply a proof of concept or is actually integrated into mkinitrd, I hope to start getting things moving forward. I appreciate the feedback so far and look forward to receiving more in the future.
Created attachment 101270 [details] Patch to add support for encrypted root filesystems to mkinitrd This new patch has the following additions over the last one: o use nash's mkdmnod instead of mknod o took USB module loading code; use --with-usb instead o requires patch to initscripts (see bug #125086) o start to add support for other authentication methods
Created attachment 101644 [details] Patch to add support for encrypted root filesystems to mkinitrd This version add the ability to read /etc/sysconfig/rootfs, a configuration file that should be created when the root filesystem is formatted. Here is an example of the contents of this file: AUTHTYPE=filesystem KEYDEV=/dev/sda KEYPATH=efsk KEYMAT_FSTYPE=vfat ROOT_CIPHER=aes This allows mkinitrd to be run from RPM %post scripts and such without any special command line arguments. Arguments like --authtype will still override the contents of /etc/sysconfig/rootfs.
*** Bug 115366 has been marked as a duplicate of this bug. ***
*** Bug 127183 has been marked as a duplicate of this bug. ***
I think that using a /etc/crypttab file in the same format as Debian will make things a lot easier. Here is a sample crypttab: # <target device> <source device> <key file> <options> swap /dev/V0/swap /dev/random swap root /dev/V0/fc2 /etc/root-key defaults For example the above file would specify that the device /dev/mapper/swap would be /dev/V0/swap encrypted with a key from /dev/random. In Debian the "swap" parameter at the end of the line indicates that after the encrypted device is setup the command "mkswap" should be run on it. Now mkinitrd could check /etc/fstab, see that the root device is /dev/mapper/root, look for the appropriate entry in /etc/crypttab then know it needs to put /etc/root-key in the initrd and do the mapping from /dev/V0/fc2 .
Created attachment 102779 [details] Patch to add support for encrypted root filesystems to mkinitrd Please: NO STABLE SYSTEMS YET! This new patch has the following changes over the last one: 1. Now reads /etc/crypttab instead of /etc/sysconfig/rootfs to be consistent with bug #127378. 2. Now provides a new authentication type "paranoid" that assumes the initrd will be installed on a removable device. This device is assumed to be physically secured and will contain a plaintext copy of the encryption key. To use this mode: mkinitrd --authtype=paranoid -f /boot/initrd.gz 2.6.8. 3. Patch is against mkinitrd 4.0.5.
Created attachment 103215 [details] Patch to add support for encrypted root filesystems to mkinitrd Please: NO STABLE SYSTEMS YET! This new patch has the following changes over the last one: 1. No longer requires libcryptsetup. This patch may now be used with the stock Fedora cryptsetup RPM, as long as it is compiled statically (see bug #129926). 2. The "filesystem" authtype is no longer worked due to change 1. 3. The patch is against 4.1.8, but I have been having trouble with 4.1.8 on my iBook. The patch applies cleanly against 4.1.1 and this is the version I am currently using.
Created attachment 103216 [details] Patch to add support for encrypted root filesystems to mkinitrd Please: NO STABLE SYSTEMS YET! This new patch has the following changes over the last one: 1. No longer requires libcryptsetup. This patch may now be used with the stock Fedora cryptsetup RPM, as long as it is compiled statically (see bug #129926). 2. The "filesystem" authtype is no longer worked due to change 1. 3. The patch is against 4.1.8, but I have been having trouble with 4.1.8 on my iBook. The patch applies cleanly against 4.1.1 and this is the version I am currently using.
Created attachment 103419 [details] Patch to add support for encrypted root filesystems to mkinitrd Please: NO STABLE SYSTEMS YET! This new patch has the following changes over the last one: 1. Now assumes that a statically linked cryptsetup exists in /sbin (see bug #129926). 2. Now handles the fourth field in /etc/crypttab, the options field. For example, "cipher=aes." 3. The patch is against 4.1.9.
Cryptsetup is now statically linked. Can we get this encrypted root code in? If not, what needs to be done?
Created attachment 105456 [details] Patch to add support for encrypted root filesystems to mkinitrd Patch is now against mkinitrd 4.1.18.
It's far too late in the FC3 cycle to add things like this. But I'll look at it again after FC3 goes out for FC4.
The patch against mkinitrd-4.1.18 still applies cleanly to mkinitrd-4.1.19-1.
Created attachment 107752 [details] Patch to add support for encrypted root filesystems to mkinitrd Please: NO STABLE SYSTEMS YET! The --authtype option has been removed. This was done so that initrds may be created for encrypted root systems by new-kernel-pkg (no difference in argument signature vs. standard non-encrypted system). Instead of using the --authconfig argument, mkinitrd not automatically determines if the root filesystem is encrypted by looking at /etc/fstab and /etc/crypttab. The "paranoid" authtype is for now the only method supported. This method stores the root filesystem key in the initrd and assumes the initrd is on some type of removable medium.
Created attachment 107778 [details] Patch to add support for encrypted root filesystems to mkinitrd Please: NO STABLE SYSTEMS YET! This version of the patch adds to grubby the ability to detect a system with an encrypted root filesystem. Grubby not notices when the device of the mounted root filesystem != the bootloader's root= configuration. If these two values are not equal, grubby looks for "root XXX..." in /etc/crypttab where XXX equals the device of the mounted root.
One thing you miss in the latest patch is support for an encrypted root device on top of an LVM volume. With your patch the code does the following starting at about line 730 in mkinitrd: if [ "$kernelmajor" == "2.4" ]; then # kernel 2.4.x LVM stufff elif [ -n "$root_enc" ]; then # crypto-root stuff else # kernel 2.6.x LVM stuff fi What you really want is to have the crypto root stuff occurring outside the if statement in question. Also inside the "if [ -n "$root_enc" ]; then" block you want to have "if [ -z $root_lvm ]; then" around the "mkdmnod" bit so that mkdmnod doesn't get called twice. Also in recent kernels the AES module is aes-i586 (maybe we should have an alias in the module-init-tools config).
I'm sorry, but I don't have any experience with LVM volumes. What I do know is that right now if root_enc=1 then root_lvm=1 but root_lvm=1 does NOT mean root_enc=1. The tests go like this (line 852): if [ is LVM (actually is device mapper) ]; then root_lvm=1 if [ is encrypted ]; then root_enc=1 fi fi So, how can I support both of these cases: LVM volume, unencrypted LVM volume encrypted ? I need a way to test if a root filesystem is really an LVM volume and not possibly just a DM/encrypted volume. In other words, how can I ask "is this device mapper volume truly a LVM volume?" Root_enc and root_lvm need to be decoupled. === In my recent kernels, aes is not aes-i586 because my kernel is built for PowerPC. So I imagine an alias from aes to aes-i586 would make i586 more consistent with other architectures.
Created attachment 108173 [details] Patch to add support for encrypted root filesystems to mkinitrd Please: NO STABLE SYSTEMS YET! This version modifies new-kernel-pkg. The change ensures that if a system's root filesystem is /dev/mapper/root and a corresponding entry exists in /etc/crypttab (meaning that / is encrypted), then the REAL device (ie: /dev/hda5) specified in the kernel's "root=" command line argument. Grub's configuration file or /etc/yaboot.conf will contain "root=/dev/hda5" instead of "root=/dev/mapper/root" after a kernel RPM is installed. This is what mkinitrd's initrd expects in the case of an encrypted root filesystem.
Some interesting concepts related to this RFI have been introduced on the hal mailing list. See: http://lists.freedesktop.org/pipermail/hal/2004-December/001423.html
Created attachment 113508 [details] Patch to add support for encrypted root filesystems to mkinitrd Now checks to see if /etc/crypttab exists before doing anything.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
SECURITY ISSUE: I assume this patch uses the standard kernel dm-crypt. However, the developer of loop-aes has argued last year that dm-crypt, in common with its predecessor, is insufficiently secure. Have these security concerns been addressed yet? See http://archives.free.net.ph/message/20040725.114236.8143e157.html (from July 2004) where he claims "...both cryptoloop and dm-crypt use ciphers in insecure and exploitable way." and http://wiki.boum.org/TechStdOut/LinuxCryptoFSBrainStroming for some context.
(In reply to comment #26) > SECURITY ISSUE: Short answer: Yes. Mostly. To summarise, there have traditionally been two long standing security issues with the usage of Linux encrypted block devices. 1) Watermarking attack The use of an Initialisation vector IV based on the sector number leads to watermarking attacks. As of kernel 2.6.10, the kernel contains the ESSIV generation mode. This IV generator should defend against the attack (for new crypto devices which specifically use this IV generator when created only!). Details: It is easily possible to check for the existence of a specially crafted file on the encrypted file system by taking advantage of the fact that an IV based purely on the sector number will change only in the LSB (more specificaly, a single known bit depending on padding scheme) between two consecutive sectors out of any contiguous 3 sectors on the disc. This allows an attacker to feed identical plaintext into CBC mode, generating identical ciphertext. A sequence of identical ciphertexts over the disc can then be used to leak a watermark. See http://clemens.endorphin.org/LinuxHDEncSettings for details on ESSIV. 2) Key management Humans suck at using passwords. Secure cryptographic keys are even worse. The standard way of getting around this fact is to generate a strong random key for the bulk encryption and then protect the key with a (much weaker) password that a human can remember. To help prevent brute force attacks against the password, a combination of salting and stretching is used. Clemens Fruhwirth has created a meta-data format for use with encrypted block devices which does the above. The format is available in his patched version of cryptsetup: http://luks.endorphin.org/ (this should already be in FC. See bug 147313) Using dm-crypt/cryptoloop in a scenario where an attacker can observe/modify encrypted device data (whilst in/between use) is very likely to have insecurities though. To properly support encrypted block devices, I would hope/recommend that: 1) Only support devices with the LUKS meta data. Trying to auto-decrypt/perform magic will only lead to bugs, data loss, and eventual madness. Plus there are already patches in the pipeline for hal/dbus support of LUKS formatted devices (for example, hot plugging of USB keys and having a passphrase dialog pop up). 2) Do NOT use /etc/crypttab, or key files. That is just crack. An encrypted block device with the LUKS meta-data block has a UUID. Use it. To make things friendly for humans make use of devlabel (may require patching). mkinitrd can be made to auto detect the use of dm-crypt via tracing the stack of block devices underneath the root FS (for example, mdadm -D for MD devices, dmsetup deps for LVM/dm-crypt devices). Basically have a list of handlers for all block device types in /proc/devices. I would hope that this would be used in general in order to make mkinitrd more robust against configuration file errors. Key data to only be supplied via user passphrases or from /dev/random (for those who choose to use encrytped swap). Eventually having support for key storage on smartcards/TPM would be cool, but not needed for first version of distribution support, and it is best to not encourage use of plaintext keys sitting in files on the computer. 3) Make sure that any initscripts recursively go through all block device setup routines (MD, LVM, dm-crypt, etc) so as to allow all (sane/insane) device configurations to "just work". Can be easily implemented by having all block device setup scripts reside in a single directory. Iteratively loop over all scripts in directory and only stop once all scripts report no further changes (or a high loop limit is hit (eg 7)).
Thank you for the suggestions in comment #27. I have a question about point number two, "...[the] LUKS meta-data block has a UUID." How would this UUID be used? Currently, if /etc/fstab contains /dev/mapper/root then the parameters to create /dev/mapper/root are looked up in /etc/crypttab. I understand your recommendation of replacing /etc/crypttab with LUKS' meta-data. This is how I would implement this: For every UUID in /etc/fstab, the boot script checks every partition in /proc/partitions for the LUKS UUID. If it exists, then setup the dm-crypt device. Set /dev/root to point to the dm-crypt device. In order to avoid the additional logic in the boot script then util-linux would need to be patched. But this effort seems stalled (see bug #56698) and has been frustrated by the transition from cryptoloop to dm-crypt to LUKS/dm-crypt. I would be interested to hear more specifics about what you envision.
(In reply to comment #28) > I would like to hear more about the concepts that you spoke of. > Specifically, I have a question about point number two, "...[the] LUKS > meta-data block has a UUID." How would this UUID be used? Its main use would be to ensure that the proper LUKS device is "opened" during initrd's linuxrc execution (i.e. scan all block devices in /proc/partitions and check the LUKS UUID against what is recorded in initrd image from mkinitrd). This will ensure that the root device is always constructed properly regardless of how discs change between boots. There isn't much other use for it in the mkinitrd scenario. The name of the dm-crypt device that gets created in linuxrc should be copied from what it was at mkinitrd execution time. On a more general distribution wide usage (e.g. multiple encrypted partitions), there are two naming issues to consider: 1) Persistent name for a block device containing luks meta data. 2) Persistent name for dm-crypt mapped device from (1). For the first version of distribution support, both of these issues can be safely ignored though. I envisage that Anaconda could "open" LUKS devices using the name /dev/mapper/dm-crypt-${UUID}. For any device with a FS, Anaconda can actually just use the FS UUID and forget that the FS is on an encrypted block device, otherwise /etc/fstab can contain: /dev/mapper/dm-crypt-${UUID} /something some_fs_that_has_no_uuid During system initialisation (and after driver setup), the first initscript to run should do all block device setup (via the iterative method mentioned previously and using the default name above for dm-crypt devices). > This is how I would implement this: > > For every UUID in /etc/fstab, the boot script checks every partition in > /proc/partitions for the LUKS UUID. If it exists, then setup the dm-crypt > device. Set /dev/root to point to the dm-crypt device. Are you referring to the initrd boot script, mkinitrd, or rc.sysinit scripts ? /etc/fstab is outside the scope of linuxrc in the initrd. mkinitrd need only consult the fstab for the root FS (and then trace devices needed and also compare against /proc/cmdline and mount table). It can then add all dependent devices to linuxrc. rc.sysinit scripts can ignore the fstab and just scan all partitions and setup all block devices. > In order to avoid the additional logic in the boot script then util-linux > would need to be patched. But this effort seems stalled (see bug #56698) > and has been frustrated by the transition from cryptoloop to dm-crypt to > LUKS/dm-crypt. If all LUKS devices are either setup at boot or as plugged in (via the hal daemon magic), then no util-linux patching is needed. Whilst some people may like to be able to specify: LUKS:f5d62883-2ea0-4dc2-99e7-d58080abb0b2 /backups auto defaults,noauto it is not needed for initial distribution support.
Created attachment 115668 [details] Patch to add support for encrypted root filesystems to mkinitrd This patch uses LUKS to store encryption parameters instead of using /etc/crypttab. I have begun to implement some of the recommendations in recent comments. A variation of the following will prepare a LUKS-encrypted root filesystem: cryptsetup luksFormat /dev/hdaX /etc/root-key cryptsetup -d /etc/root-key luksOpen /dev/hdaX root mkfs.ext3 /dev/mapper/root mount /dev/mapper/root /mnt cp -ax / /mnt At this point, the use of /etc/root-key is hard-coded into mkinitrd. I hope to replace this at some point. Currently, it seems that the init script has trouble reading a passphrase entered manually. I am not yet sure if this is because of limitations of nash or a missing stdin-related device. Until this is figured out, /etc/root-key will exist (encrypted) on / and also unencrypted on the removable boot media.
*** Bug 157301 has been marked as a duplicate of this bug. ***
Created attachment 117763 [details] Utility to provide stdin to cryptsetup in nash. Necessity being the mother of invention... My need to be able to enter a passphrase for the root partition became acute over the weekend and lead to this quick and very dirty C program. It simply closes the sdtin, stdout, and stderr file descriptors and reopens them to the console device. Then, it shifts it's arguments and execs the new argv [0]. I compile it with the following: gcc -Wall console.c -static -static-libgcc -o console My init nash script is as follows: #!/bin/nash mount -t proc /proc /proc setquiet echo Mounted /proc filesystem echo Mounting sysfs mount -t sysfs /sys /sys echo Creating /dev mount -o mode=0755 -t tmpfs /dev /dev mknod /dev/console c 5 1 mknod /dev/null c 1 3 mknod /dev/zero c 1 5 mkdir /dev/pts mkdir /dev/shm mkdir /dev/mapper mknod /dev/mapper/control c 10 63 echo Starting udev /sbin/udevstart echo -n "/sbin/hotplug" > /proc/sys/kernel/hotplug echo "Loading scsi_mod.ko module" insmod /lib/scsi_mod.ko echo "Loading sd_mod.ko module" insmod /lib/sd_mod.ko echo "Loading libata.ko module" insmod /lib/libata.ko echo "Loading ata_piix.ko module" insmod /lib/ata_piix.ko echo "Loading jbd.ko module" insmod /lib/jbd.ko echo "Loading ext3.ko module" insmod /lib/ext3.ko echo "Loading LUKS modules" insmod /lib/dm-mod.ko insmod /lib/dm-crypt.ko insmod /lib/aes-i586.ko /sbin/udevstart echo Creating root device mkrootdev /dev/root /sbin/console /sbin/cryptsetup luksOpen /dev/root root echo Mounting root filesystem mount -o defaults --ro -t ext3 /dev/mapper/root /sysroot echo Switching to new root switchroot --movedev /sysroot It assumes /dev/mapper is setup correctly and the necessary .ko files are included as well as cryptsetup. This has the desired effect of pausing the boot until a passphrase is entered. This is only a proof of concept so use at your own discretion and risk. I consider it public domain so do with it as you will...
I no longer have the time to maintain/promote this patch. Does anyone who is watching this bug wish to take over?
has anyone tested the tool + init-script mentioned in comment #32? I tried it on stock fedora core 3 and it only says at boot time: "EXIT: /sbin/console exited abnormally". When I try something like "./console ls" in a normal shell it works as expected.
I'm using it now in FC4. I have not tested beyond that single install. Did you link it statically?: gcc -Wall console.c -static -static-libgcc -o console
it works now under FC3 :-) 1. I updated nash to 4.2.15 (new mkinitrd rpm of FC 4) + udev to 058-1. The "switchroot" command in FC3 nash doesn't know the option --movedev 2. switchroot doesn't move the devicemapper correctly. In my init nash script it says "/sbin/console /sbin/cryptsetup luksOpen /dev/root root" which creates /dev/mapper/root. The following mount and switchroot works correctly with /dev/mapper/root But the rc script which tries to do an fsck on /dev/mapper/root fails because there is no /dev/mapper/root and drops me to a rescue shell. Instead there is /dev/dm-0 which is the devicemapper entry of the root-partition! I changed the fstab from /dev/mapper/root / ext3 defaults 1 1 to /dev/dm-0 / ext3 defaults 1 1 and now it works fine.
In comment #32, I introduced a simple program I called "console". It is actually unnecessary. Instead, do the following: /sbin/cryptsetup luksOpen /dev/root root < /dev/console > /dev/console echo Mounting root filesystem mount -o defaults --ro -t ext3 /dev/mapper/root /sysroot
Hm, I'd like to see this patch updated for mkinitrd-5.0. I'll do it myself if I can, but don't expect it to be perfect. :)
Created attachment 133932 [details] Patch to add support for encrypted root filesystems to mkinitrd I've found some time to start working on this again. This patch is against mkinitrd-5.1.2-1. The user is now prompted for a passphrase when the system boots. I performed the following steps to create an encrypted root partition after applying this patch: 1. Install Fedora, leaving a spare partition, call it /dev/hda6. 2. cryptsetup luksFormat /dev/hda6 3. cryptsetup luksOpen /dev/hda6 root 4. mkfs.ext3 /dev/mapper/root 5. mount /dev/mapper/root /mnt 6. cp -ax / /mnt 7. Edit /mnt/etc/fstab and change the root filesystem device to /dev/mapper/root 8. mkinitrd --fstab=/mnt/etc/fstab /boot/initrd-enc <kernelversion> 9. Edit yaboot.conf (or GRUB's config), set root to /dev/hda6 and set initrd to /boot/initrd-enc. The patch contains a few comments that contain the text "FIXME." I am hoping to get feedback from the mkinitrd maintainer on two of those comments.
I can't put the encrypted filesystem inside an LVM logical volume? That's going to ruin my day... Anyway, your new patch 133932 applies cleanly to mkinitrd-5.0.32 (%patch -p2 in the spec file) so I'm off to try it out and see what happens on a fresh FC5 box.
It works! My fresh FC5 install asks for the passphrase, decrypts the partition (which I DID put into an LVM LV and that works too) and boots right up. I couldn't login though, probably because I had to do the above steps from an SELinux-disabled live CD (cryptsetup wouldn't work from the FC5 rescue mode). So I touched /.autorelabel and rebooted, and after that everything was good.
Hm, perhaps I spoke too soon. After updating to kernel-2.6.17-2157_FC5 and making a new initrd with the patched mkinitrd, I get the following cryptic error on boot: Reading all physical volumes. This may take a while... Found volume group "VolGroup00" using metadata type lvm2 3 logical volume(s) in volume group "VolGroup00" now active Command failed: Can't get device information. On inspecting grub.conf I found that the root device had been reset to /dev/mapper/root, rather than being preserved as /dev/VolGroup00/LogVol00. Once I changed it back manually, everything works, though this does suggest some further patching is needed. :)
Okay, last comment tonight. I promise. On upgrading the kernel (again to 2174) from yum it appears a script is failing: Installing: kernel ######################### [2/3] Usage: cryptsetup [-?] [-?|--help] [--usage] [-v|--verbose] [-c|--cipher STRING] [-h|--hash STRING] [-y|--verify-passphrase] [-d|--key-file STRING] [-s|--key-size BITS] [-b|--size SECTORS] [-o|--offset SECTORS] [-p|--skip SECTORS] [-r|--readonly] [-i|--iter-time msecs] [-q|--batch-mode] [--version] [-t|--timeout secs] [OPTION...] <action> <action-specific>] cryptsetup: status: requires <name> as arguments When I then run mkinitrd -f /boot/initrd-2.6.17-1.2174_FC5.img 2.6.17-1.2174_FC5 then the initrd is generated correctly and all is well.
Created attachment 134108 [details] Patch to add support for encrypted root filesystems to mkinitrd This should address the issue identified in comment #43.
After the patch in #44, I no longer get the error message on upgrading the kernel, but the generated initrd now gives a bizarre error saying that it can't resume from /dev/mapper/swap (but I don't use suspend to disk!). I still have to run mkinitrd manually after upgrading the kernel.
Created attachment 134534 [details] Patch to add support for encrypted root filesystems to mkinitrd The new-kernel-pkg script no longer uses the findall or vecho functions, which are not available.
Created attachment 134535 [details] Patch to add support for encrypted root filesystems to mkinitrd The new-kernel-pkg script no longer uses the findall or vecho functions, which are not available.
Created attachment 134536 [details] Patch to add support for encrypted root filesystems to mkinitrd The new-kernel-pkg script no longer uses the findall or vecho functions, which are not available.
Created attachment 134537 [details] Patch to add support for encrypted root filesystems to mkinitrd The new-kernel-pkg script no longer uses the findall or vecho functions, which are not available.
Created attachment 134538 [details] Patch to provide encrypted root filesystem support in mkinitrd, updated for mkinitrd-5.1.9 I regret to say the new patch didn't apply cleanly either to mkinitrd-5.0.32 (FC5) or to mkinitrd-5.1.9, (development) so I rebuilt a patch that does apply cleanly, at least to 5.1.9. (A minor change should let it apply cleanly to 5.0.32 as well.) I also regret to say that it's still writing a bad grub.conf entry, setting root=/dev/mapper/root instead of the actual filesystem (in my case, root=/dev/VolGroup00/LogVol00). I changed this manually, but I continue to get the oddball error: Red Hat nash version 5.1.9 starting Unable to access resume device (/dev/mapper/swap) Command failed: Can't get device information. I'm going to try backporting this to mkinitrd-5.0.32 shortly.
Created attachment 135006 [details] Patch to add support for encrypted root filesystems to mkinitrd I think devices such as /dev/VolGroup00/LogVol00 don't work because of my reliance on the get_traditional_devnod shell function in new-kernel-pkg. This function, given /dev/root, looks at the devices major and minor numbers and uses sysfs to determine the traditional, e.x., /dev/hda1, device. I suspect this technique fails for something like dev/VolGroup00/LogVol00. This patch adds a test to make this failure more explicit. I'm not very familiar with volume groups, so I could use some help determining how to handle this case.
Michael Hampton: Some questions about your LVM setup: 1. What device is listed for "/" in /etc/fstab? 2. What does "cryptsetup status $rootdevice" say, where $rootdevice is the device from question one? 3. If the answer to question two is /dev/VolGroup00/LogVol00, then stop. Else, can you provide a command that takes the answer to question two as input and prints /dev/VolGroup00/LogVol00? Right now my code looks up the "real" name for /dev/root by using sysfs. But I don't think this works for LVM.
1. /dev/mapper/root / ext3 defaults 1 1 2. # cryptsetup status root /dev/mapper/root is active: cipher: aes-cbc-plain keysize: 128 bits device: /dev/root offset: 1032 sectors size: 42865656 sectors mode: read/write # cryptsetup --version cryptsetup-luks 1.0.3-rc2 3. Hm, I can't think of any way right now to get from /dev/mapper/root back to /dev/VolGroup00/LogVol00.
Created attachment 135462 [details] Patch to add support for encrypted root filesystems to mkinitrd This patch adds support for encrypted logical volumes. In order to use an encrypted logical volume, perform the following steps: 1. Install Fedora, leaving a spare logical volume, call it /dev/VolGroup01/LogVol00. 2. cryptsetup luksFormat /dev/VolGroup01/LogVol00 3. cryptsetup luksOpen /dev/VolGroup01/LogVol00 root 4. mkfs.ext3 /dev/mapper/root 5. mount /dev/mapper/root /mnt/ 6. cp -ax / /mnt 7. Edit /mnt/etc/fstab and change the root filesystem device to /dev/mapper/root 8. mkinitrd --fstab=/mnt/etc/fstab /boot/initrd-enc <kernelversion> 9. Edit yaboot.conf (or GRUB's config), set root to /dev/VolGroup01/LogVol00 and set initrd to /boot/initrd-enc.
Created attachment 135894 [details] Patch to add support for encrypted root filesystems to mkinitrd Please note that new-kernel-pkg will fail when RPM attempts to upgrade a kernel while SELinux is enforcing its policy. Please ** turn off SELinix ** before trying to test this patch's upgrade functionality. I will look into this SELinux issue after more testing. Please help test: 1. Creating a new encrypted root partition (see instructions in previous comment.) 2. Upgrading a kernel using RPM (new-kernel-pkg should properly create an initrd and update /etc/yaboot.conf.) Both of these operations should work with physical or logical volumes.
Installing: kernel ######################### [1/1] Found backing device /dev/VolGroup00/LogVol00 (dm-1) for /dev/mapper/root The latest patch (135894) creates a perfectly workable initrd and I can finally boot kernel 2.6.17-2174 from it! It does print out a whole list of devices just before asking for the passphrase though. It also works with the latest mkinitrd (5.1.15) with %patch -p1 in the spec file. I regret to say that when I installed the kernel I forgot to turn off SELinux, and so grubby failed with a Floating point exception.
Created attachment 136049 [details] Patch to add support for encrypted root filesystems to mkinitrd This patch has the following improvements over the previous one: 1. Consolidated code that creates dm control device to avoid code duplication. 2. Removed debug statements mentioned in the previous comment. 3. Added ability to store a key on a removable device. This is the technique I used to use before adding support for keyboard input. The key and initrd are placed on a removable device (e.g., thumb drive.) This allows the key to be a random number with maximum entropy for the keyspace. The removable device needs to be protected. This technique is used if /etc/root-key exists on an encrypted root device. I need to test this.
I just tested the "key on removable device" feature. It seems to work. This allows one to have a key with maximum entropy on a removable device. The removable device must be physically protected like a house key. Again, the existance of /etc/root-key causes mkinitrd to use this technique. See [1] for more information. Here are the steps for installing boot files and a key on a USB flash drive: First, prepare the encrypted root filesystem. 1. Create a key: dd if=/dev/urandom of=/etc/root-key bs=1c count=32 2. LUKS Format: cat /etc/root-key | cryptsetup luksFormat /dev/hdaX 3. Setup crypto: cryptsetup -d /etc/root-key luksOpen /dev/hdaX root 4. Create FS: mkfs.ext3 /dev/mapper/root 5. Mount: /dev/mapper/root /mnt 6. Populate: cp -ax / /mnt NOTE: temporarily storing /etc/root-key on an unencrypted filesystem is not safe UNLESS the partition hosting it is randomized after creating the encrypted filesystem. Now, install the boot system onto the USB flask disk. This example is for a PowerPC-based computer that uses OpenFirmware. 1. Determine OpenFirmware path to USB flash disk (see [1].) 2. Set up partition table: parted /dev/sda (parted) mklabel mac (parted) mkpart primary hfs 0.031 62.500 (parted) set 2 boot on (parted) name 2 Apple_Boot (parted) quit 3. Create FS: hformat /dev/sdaX 4. Configure /mnt/etc/yaboot.conf, based on the following example: boot=/dev/sdaX ofboot=/pci@f2000000/usb@1b,1/disk@1:2 partition=X install=/usr/lib/yaboot/yaboot magicboot=/usr/lib/yaboot/ofboot default=linux image=/vmlinux label=linux root=/dev/hdaX initrd=/initrd.gz read-only 5. Install bootstrap files and kernel to /dev/sdaX: ybin --config /mnt/encroot/etc/yaboot.conf -v mount /dev/sda2 /media cp /boot/<Linux kernel> /media 6. Edit /mnt/etc/fstab, setting the root filesystem to /dev/mapper/root. 7. mkinitrd --fstab=/mnt/etc/fstab /media/initrd-enc <Linux kernel version> 8. umount /media [1] http://www.linuxjournal.com/article/7743
The latest patch fails on mkinitrd-5.1.19-1 on Fedora Core 6. It says I'm not using LUKS, when I am. This is the same system I've been using all along! root@roam ~ # mkinitrd -v -f /boot/initrd-2.6.18-1.2798.fc6.img 2.6.18-1.2798.fc6 Creating initramfs Looking for deps of module uhci-hcd Looking for deps of module ohci-hcd Looking for deps of module ehci-hcd Looking for deps of module ext3: jbd Looking for deps of module jbd Found backing device for /dev/mapper/root Encryption on /dev/mapper/root does not use LUKS, aborting.
Do the two recent dependencies added to this bug (marked as security issues, so I can't see their contents) imply that Red Hat may be interested in implementing this feature?
I suspect the addition of FC7Target implies that Red Hat may be interested in implementing this feature. :)
Created attachment 141591 [details] Patch to add support for encrypted root filesystems to mkinitrd This patch applies cleanly to mkinitrd-5.1.19. It works fine with a "traditional" block device (e.x., /dev/hdaX). It also supports booting from removable media with a strong encryption key (see comment #58). But... Booting from volume groups is again broken. This is because a device node like /dev/dm-1 is not longer created when a volume group is set up. This device node is used, along with sysfs, to determine the backing device for an encrypted volume group. Could someone tell me why /dev/dm-X is no longer created for device mapper devices? What component had this responsibility before? Everything works fine if /dev/dm-X is created by hand using mknod before mkinitrd is run.
It seems to me that if you have a dm-?? device you could just skip /dev entirely and go directly to sysfs and walk backward through there; it appears that everything you need can be pulled out of there. You'd have to rewrite or replace the get_logvol_devnod function though. (This might have pitfalls I'm not aware of, though.) Here's an example: root@underground ~ # dmsetup list --tree [...snip...] vol1 (253:4) `-VolGroup01-LogVol00 (253:3) `- (8:17) root@underground ~ # cat /sys/block/dm-4/dev 253:4 root@underground ~ # ls /sys/block/dm-4/slaves dm-3 root@underground ~ # cat /sys/block/dm-3/dev 253:3 root@underground ~ # ls /sys/block/dm-3/slaves sdb1 root@underground ~ # cat /sys/block/sdb/sdb1/dev 8:17
This lack of /dev/dm-? nodes affects other components. See bug #216538.
Oh, so that explains why my encrypted USB stick doesn't mount! I reported that as bug 213601.
Er, that should be bug 213801. Sorry.
This should fix the problem mentioned in comment #62: Comment out "KERNEL=="dm-[0-9]*", OPTIONS+="ignore_device"" in /etc/udev/rules.d/50-udev.rules. I am not sure why udev has this rule.
Created attachment 143860 [details] Simple program to query password from user and store it to a file Good, somebody else is working on this too. I would really like to see an official solution in FC. This should also include support in installer/rescue mode, ie. you could directly install on an encrypted partition without having to use a temporary partition. Here is a little bit from my very simplistic approach used with FC6: a simple program which reads a password from the console and stores it to /luks_password. This file can then be used to open all other partitions in initrd, i.e. the user can use a single password (PointSec-like): luks_password echo Unlocking swap device. cryptsetup -d /luks_password luksOpen /dev/VolGroup00/LogVol01 encrypted_swap resume /dev/mapper/encrypted_swap echo Unlocking root device. cryptsetup -d /luks_password luksOpen /dev/VolGroup00/LogVol00 encrypted_root rootdev=mapper/encrypted_root echo Unlocking home device. cryptsetup -d /luks_password luksOpen /dev/VolGroup00/LogVol02 encrypted_home The file is in the initrd root, i.e. it will disappear when the root is switched. This is probably not really secure and the initrd memory should be wiped after root switch to destroy any traces of the password. BTW: I've successfully tested hibernate & resume using an encrypted swap partition. So it would be nice if the final solution would include a password for a swap partition too, not only the usually suggested solution with a random password & mkswap at every boot.
Created attachment 144351 [details] Patch to add support for encrypted root filesystems to mkinitrd I had the same issues as in comment #62, and while Michael in comment #67 mentions a feasible workaround, the block device necessary to boot is available even without the dm device file. My concern was that a future install of udev would overwrite commenting the rule change, so I've updated the patch to work in the scenario where the user has a stock FC6 install (Logical Volume root partition and the udev rules intact). The update basically does: 1) Check to see if the /dev/dm-# device exists and is a valid block device. If yes then proceed with the normal method. 2) If no then check to see if the crypto device is a valid block device and if so try to use it to derive the necessary boot info instead. I believe this should be backwards compatible with other setups, but would appreciate someone validating this approach. In the mean time this worked for me in a FC6 kernel upgrade test and using mkinitrd manually.
Is there a task list for this, that I could look at for things to help out with? I would like to see this get into FC7 (or whatever it will be called).
Created attachment 147835 [details] Patch to add encrypted root fs support to mkinitrd w/modular CBC This is a modification of Wesley Wright's patch from Comment #69. Following Michael Hamptons procedure at http://linux.ioerror.us/2006/09/encrypting-your-root-partition-on-fedora-core-5/ and using these bugzilla comments as a guide, I discovered two things: 1. The latest kernel for FC6 (2.6.19-1.2895.fc6) has the CBC support built as modules. I had to add "findmodule -blkcipher" and "findmodule -cbc" to the mkinitrd patch in comment #67 to get a "aes-cbc-essiv:sha256" LUKS device to work from the initrd environment. The attached patch file has the simple change. 2. When working from a chroot'ed environment from a Gentoo minimal Live CD, per Michael Hampton's blueprint, I had to force mkinitrd to include lvm support (added "vg_list=VolGroup00" at line 1168 in mkinitrd temporarily), because the lvm tools didn't think any LV's existed in the chroot'ed environment and mkinitrd wouldn't include lvm support. Here's how I ran mkinitrd in the chroot environment to force lvm support: chroot /mnt/disk1 mount -t proc proc /proc mount -t sysfs sysfs /sys dmsetup mknodes vi /etc/fstab (change /dev/VolGroup00/LogVol00 to /dev/mapper/root) vi /sbin/mkinitrd (add vg_list=VolGroup00 at line 1168) mkinitrd -v -f /boot/initrd-2.6.19-1.2895.fc6.img 2.6.19-1.2895.fc6 vi /sbin/mkinitrd (comment out vg_list=VolGroup00 at line 1168) umount /sys umount /proc exit The patch does not address lvm and running mkinitrd in a chroot environment.
Oops. There's a typo above. Both comment refernces should be to commnet #69.
Created attachment 148297 [details] Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC This is a modification of my patch from Comment #72. 1. Since a. an encrypted root does not offer complete protection of data at rest without an encrypted swap, and since b. laptop users are most likely to need both protection of data at rest and suspend to disk functionality, this patch to mkinitrd provides support for a LUKS formated encrypted swap volume with the ability to resume from a suspend that wrote the machine state to the encrypted swap volume. It does require one to enter two passwords at bootup when not resuming. (Comment #68 discussed a possible one password solution that is not in this patch for those willing to make the required security trade-offs.) The changes are simply a modification of what was done for encrypted root, except the swap partition's name is not constarined to "/dev/mapper/swap". It could be "/dev/mapper/foobar" if you like, but /dev/mapper/VolGroup00-LogVol01, the name of the backing volume, would obviously be a bad choice... 2. When working from a chroot'ed environment from a Gentoo minimal Live CD, per Michael Hampton's blueprint, but creating encrypted swap as well as an encrypted root, I still had to force mkinitrd to include lvm support (added "vg_list=VolGroup00" at line 1210 in mkinitrd temporarily), because the lvm tools didn't think any LV's existed in the chroot'ed environment and mkinitrd wouldn't include lvm support. Here's how I ran mkinitrd in the chroot environment to force lvm support: chroot /mnt/disk1 mount -t proc proc /proc mount -t sysfs sysfs /sys dmsetup mknodes ln -s /dev/mapper/VolGroup00-LogVol01 /dev/VolGroup00/LogVol01 vi /etc/fstab (change /dev/VolGroup00/LogVol00 to /dev/mapper/root and /dev/VolGroup00/LogVol01 to /dev/mapper/swap) vi /sbin/mkinitrd (add vg_list=VolGroup00 at line 1210) mkinitrd -v -f /boot/initrd-2.6.19-1.2895.fc6.img 2.6.19-1.2895.fc6 vi /sbin/mkinitrd (comment out vg_list=VolGroup00 at line 1210) umount /sys umount /proc exit The patch does not address lvm and running mkinitrd in a chroot environment.
my work around for the more then 1 volume / partition to save having to re-enter passwords is a small partition (i called vault) that is encrypted and stores keyfiles for unlocking root/swap/home etc etc I have not yet managed to inplement this under fedora as I only started using Fedora a few weeks ago after using Gentoo in the past I doubt this could be easy to add to the automagical mkinitrd method. but for the manual method may save time
I've successfully applied this patch to RHEL 5, and in the latest Fedora Core 6 as well. Maybe it's time to roll it in?
Michael, would you be able to provide some steps for how you applied this to RHEL5? I would like to roll this out to some of the laptops I have within the DoD space, at least for protecting /home.
Eh? You don't need this patch for encrypting non-root partitions. Just set them up normally. But the basic process I use is this: * Download the mkinitrd SRPM * Edit the spec file, adding in the latest patch * Rebuild the RPMs from the spec file * Install the new RPMs To actually install a system, since anaconda doesn't yet support encrypted partitions, I get a scratch hard drive gathering dust somewhere, install fresh over whatever was on it, including the patched RPMs from above, and then boot from a rescue CD (usually Gentoo) and transfer the freshly installed system onto the encrypted drive. Then I chroot into the encrypted disk and run mkinitrd manually (the first time). When later kernel updates come through, mkinitrd will do the right thing. See also bug 211247. Red Hat is going to need some encouragement from its customers for this feature.
Created attachment 154948 [details] Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 This patch is a slightly modified version of the patch from Comment #74. It adds encryption support for encrypted root and swap devices to the mkinitrd that comes with Fedora 7. I have tested this with my machine and it works just fine. I wrote a small HOWTO based on Michael's describing how this can be done just with the Fedora media and without the Gentoo mini CD. The Gentoo media don't work on x86_64 as there is not matching media for this system. You can find it at http://www.niemueller.de/wiki/?Fedora7WithCryptoRootNSwap. Suspend2disk to the encrypted swap partition works like a charm. I hope this will finally make it into F8 and with support in anaconda.
Created attachment 155547 [details] Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 Fixes inst call for swap device. Eliminates a small error (which didn't prevent the former patch from working, though). Is there a chance that we see this included at some point (in the near future)? Has someone tested this on a machine without root encryption to see if it interferes somehow. If it does not it should be save to put this patch into the package, even without support in the installer but accompanied with a useful HOWTO for now. I just had the problem that my mkinitrd was updated from the repo and then installing new kernels would not work anymore...
Created attachment 155901 [details] Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 This is a patch similar to the 155547 (comment #80), but can handle all lvm volumes, not only those created by anaconda which are named VolGroup?? It also adds a check if sbackingdev really is a Linux Swap partition before it bails out
Patch 155901 is still misidentifying the swap partition as the one on which it should operate, at least on my system. Once I commented the swap out of /etc/fstab, then it picked up the correct root partition.
I don't think the configuration below is supported by the current patch - I've attempted to set it up and it doesn't work; if it should do I can try again, obviously. I'm looking to encrypt the physical volume upon which the volume group is created, which in turn contains the logical volumes used for /, swap, and everything else on the laptop. Only /boot is unencrypted. On boot, I would enter one password for the luks partition, after which the lvm volumes are found and the system boots. e.g. a "stack" of devices, going down from a filesystem, is: / (ext3) /dev/mapper/vg0-lv_root (lv) /dev/mapper/vg0 (vg) /dev/mapper/pv0_crypt (luks encrypted pv) /dev/sdb2 This is the sort of setup I need: http://gentoo-wiki.com/SECURITY_LVM_and_EVMS_over_cryptsetup-LUKS It seems like a sensible way to set things up for a laptop - more sensible than entering a LUKS passphrase for each partition, swap etc.
re: comment #83 If I understand correctly, you'd like to have to type just one LUKS password and set up the other encrypted filesystems automatically via passwords in files ? That is supposed to work. Just put the key files on the root filesystem and reference them in /etc/crypttab (the third parameter). Just make sure to leave the third parameter of the root FS as 'none'
Not really: ideally I'd like to encrypt a single device, upon which all the filesystems I use (via LVM) are built. e.g. 1) partition laptop with /dev/sda1 (small, unenrypted, for /boot) and /dev/sda2 2) use LUKS to encryt /dev/sda2, which appears when decrypted as /dev/mapper/crypt_device 3) use /dev/mapper/crypt_device as the physical volume from which my primary LVM volume group (e.g. /dev/mapper/vg0) is built 4) create logical volumes for filesystem partitions from vg0, as per usual When you start the machine, /boot is unencrypted, initrd bootstraps, asks you for one LUKS passphrase which decrypts /dev/sda2, and off you go. LVM handles everything from /dev/mapper/crypt_device up. Caveat: I actually tried this on a _second_ internal hard drive in a laptop, i.e. /dev/sdb rather than /dev/sda. Clearly this shouldn't make a difference, but I'm unable to mess with /dev/sda to test. The motivation / use-case: it's all about the balance of intrusiveness vs. performance vs. security. On my workstation I may want to encrypt just /tmp, swap, /home/XXX (and use pam_mount), not least because I want the machine to be able to reboot unattended. On my laptop, I'm much more paranoid about loss of the physical machine, so I put a higher value on encrypting the _entire_ hard drive; but at the same time I'm always at the console when it boots, so entering a passphrase early in the boot process isn't a problem; and there aren't multiple users to worry about passphrase management. It's this latter scenario I'm interested in; I want to encrypt the entire drive, so I don't want the hassle of maintaining LUKS passphrases for separate partition/filesystems (and associated maintenance overheads when it comes to resizing partitions, etc.). I suspect I could solve this with multiple partitions, but as far as I can see the only thing preventing an encrypted LVM PV is the initrd (see the gentoo link). When building a laptop from scratch, this seems like the obvious way to do it. (I can see why you'd want to deal with partitions if "upgrading" a machine to LUKS). (For the truly paranoid, I encrypting the PV rather than each LV will also hide "secondary" data, such as volume information - metadata, partition sizes, etc.)
Created attachment 159957 [details] Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 Patch fixes a bug in mkinitrd.get_traditional_devnod() - there needs to be an additional for loop to step through all the possible logical volumes in each of $vgdevices (there might be a shorter way of doing this with some bash expansion/braces foo, but I'm no bash expert!). Also now patched against mkinitrd-6.0.9-7.1 (This doesn't address the requirements I mentioned in my previous comments)
Comment on attachment 159957 [details] Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 Scratch that - definitely not a bash expert! There's a problem there, but that patch still isn't right.
Comment on attachment 159957 [details] Patch to add encrypted swap and root fs support to mkinitrd w/modular CBC on F7 Apologies for the flip flop - I think it's ok after all. I'm seeing a similar symptom but for different reasons, it would seem.
Peter, can we get this patch into F8 , please ? This would help us to get everyone at the same level and go on from there...
It would be great if this could be added to mkinitrd before F8 freeze. After three years of usage it should be possible to have it at least in there for people like us keen to test and use this. Since I use crypto root support I feel a lot better traveling with my laptop. Having a crypted backup at home/office makes a loss of a laptop a matter of just the material... Even if there is no support in Anaconda to use the crypto support, there could be a "do it and risk it" entry in the wiki for the brave. Having this in F8 would give us a base for further development.
Created attachment 161831 [details] Patch to add encrypted swap and root fs support, also with encrypted PV Firstly, my bugfix in comment #88 is correct and neccesary. The bug was actually in get_logvol_devnod(), not get_traditional_devnod(), which probably explains my confusion last month. Ahem. Secondly, the attached patch adds functionality for an encrypted Physical Volume, as descibed in my scenario of comment #85. e.g. you boot your laptop and enter a passphrase to unlock a large partition. This partition forms the Physical Volume for an LVM Volume Group, which in turn contains Logical Volumes for root, swap, etc. The patch includes the most up to date previous patch, and my earlier bugfix.
Created attachment 161832 [details] Additions for encrypted Physical Volumes For easier comparison and review of my changes, I'm attaching a diff between mkinitrd patched with the previous version of the patch and mkinitrd with the complete newer encrypted PV patch.
Created attachment 161909 [details] Patch to add encrypted swap and root fs support, also with encrypted PV An update to my previous patch. Bugfixes: 1) fixes careless use of echo rather than vecho. 2) when booting from LiveCD, lvdisplay returns /dev/dm-X over /dev/mapper/*, so added get_mapper_dev() and associated checks. See comment #91 for more details.
Created attachment 161910 [details] Diff between previous patch and current patch with encrypted PV As per comment #92, a diff between the old version of the patch and my latest patch with encrypted PV (I'll just attach full patches in the future, so this gives a good overview of the extra code needed to support encrypted PVs).
Created attachment 161912 [details] HOWTO: Creating an encrypted Physical Volume using Fedora and patched mkinitrd By following the attached HOWTO with a mkinitrd package patched according to comment #93 I successfully installed - and am running - a copy of Fedora 7 on an encrypted Physical Volume. The Volume Group built from the encrypted PV then contains Logical Volumes for my root directory and swap. A second hard drive or partition is required to use this method. Since Fedora, by default, installs the root directory and swap to a single Volume Group, it should also be possible to adapt this method to (relatively!) easily convert a non-encrypted install to an encrypted one (i.e. to pvmove the existing install to a temporary PV, then encrypt the original PV before moving the installation back).
Questions: 1) In step 10 of the attached HOWTO, above, I populate the /dev directory of the chroot environment by copying the /dev entries from the running /dev. Is there a better way to do this? (I tried using start_udev, but it didn't seem to pick up everything needed from LVM and the crypt devices). 2) I think there's a bug in the patched version of grubby. isRootEnc() segfaults for me with the encrypted PV setup described above, HOWEVER it also segfaults in the same way when built and tested on a machine without any encrypted partitions. On this PC root is just an LVM Logical Volume (albeit with the PV on a RAID1 partition, e.g. /dev/md0). I suspect it may do this on all "standard" Fedora installs (i.e. root on VolGroup00/LogVol00), though LVM-on-RAID is a common enough setup for this to be a problem if this is going into F8! (Obviously this only happens on a kernel install; manual runs of mkinitrd are fine) It segfaults on the: strcomp(target_type, CRYPT_TARGET) just after: next = dm_get_next_target(dmt, next, &start, &length, &target_type, ¶ms); I haven't looked in details a what's going on here, but I suspect there may be an assumption that all device mapper devices that got this far are crypt devices , when they could be LVM, RAID, whatever. I don't think this is the selinux incompatibility mentioned earlier - at least, it still occurs with selinux set to permissive (does the selinux problem still exist in F7?). I don't really know what's going on inside grubby, so perhaps the author of that part of the patch could take a look?
Bug in comment #96 confirmed: # rpm -ivvh kernel-2.6.22.1-41.fc7.i686.rpm ... + /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel + /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.22.1-41.fc7 end_request: I/O error, dev fd0, sector 0 /sbin/new-kernel-pkg: line 121: 30109 Segmentation fault $grubby --add-kernel=$bootPrefix/$kernelName-$version $INITRD --copy-default $makedefault --title "$title" ${mbkernel:+--add-multiboot="$mbkernel"} ${mbargs:+--mbargs="$mbargs"} --args="root=$rootdevice $kernargs" --remove-kernel="TITLE=$title" (I think the "end_request: I/O error, dev fd0, sector 0" is harmless - it certainly occurs well away from the segfault?) This is on a clean F7 installation, accepting all the defaults. No RAID, no crypt, root on VolGroup00/LogVol00 and swap on VolGroup00/LogVol01. Only non-standard thing is the patched mkinited RPM. I presume this patch still works on F7 for folks with crypt on Logival Volumes or straight block devices? However much I really, really, want to see this patch go into F8, I think this bug is probably a showstopper - it breaks kernel updates for everyone without encrypted root.
N.B. root-on-encrypted-PV doesn't require a patched grubby; if you delete the part of the patch which modifies grubby, kernel updates work fine. I'd be interested to hear how anyone else gets on with an encrypted PV - it would seem to be a more elegant solution than multiple encrypted LVs, particularly for laptops. As far as getting this patch into Fedora, this bugzilla pre-dates this wiki page: http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems which mentions this bug and other discussion. I also hadn't seen the various discussions on fedora-devel-list - it's pretty obvious from these that this patch isn't going to be accepted anytime soon. Amongst other things, there's resistance to encrypting _any_ block devices which require password entry on boot due to locale and keyboard mapping problems (i.e. a lack of i18n). (Personally I see the merit in these reservations, but having had a laptop stolen I know from experience that potential theft of data is more of a worry than the inconvenience and cost of loosing the hardware - so anything is better than nothing, and the sooner the better. Oh well.)
(In reply to comment #98) > Amongst other things, there's resistance to encrypting _any_ block devices which > require password entry on boot due to locale and keyboard mapping problems (i.e. > a lack of i18n). There is already support for using encrypted filesystems and afaik encrypted lvm devices that require a password entry on boot with /etc/crypttab. So imho this should not block adding support for the root filesystem, too. And how is this problem solved for bootloader (grub) passwords? Maybe this solution can be used here, too. Or is there no solution, too?
Till: absolutely. And while I can see both sides of the argument, my personal needs would obviously be best served by inclusion of the patch. I just thought it might be useful to reference these discussions as I suspect others, like me, didn't realise they'd happened. e.g. https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02030.html
Please also see http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems.
Ray Strode has been contemplating using icons instead of text to prompt for an encryption key. See http://fedoraproject.org/wiki/Releases/FeatureBetterStartup. The "Graphical Boot Sequence" effort may allow this and it might get around the internationalization issue.
David Lehman has written an initial attempt at support for creating LUKS-encrypted partitions at install time. See https://www.redhat.com/archives/anaconda-devel-list/2007-November/msg00066.html.
Created attachment 255221 [details] Patch to add support for encrypted root filesystems to mkinitrd I did my best to collect all of the open patches into one. I also ensured that the new patch will apply against mkinitrd 6.0.19 (Fedora 8). I have not yet tested this code, other than verifying that it applies cleanly. The number of open patches has become confusing. In the future, please obsolete previous patches when a new one is proposed. Also, ensure that you submit clear comments documenting what is changed by the new patch. I appologize if I have dropped a feature implemented in the last few patches. If this is the case, then submit a new patch that returns the dropped feature and obsolete this patch.
I've tested the patch from comment #104 on a fresh Fedora 8 install, creating an encrypted LVM Physical Volume as per comment #95. This works fine, except the error I reported in comment #96 and comment #97 still stands: # rpm -ivvh kernel-2.6.23.1-49.fc8.i686.rpm ... D: install: %post(kernel-2.6.23.1-49.fc8.i686) asynchronous scriptlet start D: install: %post(kernel-2.6.23.1-49.fc8.i686) execv(/bin/sh) pid 2971 ++ uname -i ++ uname -i + '[' i386 == x86_64 -o i386 == i386 ']' + '[' -f /etc/sysconfig/kernel ']' + /bin/sed -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel + /sbin/new-kernel-pkg --package kernel --mkinitrd --depmod --install 2.6.23.1-49.fc8 grubby recieved SIGSEGV! Backtrace (7): /sbin/grubby[0x804b18f] [0x110420] /sbin/grubby[0x804c8d2] /sbin/grubby[0x804c952] /sbin/grubby[0x804f019] /lib/libc.so.6(__libc_start_main+0xe0)[0x811390] /sbin/grubby[0x80493f1] D: install: waitpid(2971) rc 2971 status 0 secs 16.353 D: opening db index /var/lib/rpm/Triggername create mode=0x42 D: running post-transaction scripts D: closed db index /var/lib/rpm/Filemd5s D: closed db index /var/lib/rpm/Sha1header D: closed db index /var/lib/rpm/Sigmd5 D: closed db index /var/lib/rpm/Installtid D: closed db index /var/lib/rpm/Provideversion D: closed db index /var/lib/rpm/Requireversion D: closed db index /var/lib/rpm/Dirnames D: closed db index /var/lib/rpm/Triggername D: closed db index /var/lib/rpm/Conflictname D: closed db index /var/lib/rpm/Providename D: closed db index /var/lib/rpm/Requirename D: closed db index /var/lib/rpm/Group D: closed db index /var/lib/rpm/Basenames D: closed db index /var/lib/rpm/Name D: closed db index /var/lib/rpm/Packages D: closed db environment /var/lib/rpm/Packages D: May free Score board((nil)) # For an encrypted PV the grubby patch isn't required - if I drop it and rebuild the mkinitrd package everything works great, including suspend to disk to a LV based on the encrypted PV. As I mentioned in earlier comments, I'm not familiar enough with what the grubby patch is doing - could the original author take a look? I believe this problem will break kernel updates for ANY user who DOESN'T have encrypted LVs.
I just installed a new kernel on a PowerPC system with an encrypted root (directly on a partition). I did not encounter the crash mentioned in comment #105. In fact, everything worked fine. I am using the patch from comment #104. Has anyone else seen the crash Kevin mentioned? I have not tried LVM yet. I will have to recreate my root filesystem.
Mike: just to be clear, does your system have either any LVM or RAID? If it does, is the encrypted root filesystem in any way "on" either of these? If you don't have any LVM or RAID, but do have an encrypted partition, I wouldn't expect you to experience the bug - see comment #96. The crasher issue is that a default Fedora install _does_ use LVM (without encryption); i.e. if this patch were included as is it would break kernel updates on default Fedora installs (which will have LVM, but won't have encryption). It would also be useful to know what your encrypted root filesystem is built upon: 1) directly on a LUKS partition 2) on a LUKS encrypted Logical Volume 3) on Logical Volume within a LUKS encrupted Physical Volume I'm guessing 1)? Do others with 2) or 3) experience the crash? P.S. I think that, when I attached patches, I could only obsolete my own previous patches but not those of others. I guess that as reporter you have more perms?
Okay, I just installed Fedora on a unencrypted LVM volume. I did see the crash Kevin mentioned when I did a "rpm -ivvh kernel && rpm -evv kernel," although the crash was on the uninstall not the install. However, when I recompiled mkinitrd to retest, I could no longer get grubby to segfault. Kevin, have you built and tested the latest patch on Fedora 8?
As per comment #105, I have tested (and am using) an encrypted PV on a clean Fedora 8 install with the latest patch. I have not tested with with a plain unencrypted install. Note that when the error occurs with a kernel RPM the RPM installation itself completes - the kernel files are installed and the RPM database updated - the only part that fails (with crash) is the post-install scriptlet updating of grub.conf, which is the part that grubby does. Mike: does the stack trace show your crash occured in grubby? It looks like you committed the original patch to grubby (comment #19 ?). Can you confirm that the grubby patch is designed to deal with root being on a dm device other than an encrypted device? It looks like your isRootEnc() function might get tripped up by this - in particular that it gets to, and calls dm_get_next_target() when root is on an LV that is not an encryped device? I'll examine in more detail if you think it should work.
I think the crash was happening in grubby in the isRootEnc function. However, by gdb backtrace was not quite right, due to PowerPC compiler optimization, I think. When I tried to recompile, the crash went away. If it is in fact the strcmp call in isRootEnc, then I can't see what would cause the crash. The first parameter is checked to by non-NULL before the strcmp call and the second is a constant string. I wrote the isRootEnc function to handle non-encrypted dm devices. I may have made a mistake, but I did try to handle all cases. I'm not a dm-API expert by any means. The frustrating this is, again, that since I recompiled (even the same source code), I have not been able to reproduce the crash.
(In reply to comment #110) > The frustrating this is, again, that since I recompiled (even the same source > code), I have not been able to reproduce the crash. That is strange - have you removed the kernel RPM and reverted grub.conf? I know I wasn't consistently getting the crash due to grubby behaving differently due to different grub.conf contents - it gets munged quite a lot testing this stuff! In some cases I was generating incomplete grub.conf entries. (I don't have the source in front of me so I can't see what dm_get_next_target is doing, but I guess the first parameter must be a non-null but invalid pointer? It's not initialised to null, I see)
Created attachment 269101 [details] Patch to add support for encrypted root filesystems to mkinitrd This patch now sets target_type to NULL before dm_get_next_target is called. This should ensure that it is a valid pointer in addition to the non-NULL check before passing it to strcmp. Does this fix the problem?
Yes, that works for me on my test machine with an encrypted PV. I haven't tried a clean F8 install with LVM without any encryption, though I suspect it will fix the problem there too.
Folks, you did a great job. You just forgot to mention, that SELinux has to be set to permissive on the Live CD. You also forgot to tell, that if you're not using LVM, the entries in /etc/fstab have to be adjusted to e.g. /dev/mapper/root and /dev/mapper/swap before re-creating the initrd. As I definately want to see this feature in Fedora 9, I'm marking this as blocker bug therefore. We're early enough in the process to get this into the release.
The supplied patch for me does not work for me. I have a system which I installed with Fedora 7 and crypto root with LVM on the PV and two encrypted partitions inside the VG as LV. The problem occurs in get_logvol_devnod() around line 209 (I patched my file to find the bug so I don't have the exact number). The line reads: [ "$mapperdev" = "$(ls -l $device | awk '{ print $10 }')" ] && logvol=$device In my case ls -l /dev/VolGroup00/LogVol00 gives: lrwxrwxrwx 1 root root 31 7. Dez 12:44 /dev/VolGroup00/LogVol00 -> /dev/mapper/VolGroup00-LogVol00 We see two things here: 1.) the string depends on LANG, so LANG should be set to C to have reproducible results for all system languages. And 2.) there is -> at position 10, even with LANG=C. So it is in fact $11. Do you get different output without "->"? If not it might be an idea to use ls -l $device | awk -F"-> " '{print $2}' such that it does not matter how many entries we have, we just make sure that we get what it points to.
# ls -l /dev/VolGroup00/LogVol01 lrwxrwxrwx 1 root root 31 2007-12-08 23:42 /dev/VolGroup00/LogVol01 -> /dev/mapper/VolGroup00-LogVol01 10th index, LANG=en_US.iso88591. # LANG=C ls -l /dev/VolGroup00/LogVol01 lrwxrwxrwx 1 root root 31 Dec 8 23:42 /dev/VolGroup00/LogVol01 -> /dev/mapper/VolGroup00-LogVol01 11th index, LANG=C.
Created attachment 289833 [details] Patch to add support for encrypted root filesystems to mkinitrd Tim, can you please test whether the patch now works for you? I included your suggestion of the use of awk. I just had to change the quoting a bit.
The patch works fine for me. I have successfully installed and booted a new kernel. I have uploaded (S)RPMs to http://fedorapeople.org/~timn/.
Using the RPMs from comment 118, I successfully resumed from a LUKS-encrypted swap partition with cipher aes-lrw-benbi, but I needed to add "findmodule -lrw" to the lists of encryption modules in mkinitrd so that the kernel could handle the cipher.
Apart from the grubby issue described in an earlier comment, this patch has been working well for me.
Most of this functionality has been implemented in anaconda / mkinitrd as we lead up to Fedora 9. I am closing this bug. If you find problems with the implementation in anaconda and mkinitrd, then please open more specific bugs against those packages. The document at http://fedoraproject.org/wiki/Releases/FeatureEncryptedFilesystems contains a test plan for this feature. Thanks, everyone.
For the information of anyone else who wants to upgrade an encrypted PV to F9, I have done so successfully through the temporary use of an external USB disk. (Upgrade of an encrypted PV is scheduled for F10: bug #437604) This is roughly what I did: 1) Boot into F8 1a) add unencrypted partition on external USB disk as a new PV in main VG 2) Boot into F9 LiveCD 2a) pvmove LVs from encrypted PV to PV on external disk 2b) vgreduce the encrypted PV out of the main VG 3) Upgrade with F9 upgrade DVD 4) Boot into newly install F9 4a) luksOpen the encrypted partition; vgextend it back into the main VG 4b) run mkinitrd 5) 5a) pvmove the LVs back from the external PV back to the encrypted PV 5b) vgreduce the external PV from the main VG 5c) run mkinitrd The only issue I had was that in step 5) the external disk was created as /dev/sda and the internal disk as /dev/sdb. When I booted without the external disk the internal disk returned to /dev/sda BUT the initrd couldn't find the encrypted PV any more. Booting into the rescue DVD, chrooting to the installed system, and re-running mkinited fixed this.
Ooops: step 5 was from the F9 LiveCD.
This thread is very self-explanatory and informative at the same time. I'm following your blogs for a long time now, and honestly, it is so intriguing that I loved going through all of them. https://www.discountscode.co.uk