Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rules contain wrong package name in STIG fields #9916

Closed
jan-cerny opened this issue Dec 1, 2022 · 3 comments
Closed

Rules contain wrong package name in STIG fields #9916

jan-cerny opened this issue Dec 1, 2022 · 3 comments
Labels
STIG STIG Benchmark related.

Comments

@jan-cerny
Copy link
Collaborator

Description of problem:

During review of #9910 we have discovered that the policy_specific_content key might contain wrong values in its subkeys values.

For example, when we build RHEL 7 content and we open the internal resolved file build/rhel7/rules/install_smartcard_packages.yml, most of the items contain the correct RHEL 7 package name pam_pkcs11. But the policy_specific_content contains openssl-pkcs11 in checktext and fixtext, and which openssl-pkcs11 isn't the correct package name.

SCAP Security Guide Version:

current upstream master as of 2022-12-01 as of HEAD 0e9c453

Operating System Version:

F 37

Steps to Reproduce:

  1. ./build_product -d rhel7
  2. cat build/rhel7/rules/install_smartcard_packages.yml

Actual Results:

openssl-pkcs11 in policy_specific_content

Expected Results:

pam_pkcs11 in policy_specific_content

Additional Information/Debugging Steps:

There was an issue with the other keys as well (see #9894 ) that manifested only when built with Python 2. But that issue seems to be caused by different thing. Our issue doesn't depend on Python version.

@jan-cerny jan-cerny added Infrastructure Our content build system STIG STIG Benchmark related. labels Dec 1, 2022
@Mab879
Copy link
Member

Mab879 commented Dec 1, 2022

So the policy_specific_content does not use variables currently. That is by design, as it makes it easier to import the changes from the spreadsheet to the repo. However, it does seem to be causing some unintended consequences, as shown here. We do have the ability to create override files like rhel7.yml.

@matejak
Copy link
Member

matejak commented Dec 2, 2022

You can see the content here: https://github.com/ComplianceAsCode/content/blob/master/linux_os/guide/system/accounts/accounts-physical/screen_locking/smart_card_login/install_smartcard_packages/policy/stig/shared.yml

Therefore, mystery is solved - it's all literal strings. So I take the "infrastructure" label out, but is it a STIG issue? I feel that in these cases, we should have OS-specific STIG files s.a. the mentioned rhel7.yml, because the policy specific content is propagated to the compiled rule, and RHEL7 STIG content somehow contradicts the let's say RHEL8 rule.

@matejak matejak removed the Infrastructure Our content build system label Dec 2, 2022
@Mab879
Copy link
Member

Mab879 commented Dec 19, 2024

RHEL 7 is no longer supported this project, closing.

@Mab879 Mab879 closed this as not planned Won't fix, can't repro, duplicate, stale Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
STIG STIG Benchmark related.
Projects
None yet
Development

No branches or pull requests

3 participants