Okay, so I'm starting to get a clearer picture of the fips issues. The clearest explanation I can find is in the dod guidance for implementing nist 800-171, 3.13.11 "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.". It explicitly explains there the caveats and issues you raised, in particular:
"Simply using an approved algorithm (e.g., FIPS 197 for AES) is not sufficient – the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140." I know this is what has been said by others, but I feel the explicit justification has been somewhat difficult to track down. So that's great, it's explicitly spelled out, which is a big part of what I was looking for. Given that, it's clear that the derivatives should never be passing any of the fips checks as they're intended to be implemented. Even still though, I think the way the fips checks are implemented is off in a couple of ways: The rules themselves are documented to check whether or not ssh (and friends) is configured to use fips validated ciphers. That by itself shouldn't be checking if the os is validated. But from what I can tell the rule should actually be whether or not ssh is configured as a fips validated module, which as discussed, is more than checking the ciphers configuration. So at a minimum, maybe the documentation for the rule should change? Beyond that though, looking at the RHEL documentation, what needs to be checked to test whether or not ssh is configured as a fips approved module is the cipher configuration, whether or not the kernel is in fips mode, I'd if the os is fips certified. It seems those three things together are what makes ssh a fips validated module. As implemented, the checks would pass if ssh is configured with the right algorithms on rhel proper even if the kernel isn't in fips mode. So should the related rules be changed to also check the kernel mode? Putting it all together, is it then a reasonable assertion that the various fips related rules for individual packages be changed as follows: - the description changed to "package is configured as a fips validated module" - checks implemented as requiring all of the following: -- package is configured to exclusively use fips validated algorithms -- kernel is in fips mode -- os is fips certified ? On Fri, Oct 11, 2019, 6:11 PM Gabe Alford <redhatri...@gmail.com> wrote: > > On Fri, Oct 11, 2019 at 12:25 PM Chuck Atkins <chuck.atk...@kitware.com> > wrote: > >> >> >>> FIPS certification is more than just turning on ciphers, >>> >> >> For sure, I'm not arguing that point at all. >> >> >>> but doing so only does the technical part, but it’s not the whole chain. >>> >> >> So, that's what the rules in question are checking though. The technical >> implementation of the ciphers. The >> > > That's not true. The rules also make sure that you are on a FIPS validated > system by design to meet compliance requirements hence the quote of the > NIST 800-53 controls. > > >> >> >>> So, having a CentOS system with proper technical configurations in >>> place is better than not doing so (like having a will on a piece of paper >>> in the top drawer of your dresser is better than not having a will), >>> calling that configuration “FIPS enabled” is not the case. It’s “just” a >>> server with certain ciphers enabled. >>> >> >> Right, but that's not what I'm advocating for. The rules are supposed >> to be testing whether or not certain ciphers, hashes, or packages are >> enabled. Those are technical checks that should be able to pass regardless >> of "certification". There is already a stand alone rule for if the OS is >> FIPS certified, and certainly none of the derivatives should pass. But >> shouldn't some of the technical components still be able to pass? "Is ssh >> configured to exclusively use FIPS approved ciphers?" is different than "Is >> ssh configured to exclusively use FIPS approved ciphers on a FIPS certifies >> OS?" The checks are two different tests and the OS check is already a >> stand alone rule. >> > > No. FIPS ciphers running on non-validated FIPS systems are considered > equivalent to cleartext. FIPS ciphers are validated by compiled binary and > not source code. A very common misconception is that these profiles/rules > is about "hardening to a standard" rather than "validating and ending up in > a compliance state" to 800-171, STIG, Common Criteria, etc. Which is why > certification profiles are no longer being delivered downstream from RHEL > in addition to the rules passing for FIPS as there are no more waivers in > the Federal government for not using FIPS or FIPS validated crypto. Not to > mention the fact that RHEL certifications and certifying content do not > apply to CentOS. There are many issues with CentOS that are related to > compliance areas, e.g. secure supply chain, certifications, validating > crypto, etc. which is why PRs surrounding compliance profiles and FIPS will > be closed. And it isn't about us not wanting to do it, it is about making > sure that compliance profiles get users to compliance end states. For those > that don't have to "comply" with FIPS (anyone not in the Federal > Government), they don't care that they fail. > > >> >>> So, if I were king for a day, I would propose the idea that having a >>> server pass a “FIPS valid” check would requiring passing other checks >>> (ciphers, kernel FIPS configuration, supported RHEL OS). A hardened CentOS >>> system could be configured to pass the cipher check and kernel checks, but >>> fail the supported OS and the meta FIPS validated check. >>> >> >> That can already effectively happen by just enabling all of the FIPS >> related rules. The profile can require all of them and then in the case of >> being run on a derivative OS, most of them can still pass as they are >> testing technical implementation but the "Is OS Certified" and "Is OS >> vendor supported" will always fail. >> > > Rules can be tailored out and removed. Plus, once again, FIPS running on > non-validated systems is considered cleartext. > > >> This is of particular interest outside of RHEL derivative OSs. We're >> currently trying to develop NIST 800-171 content for ubuntu and I don't see >> why we shouldn't be able to enforce the cipher configurations. >> > > There is a different conversation that takes place when we talk about > other distributions, because if we are talking about Canonical-supported > Ubuntu, they do have FIPS-validated crypto. > BTW. FIPS validated crypto is also a requirement of NIST 800-171 for CUI. > > >> >> - Chuck >> _______________________________________________ >> scap-security-guide mailing list -- >> scap-security-guide@lists.fedorahosted.org >> To unsubscribe send an email to >> scap-security-guide-le...@lists.fedorahosted.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org >> > _______________________________________________ > scap-security-guide mailing list -- > scap-security-guide@lists.fedorahosted.org > To unsubscribe send an email to > scap-security-guide-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org >
_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
