ansible-lockdown / ubuntu22-cis-audit Goto Github PK

Describe the Issue
Some checks are not reported because of how goss works - see goss-org/goss#743

Expected Behavior
I'm not sure if there is anything you can do on your side except completely redo some of the checks to avoid overlapping names

Actual Behavior
goss produces output with different checks on different machines.

Control(s) Affected
have not time to go through all but eg. in section 1.4 and 1.6 the checks that are testing same grub.cfg file are overlapping

Environment (please complete the following information):

• branch being used: I have seen this issue in eg main and benchmark-v1.0.0
• goss v0.3.23

Possible Solution
If we do not want to consolidate the checks (and I dont believe thats a good idea) then only workaround I was able to come up with is to run goss independently for each section(s) we know are overlapping and combine all the results

Describe the Issue

This error occurs when the benchmark attempts to enforce a single time synchronization daemon, specifically the systemd-timesyncd service.

Expected Behavior

amazon-ebs.AWS_AMI_Builder: TASK [UBUNTU22-CIS : 2.1.1.1 | PATCH | Ensure a single time synchronization daemon is in use | mask service] *** amazon-ebs.AWS_AMI_Builder: fatal: [127.0.0.1]: FAILED! => {"changed": false, "msg": "Could not find the requested service systemd-timesyncd.service: host"}

my configuration is:

ubtu22cis_time_sync_tool: ntp ubtu22cis_time_servers: - name: "169.254.169.123" options: "minpoll 8"

But sometimes the benchmark crashes this step.

Actual Behavior
The benchmark process fails with the following error message:
Could not find the requested service systemd-timesyncd.service: host

Control(s) Affected
This issue affects Control 2.1.1.1 of the CIS benchmark, which is related to time synchronization and the enforcement of a single time synchronization daemon.

Environment (please complete the following information):

• branch being used: [devel
• Ansible Version: 2.15.4
• Host Python Version: [Python 3.10.12]
• Ansible Server Python Version: [3.10.12]
• Additional Details:

Additional Notes
Anything additional goes here

Possible Solution

Heya,

Thank you very much for your work!

Just an FYI in case you weren't aware, it looks like the 22.04 benchmark has been released (1.0.0), unsure if anything needs updating.

Thanks again!

Describe the Issue
UBUNTU2-CIS-Audit runs a check using section_5/cis_5.4/cis_5.4.5.yml which is executing cat /etc/shadow | awk -F':' '{print $2}' | grep -Ev '\$y\$|\*!|!|\*'

Expected Behavior
Audit step success should be indicated when the above command returns nothing to stdout and an exit-code of '1'

[redacted]@[redacted]:/opt/UBUNTU22-CIS-Audit$ sudo cat /etc/shadow | awk -F':' '{print $2}' | grep -Ev '\$y\$|\*!|!|\*'
[redacted]@[redacted]:/opt/UBUNTU22-CIS-Audit$ echo $?
1

Actual Behavior
Only an exit-code of '0' is set up to be accepted, so the audit fails this step.

Environment (please complete the following information):

• branch being used: improvements
• Ansible Version: core 2.15.4
• Host Python Version: Python 3.10.12
• Ansible Server Python Version: Python 3.9.16

Describe the Issue
Audit 1.4.3 | Ensure authentication required for single user mode runs the following grep regex against /etc/shadow:
grep -Eq '^root:\$[0-9]' /etc/shadow || echo "Root is locked", which is identical to the recommendation from CIS.

However, if the root password is set but encrypted with Yescrypt, the above grep statement will fail and give a false negative to the audit.

Expected Behavior
Audit 1.4.3 should not fail if the root password has been set

Actual Behavior
If encrypted using Yescrypt (and stored in /etc/shadow beginning: root:$y$) the audit fails.

Control(s) Affected
1.4.3

Environment (please complete the following information):

• branch being used: improvements
• Ansible Version: core 2.15.4
• Host Python Version: Python 3.10.12
• Ansible Server Python Version: Python 3.9.16

Possible Solution
Change test to: grep -Eq '^root:\$[0-9y]' /etc/shadow || echo "Root is locked" to support Yescrypt

Describe the Issue
Error: could not read json data in UBUNTU22-CIS-Audit/section_6/cis_6.2/cis_6.2.3.yml: yaml: unmarshal errors:
line 8: mapping key "or" already defined at line 7

Expected Behavior
An error should not be thrown.

Actual Behavior
The error message above is pretty obviuos.

Possible Solution
Remove the extra or: in the file.

In 'cis-5.2.2 | Ensure sudo commands use pty | Config' there is an error .

This check is a bad check since in is not possible to get that output from that command (the regex expected does not match the one requested) therefore it will always fail.

Since the exec command is:
"grep -Ei "^use_pty" /etc/sudoers"
while the expected output is:
"/^Defaults.*\suse_pty/"
it cannot pass.

The expected behaviour will be to use a regex that can match the the expected output
for axample- "/^Defaults.*\suse_pty/"

This affects the trust in the UBUNTU-CIS-Audit testing.

• branch being used: [e.g. devel] also in main
• Ansible Version: [e.g. 2.10]
• Host Python Version: [e.g. Python 3.7.6]
• Ansible Server Python Version: [e.g. Python 3.7.6]

It seems this test is still looking for cramfs and /bin/true instead of /bin/false

https://github.com/ansible-lockdown/UBUNTU22-CIS-Audit/blob/main/section_1/cis_1.1/cis_1.1.24.yml

Is this correct ?

This is my first time trying to use the goss binary to do an audit run. When I run it, I get the error in the subject. The command I'm using is:

goss --vars UBUNTU22-CIS-Audit-cis_release/vars/CIS.yml -g UBUNTU22-CIS-Audit-cis_release/goss.yml validate

The test for the machine_uuid that sets the host_machine_uuid variable runs just fine in the terminal.

Am I doing something incorrectly?

Sorry about this question, I used the "remediate ansible" version and it's really great.

Now I would like to be able to run tests against the servers, as I read the remediation Ansible is not recommended for testing, here I am reading about Goss.

How does this work ? Can I run it from ansible ? Or do I have to run from each server

Sorry about this simple question but "goss" is very new for me.

6.1.9 should be another rule according to the CIS_Ubuntu_22.04_Benchmark v1.0.0 " Ensure no world writable files exist

A lot of sections for level2 server/workstation have no nested if structure to avoid templating them in if level 2. eg:
{{ if .Vars.ubtu22cis_level_2 }}

There are too many to list but it causes the audit to say a number of tasks have failed because of it, when running the playbook at a level1-server standard.

I recommend going through each section and applying that if statement to any that are for level 2 only. The level 1 check by my understanding is implicit as a level 2 server needs to also be at a level 1 standard, so there shouldn't be any if statements for level 1, as all the tasks set at a level 1 standard will need to run either for level 1 or 2.