Fix gui banner path for UBTU-20-010002 and simplify

[dexterle]

Description:

• Fix UBTU-20-010002
• Simplify OVAL path for OS and add Ubuntu specific path
• Add ubuntu specific ansible remediation
• Fix rule descriptions

Rationale:

• Part of Ubuntu 20.04 DISA STIG v1r9 profile upgrade
• https://github.com/ComplianceAsCode/content/pull/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-010002"

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

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/

[dexterle]

feedback: https://github.com/ComplianceAsCode/content/pull/10738/commits/2060bc6dd3fffa0011ae4a3280d5a4865863fe64#r1318941116

[openshift-ci[bot]]

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[bot]]

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

[github-actions[bot]]

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

Click here to see the full diff

New content has different text for rule 'xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled'.
--- xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled
+++ xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled
@@ -8,6 +8,7 @@
 screen by setting banner-message-enable to true.
 
 To enable, add or edit banner-message-enable to
+
 /etc/dconf/db/gdm.d/00-security-settings. For example:
 [org/gnome/login-screen]
 banner-message-enable=true
@@ -15,6 +16,7 @@
 /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification.
 For example:
 /org/gnome/login-screen/banner-message-enable
+
 After the settings have been set, run dconf update.
 The banner text must also be set.
 

OCIL for rule 'xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled' differs.
--- ocil:ssg-dconf_gnome_banner_enabled_ocil:questionnaire:1
+++ ocil:ssg-dconf_gnome_banner_enabled_ocil:questionnaire:1
@@ -1,4 +1,5 @@
 To ensure a login warning banner is enabled, run the following:
+
 $ grep banner-message-enable /etc/dconf/db/gdm.d/*
 If properly configured, the output should be true.
 To ensure a login warning banner is locked and cannot be changed by a user, run the following:

[codeclimate[bot]]

Code Climate has analyzed commit 7c7be082 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 53.8% (0.0% change).

View more on Code Climate.

[dodys]

I added a tag to not merge this PR, I need to do some more testing on it, as I think the DISA STIG way of setting banner is just one of the different ways to do it

[mpurg]

I did some testing on this.

While both implementations give the correct result, I feel that the original implementation (setting the banner in /etc/dconf/...) is superior as it:

• takes precedence over the proposed implementation (configuration defined in /etc/gdm3/...)
• allows locking the configuration from user modification
• is transferable across other benchmarks (e.g. Ubuntu CIS 20.04/22.04, RHEL 8 STIG)

I suggest we keep the original implementation, introducing a slight deviation from instructions in the STIG manual. I will propose to DISA to modify the rule accordingly.

[jan-cerny]

ping

[dodys]

dexterle reached out last week about continuing work on this PRs, and I've asked to open new ones for a clean state. Therefore closing this one.