This PR follows #14834 and continues addressing issue #8709.

[Tomatotech90]

Description

This PR follows #14834 and continues addressing issue #8709.

After #14834 was merged, reviewing the remaining files from the maintainer's grep list, I identified 15 additional files containing DoD-specific phrasing. Following review feedback, this PR now keeps DoD wording where it mirrors upstream STIG content, and generalizes it only where it was incidental prose.

Files reworded to generic language:

• configure_gnutls_tls_crypto_policy/rule.yml
• httpd_public_resources_not_shared/rule.yml
• ensure_gpgcheck_repo_metadata/rule.yml

Files reverted to original DoD wording, since they mirror upstream STIG content:

• ssh_use_approved_macs_ordered_stig/rule.yml
• set_firewalld_default_zone/policy/stig/shared.yml
• harden_sshd_macs_opensshserver_conf_crypto_policy/policy/stig/shared.yml
• set_password_hashing_algorithm_systemauth/policy/stig/shared.yml
• set_password_hashing_algorithm_systemauth/policy/stig/rhel10.yml
• accounts_password_pam_minlen/policy/stig/shared.yml
• sssd_certificate_verification/policy/stig/shared.yml
• var_smartcard_drivers.var

Banner files:

• banner_etc_issue_net/rule.yml, banner_etc_motd/rule.yml, banner_etc_gdm_banner/rule.yml: removed the required banner text entirely from the description field, rather than just rewording the lead-in sentence.
• banner_etc_profiled_ssh_confirm/rule.yml: added a new option, generic_default, to var_ssh_confirm_text.var, so this rule now supports a policy-agnostic banner alongside the existing dod_default option. Updated the description field in rule.yml to clarify that the confirmation text is configurable via the variable, rather than showing the DoD text directly.

Pre-existing trailing whitespace in var_smartcard_drivers.var was fixed during lint verification.

Rationale

Make security content policy-agnostic, with the DoD reference incidental, while keeping DoD wording when the content mirrors upstream STIG language or documents a requirement that is intentionally DoD-specific.

Updates #8709 (does not fully close it, see notes below).

Notes

17 files from the original grep list were reviewed but excluded from this PR. They fall into three groups, in which the DoD reference is part of the rule's actual requirement rather than incidental wording. These questions are still open. Guidance would be appreciated before I change any of these.

Group 1: Banner text files (7 files)
banner_etc_issue/rule.yml, banner_etc_issue/policy/stig/shared.yml, gui_login_dod_acknowledgement/rule.yml, login_banner_text.var, motd_banner_text.var, remote_login_banner_text.var, var_web_login_banner_text.var

These files contain the Standard Mandatory DoD Notice and Consent Banner as verbatim text that checks against. Should the option keys (dod_banners, dod_default) be renamed, or is that intentional since DoD STIG profiles select those keys by name?

Group 2: PKI and certificate files (5 files)
sssd_has_trust_anchor/rule.yml, sssd_has_trust_anchor/policy/stig/shared.yml, httpd_configure_valid_server_cert/rule.yml, only_allow_dod_certs/rule.yml, httpd_configure_banner_page/rule.yml

These rules check for or reference DoD-specific PKI infrastructure (DoD Root CA, DoD server certificates, cyber.mil). Is there a generic equivalent, or are these rules intentionally DoD-specific?

Group 3: DoD infrastructure and network files (5 files)
httpd_nipr_accredited_dmz/rule.yml, smartcard_auth/rule.yml, chronyd_server_directive/rule.yml, chronyd_or_ntpd_set_maxpoll/rule.yml, mcafee_security_software/group.yml

These rules reference DoD-specific networks (NIPRNet/SIPRNet), DoD-mandated exemption lists, or DoD-mandated tooling. The NIPRNet/SIPRNet references appear in srg_requirement fields that quote the STIG SRG verbatim. Should those be left as-is since they are direct SRG quotes? Is there a generic equivalent for mcafee_security_software, or is it also intentionally DoD-specific?

Review Hints

Each file can be reviewed independently. Changes are prose-only with no impact on OVAL checks, remediations, or rule logic, except for the banner files, where the required-text block was removed or replaced with a variable reference in the description field.

Full documentation of the approach, verification steps, and lint/build results for this PR: https://github.com/Tomatotech90/github-contribution-log/blob/main/Remove_DoD_Specific_Verbiage_from_rule.yml_(Part%202).md

[openshift-ci]

Hi @Tomatotech90. Thanks for your PR.

I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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-sigs/prow repository.

[Mab879]

Thanks for the PR. I have a few comments.

[Mab879]

The rules with _stig can be keep the DoD wording as they specifically for the STIG.

[Mab879]

The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.

[Mab879]

If we truly removing DOD specific content we should remove the required text.,

[Mab879]

Same as banner_etc_issue_net.

[Mab879]

Same as banner_etc_issue_net.

[Mab879]

The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.

[Mab879]

This is some helpful text, propose to keep.

[Mab879]

The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.

[Mab879]

The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.

[Mab879]

The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.

[Tomatotech90]

Thanks, and I will do the changes.

[Tomatotech90]

