This PR follows #14834 and continues addressing issue #8709.#14841
This PR follows #14834 and continues addressing issue #8709.#14841Tomatotech90 wants to merge 2 commits into
Conversation
Continues work from PR ComplianceAsCode#14834. Removes DoD-specific phrasing from 15 additional files, replacing with policy-agnostic language where the underlying security requirement applies to any organization. Also fixes pre-existing trailing whitespace in var_smartcard_drivers.var and banner_etc_profiled_ssh_confirm/rule.yml found during lint verification. Updates ComplianceAsCode#8709
|
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 Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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
left a comment
Mab879
left a comment
There was a problem hiding this comment.
Thanks for the PR. I have a few comments.
| is commented out, or is missing, this is a finding. | ||
|
|
||
| rationale: |- | ||
| DoD Information Systems are required to use FIPS-approved cryptographic hash |
There was a problem hiding this comment.
The rules with _stig can be keep the DoD wording as they specifically for the STIG.
| {{{ full_name }}} must implement certificate status checking for multifactor authentication. | ||
|
|
||
| vuldiscussion: |- | ||
| Using an authentication device, such as a DoD Common Access Card (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, credentials stored on the authentication device will not be affected. |
There was a problem hiding this comment.
The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.
| default text with a message compliant with the local site policy or a legal | ||
| disclaimer. | ||
| The DoD required text is either: |
There was a problem hiding this comment.
If we truly removing DOD specific content we should remove the required text.,
| default text with a message compliant with the local site policy or a legal | ||
| disclaimer. | ||
| The DoD required text is either: |
| This rule verifies that that the SSH login confirmation banner is set | ||
| correctly. | ||
|
|
||
| The DoD required text is: |
| A {{{ full_name }}} firewall must employ a deny-all, allow-by-exception policy for allowing connections to other systems. | ||
|
|
||
| vuldiscussion: |- | ||
| Failure to restrict network connectivity only to authorized systems permits inbound connections from malicious systems. It also permits outbound connections that may facilitate exfiltration of DoD data. |
There was a problem hiding this comment.
The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.
|
|
||
| description: |- | ||
| Choose the Smart Card Driver in use by your organization. | ||
| <br />For DoD, choose the <tt>cac</tt> driver. |
There was a problem hiding this comment.
This is some helpful text, propose to keep.
| {{{ full_name }}} pam_unix.so module must be configured in the system-auth file to use a FIPS 140-3 approved cryptographic hashing algorithm for system authentication. | ||
|
|
||
| vuldiscussion: |- | ||
| Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised. |
There was a problem hiding this comment.
The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.
|
|
||
| {{{ full_name }}} systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. | ||
|
|
||
| FIPS 140-3 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system. |
There was a problem hiding this comment.
The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.
|
|
||
| The "minlen", sometimes noted as minimum length, acts as a "score" of complexity based on the credit components of the "pwquality" module. By setting the credit components to a negative value, not only will those components be required, they will not count towards the total "score" of "minlen". This will enable "minlen" to require a 15-character minimum. | ||
|
|
||
| The DoD minimum password requirement is 15 characters. |
There was a problem hiding this comment.
The STIG policy content, should keep the DOD wording as this is a mirror of the upstream STIG content.
There was a problem hiding this comment.
Thanks, and I will do the changes.
|
@Mab879 Thanks for the detailed feedback. I've made the following changes: ssh_use_approved_macs_ordered_stig/rule.yml Each of these now matches the original upstream text exactly. I verified this with a direct diff against upstream/master for each file. banner_etc_issue_net/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. 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. configure_gnutls_tls_crypto_policy/rule.yml |
Revert 8 STIG-specific files to original DoD wording, since these mirror upstream STIG content per maintainer feedback: - 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 Remove the required banner text entirely from 3 banner files, since rewording the lead-in sentence alone was not sufficient: - banner_etc_issue_net/rule.yml - banner_etc_motd/rule.yml - banner_etc_gdm_banner/rule.yml banner_etc_profiled_ssh_confirm/rule.yml is left unchanged in this commit. Its required text is embedded in a shell script's read -p prompt rather than a standalone block, and I want maintainer input before deciding whether to remove the script or just the wording.
2 participants
Description
This PR follows #14834 and continues addressing issue #8709.
After #14834 was merged, I reviewed the remaining files from the maintainer's grep list and 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.ymlhttpd_public_resources_not_shared/rule.ymlensure_gpgcheck_repo_metadata/rule.ymlFiles reverted to original DoD wording, since they mirror upstream STIG content:
ssh_use_approved_macs_ordered_stig/rule.ymlset_firewalld_default_zone/policy/stig/shared.ymlharden_sshd_macs_opensshserver_conf_crypto_policy/policy/stig/shared.ymlset_password_hashing_algorithm_systemauth/policy/stig/shared.ymlset_password_hashing_algorithm_systemauth/policy/stig/rhel10.ymlaccounts_password_pam_minlen/policy/stig/shared.ymlsssd_certificate_verification/policy/stig/shared.ymlvar_smartcard_drivers.varBanner 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: left unchanged. The required text is embedded in a shell script'sread -pprompt rather than a standalone block. Would you prefer the script removed entirely, or the wording replaced while keeping the script structure? I don't have enough context on the check to decide this on my own.Pre-existing trailing whitespace in
var_smartcard_drivers.varwas 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, with no response yet. Guidance would be appreciated before I touch 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.varThese 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.ymlThese 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.ymlThese rules reference DoD-specific networks (NIPRNet/SIPRNet), DoD-mandated exemption lists, or DoD-mandated tooling. The NIPRNet/SIPRNet references appear in
srg_requirementfields that quote the STIG SRG verbatim. Should those be left as-is since they are direct SRG quotes? Is there a generic equivalent formcafee_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 three banner files, where the required-text block was removed from the description field.
(no update yet)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