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

[Tomatotech90]

Description:

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

After #14834 was merged, I went through the remaining files from the
maintainer's grep list and identified 15 additional files where
DoD-specific phrasing can be replaced with policy-agnostic language
Without changing the meaning of the underlying security requirement.

Files changed:

• 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
• configure_gnutls_tls_crypto_policy/rule.yml
• var_smartcard_drivers.var
• 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
• httpd_public_resources_not_shared/rule.yml
• ensure_gpgcheck_repo_metadata/rule.yml
• banner_etc_profiled_ssh_confirm/rule.yml
• banner_etc_motd/rule.yml
• banner_etc_gdm_banner/rule.yml
• banner_etc_issue_net/rule.yml

Pre-existing trailing whitespace in var_smartcard_drivers.var and
banner_etc_profiled_ssh_confirm/rule.yml was also fixed during lint
Verification of those files.

Rationale:

Make security content policy-agnostic, so it applies to any organization,
not only DoD. Each change removes or replaces a DoD-specific reference
with equivalent generic language while preserving the technical requirement.

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 where the DoD reference is part
of the rule's actual requirement rather than incidental wording.
Guidance from maintainers would be appreciated before touching 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 that should be used here, 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

These rules reference DoD-specific networks (NIPRNet/SIPRNet) or
DoD-mandated exemption lists. 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?

Review Hints:

Each file can be reviewed independently. Changes are prose-only with
No impact on OVAL checks, remediations, or rule logic'

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.