I agree with Chuck in that the checks should go all the way down the stack for validation since this is what is actually correct.
The current checks do not do that and are incorrect in that sense. Technically, I could replace system openssl with a recompiled openssl and invalidate the whole thing. This should be checked for to produce an actual valid check down the stack. A valid check (in the case of SSH) would be: * SSH is from Red Hat * SSH is configured with correct ciphers/hashes/etc... * SSH is using system openssl * System openssl is the one from Red Hat * Kernel is one of the approved ones from Red Hat * Kernel is FIPS enforcing Now, the reason that I wanted this capability is just to see if things break horribly when put in FIPS mode on a CentOS system. Why? Because, it's easy to do in GitLab CI without exposing my RHN keys to the world. I tried this several different ways without success so far. While I made it function, I couldn't do it in a way that didn't expose the keys in the logs. Thanks, Trevor On Sat, Oct 12, 2019 at 8:51 AM Chuck Atkins <chuck.atk...@kitware.com> wrote: > 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 > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --
_______________________________________________ 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
