Bug 1009708 - FIPS-140 updates needed
FIPS-140 updates needed
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
6.5
Unspecified Unspecified
urgent Severity high
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
: Regression
: 1011225 (view as bug list)
Depends On:
Blocks: RHEL65FIPS140
  Show dependency treegraph
 
Reported: 2013-09-18 19:29 EDT by Steve Grubb
Modified: 2013-09-26 13:04 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-26 13:04:36 EDT
Type: Bug
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 2013-09-18 19:29:57 EDT
Description of problem:
In order to do a FIPS certifiable installation, people have to boot the OS install with fips=1 kernel parameter. That means that all FIPS modules go into FIPS mode and do an integrity check. This means that they have to find and locate a .hmac file. Due to new requirements handed out by NIST in the last month or so, we had to re-define a FIPS product to be the crypto module + a -fips subpackage. For example, openssl now has a openssl-fips package that has nothing but the .hmac file in it.

The upshot of all this is that we now need the -fips package to be installed in the boot image so that anyone having to do FIPS compliant disk encryption has the .hamc files available for the self test. Booting with a fips=1 commandline parameter and selecting an encrypted partition is the test that QE would need to verify. Not fixing this would be a regression.
Comment 2 David Cantrell 2013-09-19 08:55:01 EDT
The request is fine, but in order to avoid a future where changes to FIPS require a change in anaconda, let's establish some conventions:

1) All packages required for FIPS that are special case should be in a @fips group defined in comps.  This data is maintained outside of anaconda, but is read by anaconda at install time.

2) When fips=1 is passed, anaconda can simply ensure that the @fips group is explicitly added to the package install set.  This avoids us having to maintain a list of packages in anaconda.

Does this sound reasonable to everyone?  If so, we need another bug to handle the comps changes (#1).  We can use this bug to handle #2.
Comment 6 Ann Marie Rubin 2013-09-20 16:04:42 EDT
Can we get agreement on a solution and devel ack this blocker bug for 6.5?
Comment 7 Bill Nottingham 2013-09-20 16:11:25 EDT
You're asking us to move heaven and earth to create a new installation paradigm for fips systems A MONTH AFTER DEVEL FREEZE.

Why wasn't this brought up at any point earlier during 6.5 development?
Comment 8 Steve Grubb 2013-09-20 18:04:20 EDT
Well, the NIST requirements are very new. We have been wresting with a solution and trying to get all the pieces in place. This part of the problem was discovered earlier this week when someone was trying to do a FIPS install.

There may be some misunderstanding of the "ask" here. What we need is -fips files to be in the install media. In know crypt-setup will have one. I don't know if nss, openssl, or openssh is used during install. But that is about the extent of it.

There is the secondary issue of wanting -fips files to wind up in the installed system if the install kernel is booted with fips=1.
Comment 12 Bill Nottingham 2013-09-23 17:43:51 EDT
*** Bug 1011225 has been marked as a duplicate of this bug. ***

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