FIPS mode verification
I'm reading about installed RHEL in FIPS mode and I see this:
To fulfil the strict FIPS 140-2 compliance, add the fips=1 kernel option to the kernel command line during system installation.
But then there is also this:
To turn your system, kernel and user space, into FIPS mode anytime after the system installation, follow these steps:
How do I tell which option was used when I am given a system? How do i verify the system is in strict FIPS mode?
Responses
You have two options:
cat /proc/sys/crypto/fips_enabledsysctl crypto.fips_enabled
1 indicates enabled, while 0 indicates disabled.
Taken from the "Diagnostic Steps" here: https://access.redhat.com/solutions/137833
If you're "choosing" FIPS due to a mandated compliance requirement (99% of people, I would guess), whenever possible, you should absolutely boot the installer with the "fips=1" argument (instead of doing post-install configuration). Doing so will not only save you time and work (you won't have to do all those steps), but ... well, I've updated that article with a warning at the top which explains.
Is there a way to see what might crypto related functions might have been done before FIPS was enabled?
No... not really. If you're not in full control of the system or are unsure of its history ... that's where it's really recommended to install from scratch with FIPS to ensure all is well.
For instance is there a way to see if the SSH keys are FIPS compliant?
The ssh-keygen command -- usually automatically kicked off by ssh-keygen.service (in modern systemd RHEL) on first-boot -- generates groups for Diffie-Hellman Group Exchange as well as SSH host keys. In modern OpenSSH, I doubt FIPS triggers anything different in the former and as far as the latter: since the keys aren't encrypted, I doubt there's any use of a forbidden hashing algo like md5 -- certainly there's nothing that is permanent, given the fact that you can use ssh host keys generated pre-FIPS on a FIPS system.
The argument is more about the FIPS requirements around RNG testing. Though, ssh-keygen might skip generation of some key-types when you're in FIPS mode, e.g., ed25519.
(That said, password-protected ssh user keys is another story.)
Correct me if I'm wrong, but it sounds like you're reviewing a STIG. I'm sorry for your loss.
To the best of my knowledge, there is no difference. If FIPS is enabled, it is enabled. But it is significantly easier to build a FIPS-compliant system if done during the operation system installation process.
It seems a perfectly reasonable question to me, and actually a reasonable requirement. If the system was installed and only subsequently was FIPS 140-2 applied, then the system could have been subverted in the interval. That is what is implied - to my mind at least - in the phrasing of: "To fulfil the strict FIPS 140-2 compliance, add the fips=1 kernel option to the kernel command line during system installation." I'm not one for "security best practice" - it's usually what some non-technical person has read on the internet - usually something posted by another non-technical person, and is the source IMO of the (bad) advice concerning passwords. However in this case, the original question and reason behind it are both reasonable. Sorry to scold, but I find both answers given to be spectacularly unhelpful. The first didn't read the question, and the second hasn't answered it.
I wrote a script that's based on the solution provided by Red Hat at this discussion post https://access.redhat.com/discussions/3487481
I'm going to add more sanity clauses into the script soon, but it's pretty good now.
Regards,
RJ
Brian asked above
If FIPS is enabled, and you can verify that it is enabled
with either method listed above, does it matter how it
was enabled?
- the answer is a tentative "yes" because even after I successfully implemented FIPS using the solution (and a script I wrote to implement the solution, cited above), the STIG check from DISA still failed, even though it was running. So I had to dig into the complaints of the STIG checker and found that the complaints (in this case) wanted a "fips=1" for EVERY instance of a kernel in /boot/grub2/grub.cfg, and if that wasn't enough, it wanted an additional entry in the /etc/defaults/grub for
GRUB_CMDLINE_LINUX_DEFAULT="fips=1"or it would fail too. I had already put a value in forGRUB_CMDLINE_LINUX(see my script, previous post) but that was not sufficient to make it go away in the stig check. So yes, it worked, but it "failed" grrrrr due to the broken nature of the stig checker, but it could be argued the configs were necessary for subsequent kernels (even though my original script fulfilled that.
The alternative is to explain to a disinterested person why your work is correct but the stig check fails. Now in some cases this is going to happen. I've taken additional steps (like in this specific case) to make sure both pass.
enjoy
begin ADDED: See Tom's post for additional clarity. I wrote this with the intention that if you happen to have to carry the cross of STIG compliance, there are additional steps than some of the initial steps for some items to get the compliance software to register. That being said, some of the "checks" are dumb on the compliance check software and it will issue "false positives". There are some things that may be worth it to your organization to "POA&M" and not fulfill compliance on.. There are some STIG things we don't do on specific servers for that reason. Some servers can take most of the security settings we need, some take less based on their server role and if we can or can not implement a given STIG rule (such as FIPS). One example, FIPS and Satellite server, or Gluster does not go together.
end added
Spent a lot of years working in the "STIG required" space: have yet to see a system that is able to get a 100% mark on a compliance-scan ...except in the vanishingly-rare instance where the accreditor is using a scan-profile that's been properly aligned to the specifics of the deployment-environment and the workload the system will be hosting. In a complex, "enterprise" environment - where you may have some systems being hosted on a variety of physical hardware, virtualization frameworks and "cloud"solutions, the typical scores tend to group-out environment-by-environment: e.g., your accreditor's scan-profile typically says "DHCP must be disabled" but your "cloud" hosted systems can never pass this test due to underlying requirements of your cloud service.
In general, if you've taken the proper dev/test/prod deployment cycle, you should know before your systems leave dev for test what scan-items the eventual prod systems will "fail". Having this all documented - and part of your CCP document-bundle - is frequently sufficient for semi-clueful accreditors.
Given that there's a number of COTS products that simply will not operate under FIPS mode, you can get around it via your POA&M filing. Which, again, is something you should know to have documented well before your official accreditor has sat down to run his tools against it.
Absolutely, if FIPS (or some STIG thing) breaks the function of something, and it's important enough, it can be dealt with as Tom says. The same with many other things that are in the STIG. We don't take "everything" either, and some things we "POA&M" That being said, our stig compliance is nicely high, while still being functional. A system that gets 100% is probably not useful at all. Ours are not 100% and I too have yet to see a system that is 100% just as Tom said.
My intent is simply to answer that one itch that Brian asked, not to make some statement that 100% to be the goal because that is totally unrealistic.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
