Bug 1009708

Summary:	FIPS-140 updates needed
Product:	Red Hat Enterprise Linux 6	Reporter:	Steve Grubb <sgrubb>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED NOTABUG	QA Contact:	Release Test Team <release-test-team>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	6.5	CC:	arubin, dgregor, ebenes, lkocman, notting, rrelyea, sforsber, sgrubb
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-09-26 17:04:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	968473

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. ***