Bug 805538 - FIPS-140 support is missing
FIPS-140 support is missing
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
Unspecified Unspecified
high Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 717789
  Show dependency treegraph
 
Reported: 2012-03-21 10:38 EDT by Steve Grubb
Modified: 2012-06-08 10:44 EDT (History)
8 users (show)

See Also:
Fixed In Version: kernel-3.3.0-5.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-31 20:26:38 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 Steve Grubb 2012-03-21 10:38:50 EDT
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.
Comment 1 Josh Boyer 2012-03-21 11:58:15 EDT
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.
Comment 2 Steve Grubb 2012-03-21 12:11:27 EDT
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.
Comment 3 Josh Boyer 2012-03-21 12:22:31 EDT
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.
Comment 4 Steve Grubb 2012-03-21 12:41:29 EDT
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.
Comment 5 Steve Grubb 2012-03-21 12:46:19 EDT
Said another way, the feature already exists in Fedora. The kernel build process and packaging is not allowing it to work.
Comment 6 Josh Boyer 2012-03-21 13:22:12 EDT
(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?
Comment 7 Steve Grubb 2012-03-21 13:59:20 EDT
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.
Comment 8 Josh Boyer 2012-03-21 14:54:55 EDT
(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.
Comment 9 Steve Grubb 2012-03-21 15:53:44 EDT
F15 is not necessary in my opinion. If you want to add it that's fine. Thanks.
Comment 10 Josh Boyer 2012-03-21 16:22:30 EDT
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]$
Comment 11 Fedora Update System 2012-03-26 09:40:40 EDT
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
Comment 13 Fedora Update System 2012-03-28 01:54:40 EDT
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).
Comment 14 Fedora Update System 2012-03-29 19:08:44 EDT
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
Comment 15 Fedora Update System 2012-03-31 20:26:38 EDT
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.
Comment 16 Steve Grubb 2012-04-02 07:47:26 EDT
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!
Comment 18 Fedora Update System 2012-04-11 22:01:24 EDT
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.

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