Add remediation and OVAL for UBTU-20-010297

[dexterle]

Description:

• Fix UBTU-20-010297
• Add Ubuntu2004 Ansible and Bash remediation
• Add Ubuntu2004 OVAL Definition

Rationale:

• Part of Ubuntu 20.04 DISA STIG v1r9 profile upgrade
• Ubuntu2004 stig profile v1r9 update #10738

Review Hints:

Build the product:

./build_product ubuntu2004

To test these changes with Ansible:

ansible-playbook build/ansible/ubuntu2004-playbook-stig.yml --tags "DISA-STIG-UBTU-20-010297"

To test changes with bash, run the remediation sections: xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_kmod

Checkout Manual STIG OVAL definitions, and use software like DISA STIG Viewer to view definitions.

git checkout dexterle:add-manual-stig-ubtu-20-v1r9

This STIG can be tested with the latest Ubuntu 2004 Benchmark SCAP. For reference, please review the latest artifacts: https://public.cyber.mil/stigs/downloads/

[openshift-ci]

Hi @dexterle. 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.

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/test-infra repository.

[github-actions]

Start a new ephemeral environment with changes proposed in this pull request:

rhel8 (from CTF) Environment (using Fedora as testing environment)

Fedora Testing Environment

Oracle Linux 8 Environment

[marcusburghardt]

@dexterle , I saw you opened 41 draft PRs. We definitely appreciate your collaboration in the project, but 41 draft PRs without proper description is making the PRs queue a little messy and consequently hard to review.

Please, take a time and organize your existing PRs:

• Update the description of all PRs respecting the Project Style Guides.
• I saw many PRs are really simple but they are still set as Draft. Please, make it clear if you plan to change the draft PRs. Otherwise, move it to "Ready for Review"
  • We usually don't actively review Draft PRs and likely they are closed after some time without interaction.

I also invite you to join the Project room in Gitter:

• https://matrix.to/#/#Compliance-As-Code-The_content:gitter.im

[dexterle]

@dexterle , I saw you opened 41 draft PRs. We definitely appreciate your collaboration in the project, but 41 draft PRs without proper description is making the PRs queue a little messy and consequently hard to review.

Please, take a time and organize your existing PRs:

• Update the description of all PRs respecting the Project Style Guides.

• I saw many PRs are really simple but they are still set as Draft. Please, make it clear if you plan to change the draft PRs. Otherwise, move it to "Ready for Review"

  • We usually don't actively review Draft PRs and likely they are closed after some time without interaction.

I also invite you to join the Project room in Gitter:

• https://matrix.to/#/#Compliance-As-Code-The_content:gitter.im

@marcusburghardt , apologies for the delay on the PR updates, and thank you for your patience. I have modified all of the Ubuntu profile upgrade STIG PRs with proper descriptions and moved to "Ready for Review". I have also joined the project room in Glitter, and will spend time rebasing and testing.

[marcusburghardt]

@dexterle , I saw you opened 41 draft PRs. We definitely appreciate your collaboration in the project, but 41 draft PRs without proper description is making the PRs queue a little messy and consequently hard to review.
Please, take a time and organize your existing PRs:

• Update the description of all PRs respecting the Project Style Guides.

• I saw many PRs are really simple but they are still set as Draft. Please, make it clear if you plan to change the draft PRs. Otherwise, move it to "Ready for Review"

  • We usually don't actively review Draft PRs and likely they are closed after some time without interaction.

I also invite you to join the Project room in Gitter:

• https://matrix.to/#/#Compliance-As-Code-The_content:gitter.im

@marcusburghardt , apologies for the delay on the PR updates, and thank you for your patience. I have modified all of the Ubuntu profile upgrade STIG PRs with proper descriptions and moved to "Ready for Review". I have also joined the project room in Glitter, and will spend time rebasing and testing.

Great @dexterle. You do not need to apologize. You are getting used to the project and everything is fine. Most maintainers are on Gitter. You can also contact us there when you need any help.

[marcusburghardt]

Perhaps it is time to simplify this rule. Currently the OVAL and remediation are named to satisfy only specific products but the rule is be valid for many other products. Ideally, this rule should use the audit_rules_privileged_commands template, like other similar rules. If there is any particularity where the template is not suitable, we should unify the files using the shared name. What do you think @ComplianceAsCode/suse-maintainers , @ComplianceAsCode/ubuntu-maintainers , @ComplianceAsCode/oracle-maintainers ?

