Description of problem: The Fedora distribution cannot be tested in FIPS mode because the kernel is not shipping .hmac files with the crypto modules. The spec file needs to create the .hmac files and include them. Without it, the kernel cannot validate module integrity and therefore panics. So, there is no way to do any user space FIPS development or testing on Fedora. Version-Release number of selected component (if applicable): all How reproducible: everytime Steps to Reproduce: 1. set PRELINKING=no in /etc/sysconfig/prelink 2. prelink -u -a 3. yum install dracut-fips 4. dracut -f 5. append fips=1 to the kernel line in /etc/grub.conf 6. If /boot or /boot/efi resides on a separate partition, the kernel parameter boot=<partition of /boot or /boot/efi> must be supplied. use 'df /boot' to figure out what goes into the boot parameter and append it to the kernel line in /etc/grub.conf 7. reboot Actual results: panic Expected results: login prompt Additional info: rhel kernel spec file probably has the missing commands to make the .hmac files. You will probably need to add a BuildDependency on hmaccalc.
I don't much see a benefit to Fedora in doing this. Can you elaborate why it would be needed at all? As far as I know, the Fedora project is not going for FIPS-140 compliance. Also, if there are good reasons perhaps you could attach a patch that provides this based on what you found in RHEL.
Yeah, its real simple. Without the kernel successfully coming up, /proc/sys/crypto/fips_enabled does not have a 1 in it. That means none of user space goes into FIPS mode. Therefore no developer or upstream maintainers can see the effect of FIPS mode on their software. Right now squid and aide are broken as is many other things. We cannot do any effective testing and bug solving without being able to come up in FIPS whether Fedora is certified or not.
Sorry, my question might have been unclear. Your answer simply said the same thing as the original report. My question might have been better phrased as: Is this a new Fedora Feature? Is there some distro-wide coordinated effort to prove as a usable testbed for FIPS-140? You reported this against F16, which would make me think this is some kind of regression if it's a feature. Except I'm pretty sure that F16 never shipped any hmac files ever. So this must be some kind of new request. Which is why I'm thinking perhaps this is a new feature. At any rate, I'll move it to rawhide since that's where any sort of fix will land. Also, upstream kernel developers should be able to build their own kernel with whatever is needed so I doubt they're blocked on this.
This is not exactly a feature request. The kernel has everything in it to support FIPS. No development work needs to be done there. It just needs to create the .hmac files and package them up. I thought they were shipped at one time in the past like F8/9. But in terms of distro wide coordinated effort, its not needed. Openssl, libgcrypt, nss, openssh already have support in them. We are just trying to do our normal daily development work on user space components and fix any problems. The kernel not having .hmac files is the only thing blocking work. This is not about kernel developers needing this to do work, its about user space not being able to go into fips mode where we can do our testing. So, yes it blocks development. I put the bug on F16 because I and others need to use a stable distribution to work on. This does not introduce any logic changes that affect any user (unless they boot into FIPS mode), its just making and shipping .hmac file so that the kernel finishes booting. Very low risk. Putting this in rawhide means no one will see the effects of FIPS until fall of 2012. That is way too long for such a simple change.
Said another way, the feature already exists in Fedora. The kernel build process and packaging is not allowing it to work.
(In reply to comment #4) > This is not about kernel developers needing this to do work, its about user > space not being able to go into fips mode where we can do our testing. So, yes > it blocks development. I put the bug on F16 because I and others need to use a > stable distribution to work on. This does not introduce any logic changes that > affect any user (unless they boot into FIPS mode), its just making and shipping > .hmac file so that the kernel finishes booting. Very low risk. Putting this in > rawhide means no one will see the effects of FIPS until fall of 2012. That is > way too long for such a simple change. Is the kernel panicing because it crapped itself, or because userspace decided "oh no, I can't continue" and the init process exited? IMHO, the answer to that question is going to provide a lot more insight as to how invasive this is. Maybe even the actual backtrace? Perhaps I'm confused, but even if the kernel already has everything it needs to support FIPS, it still clearly isn't being tested and used today. I know the kernel team certainly isn't going to sign up to do testing for that. Are you and whomever you're working with when you say "we" comfortable handling any fallout that comes from fips=1 being usable?
This is a planned panic. If you look in: /usr/share/dracut/modules.d/01fips/fips.sh you see this: info "Checking integrity of kernel" if ! [ -e "/boot/.vmlinuz-${KERNEL}.hmac" ]; then warn "/boot/.vmlinuz-${KERNEL}.hmac does not exist" return 1 fi sha512hmac -c "/boot/.vmlinuz-${KERNEL}.hmac" || return 1 So, the initrd is where this panic occurs. It just needs the .hmac file for the vmlinuz-* binary. This is done like so: %if %{with_fips} BuildRequires: hmaccalc %endif After the initramfs is sized, then %if %{with_fips} # hmac sign the kernel for FIPS echo "Creating hmac file: $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac" ls -l $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer sha512hmac $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer | sed -e "s,$RPM_BUILD_ROOT,," > $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac; %endif And in the install section %if %{with_fips} \ /%{image_install_path}/.vmlinuz-%{KVERREL}%{?2:.%{2}}.hmac \ %endif \ The above needs tweaking for Fedora's spec file. But it shows you the basic recipe. This is only spec file work. No kernel changes. No new config flags.
(In reply to comment #7) > This is a planned panic. If you look in: > /usr/share/dracut/modules.d/01fips/fips.sh you see this: > > info "Checking integrity of kernel" > if ! [ -e "/boot/.vmlinuz-${KERNEL}.hmac" ]; then > warn "/boot/.vmlinuz-${KERNEL}.hmac does not exist" > return 1 > fi > sha512hmac -c "/boot/.vmlinuz-${KERNEL}.hmac" || return 1 > > So, the initrd is where this panic occurs. OK. That makes me much more comfortable with the word "panic" here. It just needs the .hmac file for the > vmlinuz-* binary. This is done like so: > > %if %{with_fips} > BuildRequires: hmaccalc > %endif > > After the initramfs is sized, then > > %if %{with_fips} > # hmac sign the kernel for FIPS > echo "Creating hmac file: > $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac" > ls -l $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer > sha512hmac $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer | > sed -e "s,$RPM_BUILD_ROOT,," > > $RPM_BUILD_ROOT/%{image_install_path}/.vmlinuz-$KernelVer.hmac; > %endif > > And in the install section > %if %{with_fips} \ > /%{image_install_path}/.vmlinuz-%{KVERREL}%{?2:.%{2}}.hmac \ > %endif \ > > The above needs tweaking for Fedora's spec file. But it shows you the basic > recipe. This is only spec file work. No kernel changes. No new config flags. Great, thank you for providing that. I'll probably skip the with_fips conditional because there's really little point in putting that in if we're not going to disable it. My last question is if this needs to be applied to F15 too. F16-rawhide seems reasonable to me, but I thought I'd check.
F15 is not necessary in my opinion. If you want to add it that's fine. Thanks.
Applied to Fedora git. Should be in all the various next updates. [jwboyer@vader kernel]$ rpm -qpl x86_64/kernel-3.3.0-5.fc16.x86_64.rpm | grep hmac /boot/.vmlinuz-3.3.0-5.fc16.x86_64.hmac [jwboyer@vader kernel]$
kernel-3.3.0-5.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/kernel-3.3.0-5.fc17
Package kernel-3.3.0-5.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.3.0-5.fc17' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4761/kernel-3.3.0-5.fc17 then log in and leave karma (feedback).
kernel-3.3.0-8.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kernel-3.3.0-8.fc16
kernel-3.3.0-8.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Just thought I'd follow up and say that the change to the build process change is working correctly. There are some problems with dracut now, but this is exactly what we needed to find out. Thanks for the help!
kernel-3.3.0-5.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.