Couple of questions for contributing about rhel7-cis HOT 5 CLOSED

Great thanks @shepdelacreme we ended up going for template per rule, will put together a pr once I can get the last couple of rules to pass openscap. Looks like the version in rhel7 yum has got a couple of false positives

from rhel7-cis.

We are definitely open to PRs. There is some general contributing guidelines here that covers our preferred Ansible syntax (although it is a bit out of date and needs an update). https://github.com/ansible/ansible-lockdown/blob/master/CONTRIBUTING.md

SCORED and NOT_SCORED refer to the CIS benchmark itself. You can go here https://www.cisecurity.org/cis-benchmarks/ and get version 2.2.0 of the RHEL7 benchmark if you don't already have it. On page 14 of that document they outline the difference but essentially items that are marked as "Scored" are counted in the final benchmark assessment, "Not Scored" items are not and so if your system is not compliant with that item it should not lower the score from an automated scoring system like OpenSCAP.

However I don't know if that is how OpenSCAP operates and also I'm not sure how your auditor views. Some auditors will count "Not Scored" items against you.

The numbers are meaningful. They are directly tied to the item numbers in the CIS Benchmark PDF document. For instance...your example of "fix rpm file perms" is most likely check # "6.1.1 Audit system file permissions" from the CIS benchmark.

6.1.1 is not implemented yet which is why OpenSCAP is probably reporting that error back to you.
As you can see below the task runs command: /bin/true which is just a placeholder and reports back success each time. If you'd like to implement this control you would edit this placeholder task.
https://github.com/MindPointGroup/RHEL7-CIS/blob/dd23ba5df908e9415ecd2d7aa5948dff6f2f1199/tasks/section6.yml#L1-L10

from rhel7-cis.

Brilliant thanks @shepdelacreme !

from rhel7-cis.

I am implementing the notimplemented auditd rules for our site

Currently there are some lineinfile rules around the conf file and the audit.rules

To me it would make sense to use a template for several of those rules (I would like to do for the unimplemented ones) called something like cis.rules.j2 that can go in /etc/audit/rules.d/ and can have conditional blocks per rule based on variables (such as rhel7cis_rule_4_1_11 and rhel7cis_rule_4_1_11) as well as env variables (such as ansible_architecture == 'x86_64')

Would this be a welcome pr, or would there be a different way (e.g sep rules file per rule, or adding to existing audit.rules file with lineinfile) you would prefer it imlemented? To me it might make sense to have a separate file per rule called something like /etc/audit/rules.d/rhel7cis_rule_4_1_13.rule

from rhel7-cis.

@sambanks This would be a welcome PR. The method you describe with a jinja2 template file or something like what is being done in our RHEL7 STIG baseline repo would work. https://github.com/MindPointGroup/RHEL7-STIG/blob/bb4e907f718ab583470e545ffb5ce81459d3952b/tasks/fix-cat2.yml#L1212

I think I might prefer a jinja2 template approach though.

from rhel7-cis.