Broaden sshd_use_approved_* to non-FIPS use cases

[cipherboy]

Description

Allow sshd_use_approved_ciphers to satisfy both FIPS and non-FIPS use cases with the same rule. Benchmarks like CIS encourage the usage of approved cipher suites as well (and do mention FIPS), but don't strictly limit the caller to FIPS. For DISA STIG, other rules are more applicable like sshd_use_approved_ciphers_ordered_stig so this change should be safe.

Remove the dependency on the installed_OS_is_FIPS_certified OVAL as well.

Also apply to sshd_use_approved_macs.

Resolves: #6901

Co-Authored-By: Richard Maciel Costa <[email protected]>
Signed-off-by: Alexander Scheel <[email protected]>

Rationale

As mentioned in #6901, we have duplicate rules for strictly DISA-STIG systems (sshd_use_approved_ciphers_ordered_stig and sshd_use_approved_macs_ordered_stig). Benchmarks like CIS can use but don't strictly require FIPS mode. But all benchmarks have the notion of an "approved" list of ciphers. So replace most instances of FIPS with Approved.

Note that I left the list of FIPS ciphers in place (along with the FIPS warning message) as the CIS benchmark does include FIPS-approved cipher listings.

[openscap-ci]

Changes identified: Rules:  sshd_use_approved_ciphers  sshd_use_approved_macs

Show details

Rule sshd_use_approved_ciphers:  Node moved within OVAL check.  Node deleted from OVAL check.  Deleted attribute from OVAL check.  Attribute value changed in OVAL check.  Text changed in OVAL check. Rule sshd_use_approved_macs:  Node moved within OVAL check.  Node deleted from OVAL check.  Deleted attribute from OVAL check.  Attribute value changed in OVAL check.  Text changed in OVAL check.

Recommended tests to execute:  build_product rhel7  tests/test_suite.py rule --libvirt qemu:///system test-suite-vm --remediate-using bash --datastream build/ssg-rhel7-ds.xml sshd_use_approved_ciphers  tests/test_suite.py rule --libvirt qemu:///system test-suite-vm --remediate-using bash --datastream build/ssg-rhel7-ds.xml sshd_use_approved_macs

[JAORMX]

/test all

[yuumasato]

I don't fully understand the FIPS use cases and some of the nuances...

But historically, the sshd_use_approved_* rules have been about FIPS approved algorithms, and the sshd_use_strong_* rules came in to be the counter part without FIPS verbiage. So I'd tend to improve the strong rules instead of the approved ones... But I don't have a strong opinion here. Do @carlosmmatos @ggbecker have thoughts on this?

And about the approved rules having a check for FIPS approved OSes. This came in from people in the field, that despite the warnings in the rule people still got confused and thought they were FIPS compliant because the rule was passing. I'd really be interested to hear more stories about this, whether the OS check is useful or just frustrates people.

[cipherboy]

This came in from people in the field, that despite the warnings in the rule people still got confused and thought they were FIPS compliant because the rule was passing.

Hmmm...

So one of the things this does is drop "FIPS" from the title of the rule so hopefully that will be less-so the case.

However, I'm not suggesting that installed_OS_is_FIPS_certified be removed from all profiles that it is relevant in, merely that it (continue to) be explicitly included and be a separate and independent rule in its own right.

Rules like enable_fips_mode should definitely exist and depend on installed_OS_is_FIPS_certified, so I'm not sure how (unless they're building their own profile?) they'd end up with this rule being what convinces them of FIPS support, without well, the other rules that include FIPS in their name. :D

I dunno. :-)

Regarding the OS check in general, I think it is useful to weed out the CentOS/Rocky/Scientific Linux users (or in general, when a new OS is released like RHEL 9 but isn't yet certified from day-zero) -- in case they assume the OS is FIPS certified this will help confirm it isn't. But more OSes are undergoing FIPS certification and might not necessarily be tracked here. Ubuntu was the obvious missing case but maybe there's more elsewhere?

[jan-cerny]

@cipherboy any plans?

[cipherboy]

Hi @jan-cerny, no plans from me :-) @dodys might be better if he's still at Canonical. But if there's enough community sentiment (it seemed like Carlos agreed), I'm more than happy to have someone else pick this up (@Mab879? :D)

[dodys]

Hi @jan-cerny, no plans from me :-) @dodys might be better if he's still at Canonical. But if there's enough community sentiment (it seemed like Carlos agreed), I'm more than happy to have someone else pick this up (@Mab879? :D)

I'm trying to catch-up on this, but is there anything else needed?

[cipherboy]

@dodys Not that I can tell; from what I recall of discussions at the time, it was left for internal discussions at RH to decide if they were fine to remove it or not. From a project perspective, it made sense roughly that FIPS compliance should be a separate line item than "safe" SSH cipher suite selection and further that SSH cipher suite selection could be restricted in cases other than FIPS mode.

But IIRC, there was some discussion of their own benchmark plans if they were going to broaden this rule from strict FIPS compliance or not. Otherwise, we might end up creating a separate role entirely (with a different name...); something I think we've tried to avoid in this project...

Maybe it just needs a rebase and we can merge it? If so, happy to do the rebase.

[dodys]

@dodys Not that I can tell; from what I recall of discussions at the time, it was left for internal discussions at RH to decide if they were fine to remove it or not. From a project perspective, it made sense roughly that FIPS compliance should be a separate line item than "safe" SSH cipher suite selection and further that SSH cipher suite selection could be restricted in cases other than FIPS mode.

But IIRC, there was some discussion of their own benchmark plans if they were going to broaden this rule from strict FIPS compliance or not. Otherwise, we might end up creating a separate role entirely (with a different name...); something I think we've tried to avoid in this project...

Maybe it just needs a rebase and we can merge it? If so, happy to do the rebase.

Yeah, I can also do it, if you want me to.

But it would be nice to have some confirmation from @yuumasato and others, that there isn't anything else impacting this on their side.

[openshift-ci[bot]]

@cipherboy: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-aws-ocp4-cis-node	11aa97c10a3b597a4e7780ea0a167f1ecfe09687	link	/test e2e-aws-ocp4-cis-node
ci/prow/e2e-aws-ocp4-moderate	11aa97c10a3b597a4e7780ea0a167f1ecfe09687	link	/test e2e-aws-ocp4-moderate
ci/prow/e2e-aws-ocp4-e8	11aa97c10a3b597a4e7780ea0a167f1ecfe09687	link	/test e2e-aws-ocp4-e8
ci/prow/e2e-aws-ocp4-cis	11aa97c10a3b597a4e7780ea0a167f1ecfe09687	link	/test e2e-aws-ocp4-cis
ci/prow/e2e-aws-rhcos4-moderate	11aa97c10a3b597a4e7780ea0a167f1ecfe09687	link	/test e2e-aws-rhcos4-moderate
ci/prow/e2e-aws-ocp4-high-node	11aa97c10a3b597a4e7780ea0a167f1ecfe09687	link	true	/test e2e-aws-ocp4-high-node
ci/prow/e2e-aws-rhcos4-high	11aa97c10a3b597a4e7780ea0a167f1ecfe09687	link	true	/test e2e-aws-rhcos4-high
ci/prow/e2e-aws-ocp4-stig	11aa97c10a3b597a4e7780ea0a167f1ecfe09687	link	true	/test e2e-aws-ocp4-stig

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[jan-cerny]

It seems that there is nothing happening recently, so I will closed this due to inactivity. But you can reopen it if you still want this change.