@Mab879 Thanks for the detailed feedback. I've made the following changes:
Reverted to original DoD wording (8 files), since these are STIG-specific or mirror upstream STIG content:

ssh_use_approved_macs_ordered_stig/rule.yml
set_firewalld_default_zone/policy/stig/shared.yml
harden_sshd_macs_opensshserver_conf_crypto_policy/policy/stig/shared.yml
set_password_hashing_algorithm_systemauth/policy/stig/shared.yml
set_password_hashing_algorithm_systemauth/policy/stig/rhel10.yml
accounts_password_pam_minlen/policy/stig/shared.yml
sssd_certificate_verification/policy/stig/shared.yml
var_smartcard_drivers.var

Each of these now matches the original upstream text exactly. I verified this with a direct diff against upstream/master for each file.
Removed the required banner text entirely (3 files), per the feedback that rewording the lead in sentence wasn't enough:

banner_etc_issue_net/rule.yml
banner_etc_motd/rule.yml
banner_etc_gdm_banner/rule.yml

The description field in each now ends after the intro paragraph explaining how to configure the banner. The required text block (the USG notice and the "I've read..." alternative) has been removed entirely, not just reworded.
Held aside, need your input:

banner_etc_profiled_ssh_confirm/rule.yml

This one is different from the other three banner files. The required text isn't a standalone block; it's embedded inside a shell script as the string passed to a read -p prompt (the if [ -n "$SSH_CLIENT" ]... while... read -p... case... esac logic). Removing the DoD wording here means either stripping the whole script or just blanking the prompt string while keeping the script structure intact. I didn't want to guess which one is correct without knowing what the associated check actually verifies, so I left this file unchanged for now. Let me know which approach you'd prefer, and I'll update it.
No changes were made (3 files), since there was no comment on these:

configure_gnutls_tls_crypto_policy/rule.yml
httpd_public_resources_not_shared/rule.yml
ensure_gpgcheck_repo_metadata/rule.yml

[Mab879]

Looking at banner_etc_profiled_ssh_confirm/rule.yml we might be able to put variable var_ssh_confirm_text in place of the DoD Text.

[Tomatotech90]

Looking at banner_etc_profiled_ssh_confirm/rule.yml we might be able to put variable var_ssh_confirm_text in place of the DoD Text.

Thanks, that makes sense. Checking turns out var_ssh_confirm_text.var already exists in the repo and is correctly wired into the fix script via {{{ bash_instantiate_variables("var_ssh_confirm_text") }}} in bash/shared.sh. So the variable mechanism itself isn't missing.
What I think is missing is a generic option. Right now that .var file only has one option, dod_default, with the USG banner text as a regex value. There's no non-DoD choice to pick instead, similar to var_smartcard_drivers.var offers a few options, including a generic one.
So what I'm thinking is: add a second, generic option to var_ssh_confirm_text.var (something like generic_default) with a policy-agnostic placeholder banner in the same regex format as dod_default, then update rule.yml's description field, since right now it just shows the DoD text directly and doesn't reflect that the variable mechanism already exists.

[Mab879]

Adding another option var_ssh_confirm_text would be fine.

[Tomatotech90]

Adding another option var_ssh_confirm_text would be fine.

I did add the variable

[Mab879]

/ok-to-test

[Tomatotech90]

/retest

[Mab879]

If you could add test for new generic_default that might be good idea as well.

[Tomatotech90]

The generic_default test was failing. var_ssh_confirm_text has no default option set, so the scan kept resolving to dod_default no matter what the test wrote to disk. Added a variables line to the test scenario so it actually picks generic_default during the scan. Checked it locally with the Jinja stripper and a full build, both clean. Waiting on CI now.

[Tomatotech90]

@Mab879

