Bug 2020670

Description of problem:

The sshd* rules in OSPP profile like sshd_enable_warning_banner talk in description about the configuration to be added to /etc/ssh/sshd_config. However, the OVAL checks and especially the remediation work with /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf, or due to the use of missing_parameter_pass: 'true' in rule.yml, no configuration is done.

So when remediation is run and reports fixed, checking the content of the configuration manually based on the description does not find the configuration there.

Also, the use of single 00-complianceascode-hardening.conf file for multiple rules seems weird.

Version-Release number of selected component (if applicable):

scap-security-guide-0.1.57-5.el9.noarch

How reproducible:

Deterministic.

Steps to Reproduce:
1. Make a backup of /etc/ssh:
   cp -rp /etc/ssh /etc/ssh.orig
2. Run oscap xccdf eval --remediate --profile xccdf_org.ssgproject.content_profile_ospp --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
3. Open report.html in browser.
4. Click "Show all result details"
5. Search for "content_rule_sshd_" in the page and for each of those rules, read the description and check on disk (diff files /etc/ssh against /etc/ssh.orig) what was configured and where.

Actual results:

xccdf_org.ssgproject.content_rule_sshd_disable_empty_passwords:
Description talks only about configuring in /etc/ssh/sshd_config.
But no change is done due to missing_parameter_pass: 'true'.

xccdf_org.ssgproject.content_rule_sshd_disable_gssapi_auth:
Description talks only about configuring in /etc/ssh/sshd_config.
After remediation, /etc/ssh/sshd_config.d/50-redhat.conf still has GSSAPIAuthentication yes and no other configuration is done.

xccdf_org.ssgproject.content_rule_sshd_disable_kerb_auth:
Description talks only about configuring in /etc/ssh/sshd_config.
But no change is done due to missing_parameter_pass: 'true'.

xccdf_org.ssgproject.content_rule_sshd_disable_root_login:
Description talks only about configuring in /etc/ssh/sshd_config.
Actual configuration done in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf.

xccdf_org.ssgproject.content_rule_sshd_enable_strictmodes:
Description talks only about configuring in /etc/ssh/sshd_config.
But no change is done due to missing_parameter_pass: 'true'.

xccdf_org.ssgproject.content_rule_sshd_enable_warning_banner:
Description talks only about configuring in /etc/ssh/sshd_config.
Actual configuration done in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf.

xccdf_org.ssgproject.content_rule_sshd_rekey_limit:
Description talks only about configuring in /etc/ssh/sshd_config.
Configuration done in /etc/ssh/sshd_config, so this one matches -- yay!

xccdf_org.ssgproject.content_rule_sshd_use_directory_configuration:
Description talks only about configuring in /etc/ssh/sshd_config.
Configuration stays in /etc/ssh/sshd_config, so this one matches -- yay!

xccdf_org.ssgproject.content_rule_sshd_disable_empty_passwords:
Description talks only about configuring in /etc/ssh/sshd_config.
But no change is done due to missing_parameter_pass: 'true'.

Expected results:

If the config change will be done in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf, the description should say so.

If the config change will not be done (because the defaults are sufficient), the description should say so.

Additional info:

I actually like the missing_parameter_pass: 'true' and using the defaults. But then, the description should be updated to make it clear that not having that configuration anywhere is acceptable too since the compiled-in defaults take care of the problem.

I have concerns about using single 00-complianceascode-hardening.conf as a dumping place for all changes. This is not how drop-in snippets are supposed to work. Shouldn't each rule put their config line to separate file?

After all, for ssh client, /etc/ssh/ssh_config.d/02-rekey-limit.conf gets created for ssh_client_rekey_limit rule, so why don't sshd rules do the same?