Bug 1009708 - FIPS-140 updates needed
Summary: FIPS-140 updates needed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.5
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
: 1011225 (view as bug list)
Depends On:
Blocks: RHEL65FIPS140
TreeView+ depends on / blocked
 
Reported: 2013-09-18 23:29 UTC by Steve Grubb
Modified: 2013-09-26 17:04 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-26 17:04:36 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Steve Grubb 2013-09-18 23:29:57 UTC
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 12:55:01 UTC
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 20:04:42 UTC
Can we get agreement on a solution and devel ack this blocker bug for 6.5?

Comment 7 Bill Nottingham 2013-09-20 20:11:25 UTC
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 22:04:20 UTC
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 21:43:51 UTC
*** 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.