fail 1: banner_etc_profiled_ssh_confirm_generic.pass.sh failure
I checked this failure since it kept happening after a few fixes, so I went to check the actual test framework code instead of guessing again.
I found that the variables metadata comment (# variables = var_ssh_confirm_text=generic_default) is applied through an XSLT patch in tests/ssg_test_suite/rule.py (generate_xslt_change_value_template). I think the issue is that this patch performs a blind, literal text substitution: it writes whatever string follows the = directly into the datastream's unselected node as raw text. It doesn't resolve generic_default as an option name into its actual regex, it just writes the seven characters generic_default verbatim.
So I think this mechanism can't select a named option for a variable like var_ssh_confirm_text, since its options hold full regex values, not simple literals. Putting the actual regex directly in the metadata line doesn't work either, since variables are parsed as a comma-separated list and the regex itself contains many literal commas, so it would get split during parsing.
I verified generic_default resolves correctly and produces valid banner text by running it through the same deregexify steps used at build time (documented in the PR's contribution log), but I don't see a way to wire that into an automated .pass.sh scenario given how the test framework currently works.
I would like you to check this and let me know if you'd prefer I remove the generic_default test scenario and rely on the manual verification already documented, or if there's a different pattern I should use for testing variable options like this one.

---

Fail 2: stable-products failure on sle16
The Gate job is also failing on an unrelated check: stable-products reports sshd_config_base_dir changed for sle16 from /etc/ssh to /usr/etc/ssh. Nothing in this PR touches any SLE16 file or product definition; this appears to be pre-existing drift on master, surfaced by CI running against this branch, not something introduced by these changes. Flagging it here rather than editing SLE16 files myself, since I don't have visibility into why that drift happened upstream.

[Mab879]

Fail 1: We can move the scenario and once done I will do manual testing

Fail 2 should be fixed by: #14875

[Mab879]

I did some manual testing and it seems there are some unescaped ' in the text that is causing the remediation to error out. It might be best to reword to not require apostrophes.

[Tomatotech90]

/retest

[Tomatotech90]

/test e2e-aws-openshift-node-compliance

[Tomatotech90]

/test e2e-aws-openshift-platform-compliance

[Mab879]

During manual testing I was still running into issues.

I was able to get passing with suggest change to the regex and this diff below.

Seems that ? tripping something up.

diff --git a/ssg/utils.py b/ssg/utils.py
index 482e51d4c0..295afc863c 100644
--- a/ssg/utils.py
+++ b/ssg/utils.py
@@ -598,8 +598,8 @@ def escape_regex(text):
 
     This function mimics the behavior of re.escape() in Python 3.7, which escapes a reasonable set
     of characters.
-    Specifically, it escapes the following characters: #, $, &, *, +, ., ^, `, |, ~, :, (, ), and -.
-    Note that the characters '!', '"', '%', "'", ',', '/', ':', ';', '<', '=', '>', '@', and "`"
+    Specifically, it escapes the following characters: #, $, &, *, +, ., ?, ^, `, |, ~, :, (, ), [, ], and -.
+    Note that the characters '!', '"', '%', "'", ',', '/', ';', '<', '=', '>', '@', and "`"
     are not escaped.
 
     Args:
@@ -611,8 +611,9 @@ def escape_regex(text):
     # We could use re.escape(), but it escapes too many characters, including plain white space.
     # In python 3.7 the set of characters escaped by re.escape is reasonable, so lets mimic it.
     # See https://docs.python.org/3/library/re.html#re.sub
-    # '!', '"', '%', "'", ',', '/', ':', ';', '<', '=', '>', '@', and "`" are not escaped.
-    return re.sub(r"([#$&*+.^`|~:()\[\]-])", r"\\\1", text)
+    # '!', '"', '%', "'", ',', '/', ';', '<', '=', '>', '@', and "`" are not escaped.
+    # '?' must be escaped; otherwise plain-text questions become regex quantifiers.
+    return re.sub(r"([#$&*+.?^`|~:()\[\]-])", r"\\\1", text)

[Tomatotech90]

During manual testing I was still running into issues.

I was able to get passing with suggest change to the regex and this diff below.

Seems that ? tripping something up.

diff --git a/ssg/utils.py b/ssg/utils.py
index 482e51d4c0..295afc863c 100644
--- a/ssg/utils.py
+++ b/ssg/utils.py
@@ -598,8 +598,8 @@ def escape_regex(text):
 
     This function mimics the behavior of re.escape() in Python 3.7, which escapes a reasonable set
     of characters.
-    Specifically, it escapes the following characters: #, $, &, *, +, ., ^, `, |, ~, :, (, ), and -.
-    Note that the characters '!', '"', '%', "'", ',', '/', ':', ';', '<', '=', '>', '@', and "`"
+    Specifically, it escapes the following characters: #, $, &, *, +, ., ?, ^, `, |, ~, :, (, ), [, ], and -.
+    Note that the characters '!', '"', '%', "'", ',', '/', ';', '<', '=', '>', '@', and "`"
     are not escaped.
 
     Args:
@@ -611,8 +611,9 @@ def escape_regex(text):
     # We could use re.escape(), but it escapes too many characters, including plain white space.
     # In python 3.7 the set of characters escaped by re.escape is reasonable, so lets mimic it.
     # See https://docs.python.org/3/library/re.html#re.sub
-    # '!', '"', '%', "'", ',', '/', ':', ';', '<', '=', '>', '@', and "`" are not escaped.
-    return re.sub(r"([#$&*+.^`|~:()\[\]-])", r"\\\1", text)
+    # '!', '"', '%', "'", ',', '/', ';', '<', '=', '>', '@', and "`" are not escaped.
+    # '?' must be escaped; otherwise plain-text questions become regex quantifiers.
+    return re.sub(r"([#$&*+.?^`|~:()\[\]-])", r"\\\1", text)

I made a patch to ssg/utils.py because the ? in the banner text was not being escaped, causing the remediation to error out. Applied the fix to escape_regex and regenerated the generic_default regex with the corrected tool, so it now escapes the ? same way dod_default does. Checked it with yamllint and full builds for RHEL9 and Ubuntu 24.04, both came out clean

[Tomatotech90]

/retest

[openshift-ci]

@Tomatotech90: The following test 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-openshift-node-compliance	ede308b	link	true	/test e2e-aws-openshift-node-compliance

Full PR test history. Your PR dashboard.

Details

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-sigs/prow repository. I understand the commands that are listed here.