[dodys]

Perhaps it is time to simplify this rule. Currently the OVAL and remediation are named to satisfy only specific products but the rule is be valid for many other products. Ideally, this rule should use the audit_rules_privileged_commands template, like other similar rules. If there is any particularity where the template is not suitable, we should unify the files using the shared name. What do you think @ComplianceAsCode/suse-maintainers , @ComplianceAsCode/ubuntu-maintainers , @ComplianceAsCode/oracle-maintainers ?

sounds good to me
on this one specifically we (Ubuntu) could share the same remediation and oval as SUSE as the template itself doesn't match our case

[dodys]

please check our comments above

[freddieRv]

Perhaps it is time to simplify this rule. Currently the OVAL and remediation are named to satisfy only specific products but the rule is be valid for many other products. Ideally, this rule should use the audit_rules_privileged_commands template, like other similar rules.

This sounds good 👍🏻

If there is any particularity where the template is not suitable, we should unify the files using the shared name.

Looking at OL7 and OL8 STIGs, the template works for OL7. However for OL8 DISA is using a different syntax for the rules.
This is correctly shown only on the rule's yaml, but not on OVAL/Ansible/Bash:

{{%- if product in ["ol7", "rhel7", "rhel8", "rhel9"] %}}
    {{%- set kmod_audit="-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=" ~ uid_min ~ " -F auid!=unset -F key=privileged" %}}
{{%- elif product in ["ubuntu2004", "ubuntu2204"] %}}
    {{%- set kmod_audit="-w /bin/kmod -p x -k modules" %}}
{{%- else %}}
    {{%- set kmod_audit="-w /usr/bin/kmod -p x -k modules" %}}
{{%- endif %}}

This is true for a number of audit rules. If other products are in a similar position we could modify the template to accommodate both syntaxes.

[teacup-on-rockingchair]

Perhaps it is time to simplify this rule. Currently the OVAL and remediation are named to satisfy only specific products but the rule is be valid for many other products. Ideally, this rule should use the audit_rules_privileged_commands template, like other similar rules. If there is any particularity where the template is not suitable, we should unify the files using the shared name. What do you think @ComplianceAsCode/suse-maintainers , @ComplianceAsCode/ubuntu-maintainers , @ComplianceAsCode/oracle-maintainers ?

sounds good to me on this one specifically we (Ubuntu) could share the same remediation and oval as SUSE as the template itself doesn't match our case

Completely agree 👍 , let's start with shared and platform restriction there and we can add platforms as we go :)

[github-actions]

This datastream diff is auto generated by the check Compare DS/Generate Diff

Click here to see the full diff

OVAL for rule 'xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_kmod' differs.
--- oval:ssg-audit_rules_privileged_commands_kmod:def:1
+++ oval:ssg-audit_rules_privileged_commands_kmod:def:1
@@ -1,7 +1,7 @@
 criteria OR
 criteria AND
 extend_definition oval:ssg-audit_rules_augenrules:def:1
-criterion oval:ssg-test_audit_rules_privileged_commands_kmod_augenrules:tst:1
+criterion oval:ssg-test_kmod_augenrules:tst:1
 criteria AND
 extend_definition oval:ssg-audit_rules_auditctl:def:1
-criterion oval:ssg-test_audit_rules_privileged_commands_kmod_auditctl:tst:1
+criterion oval:ssg-test_kmod_auditctl:tst:1

New datastream is missing bash remediation for rule 'xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_kmod'.
New datastream is missing ansible remediation for rule 'xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_kmod'.

[codeclimate]

Code Climate has analyzed commit b28df48 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 56.9%.

View more on Code Climate.

[dodys]

@teacup-on-rockingchair could you check if this looks ok from SUSE's perspective? There are some failing tests.

[teacup-on-rockingchair]

@teacup-on-rockingchair could you check if this looks ok from SUSE's perspective? There are some failing tests.

Those seem to fail for two reasons:

• first missing package requirement in the auditclt related tests, I will add them in a separate file
• missing some patches in the testing infrastructure to recognize SLE platform, this is fixed with rebase

After that I got result 'not applicable' on those since they seem to be only machine environment relevant :)

[teacup-on-rockingchair]

👍 nice stuff

[dodys]

that also lgtm, thanks!