Tasks need to be refactored into YAML literal
juliedavila opened this issue · 15 comments
From this:
- name: V-38677 High The NFS server must not have the insecure file locking option enabled
replace: dest=/etc/exports regexp='insecure_locks'
tags: [ 'cat1' , 'V-38677' , 'nfs' ]to this:
- name: V-38677 High The NFS server must not have the insecure file locking option enabled
replace:
dest: /etc/exports
regexp: 'insecure_locks'
tags: [ 'cat1' , 'V-38677' , 'nfs' ]I've been wanting to do this for some time. Do you want all the tasks to use YAML literal syntax? Sometimes I find it's more concise to use Ansible's one line syntax.
Also, are you ok with the tag formatting or you would rather those be in multi-line list format?
I do want all tasks to use YAML literal. I agree that the one line may look cleaner at times but I err on the side of wanting to keep it pure (or 'real') YAML. As far as tags, I'm okay with keeping them in brackets as that is still YAML literal but I would prefer for them to be multi-line.
On a side note, I'll likely be pushing out a contributions guide to the repo today to clarify a few new standards.
Understood. I'll work on refactoring the tasks.
Cool, if you want, feel free until the next commit which will have cat1.yml refactored. Or alternatively, take a look at my fork at cat1.yml and you can see the new style. Doing YAML literal, inclusion of 'audit' tasks w/register (even if not being used by subsequent tasks, and ensuring that tasks execute in sequence by vuln_id as well.
I took a look at the refactor branch in your fork. I really like where you're going with the new format. Looks great. My only question is what is the third field in | HIGH | V-123456 | PATCH |? It looks like AUDIT indicates a check/registered var, and PATCH indicates a change. Will there ever be any other values in this field? I just want to be consistent with what you have in mind.
Actually, the more I look at it, it seems this may be working towards a "check" mode and a "remediate" mode of the role, something I originally didn't want to tackle since I figured other auditing tools would be used to discover the gaps that need remediating. It was beyond my initial ambition, but I'm thrilled to see there may be a way to make Ansible do the checking sans fixing. This just gets better by the day. 😄
Regarding tasks in sequence by vuln_id, is there a simple way to get the STIGs sorted that way? When I created all the initial tasks, they were in order as they appear on stigviewer.com — I used that as my to-do list. If I could get them in that order to begin with, it would save manual reordering later on (unless you have a script to sort YAML by keyword or tag). I'm open to suggestions for STIG viewing tools.
I use the DISA STIG viewer tool provides here. http://iase.disa.mil/stigs/Pages/stig-viewing-guidance.aspx
It's a simple Java tool that isn't without its problems but it should allow you to sort/etc.
Oh that actually answers something I was going to ask @samdoran. I have a particular challenge. You see, in stigviewer.com, they have V-38666 for example, which is The system must use and update a DoD-approved virus scan program. However, using the latest rev8 xccdf directly from the DISA IASE site, that rule does not come up in the view, along with others like V-38668 (ctrl alt delete sequence). I obviously lean towards what comes out of DISA's site directly, but I'm still confused as to why there is that discrepancy.
@samdoran to your other question, currently, that third field is just AUDIT or PATCH, but I'm open to any addition that makes sense. Also, the style is further explained here: https://github.com/ansible/ansible-lockdown/blob/master/CONTRIBUTING.md
For AUDIT, it must always be registered, b/c part of the refactor will include the creation of a text report (via jinja2) with an enumeration of the rules and current level of compliance for each rule.
@defionscode You're viewing the rev8 content in the Java stigviewer app and you don't see V-38666/V-38668? I see them when I use the latest stigviewer 2.0 app. Also as a note the stigviewer website seems to still be using rev6 of the STIG that was released back in May.
Hmm no I don't see them, but Im on viewer 1.2, I'll upgrade and see if that does the trick. So odd.
Ok, so for documentation purposes the issue was found. There are two places on the DISA site with scap content for RHEL6 STIG Rev8.
The one with the missing rules
http://iase.disa.mil/stigs/scap/Pages/index.aspx
The complete one
http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx
I have no idea why this is, but it is.
@shepdelacreme I've used that Java tool in the past but have no love for it. I guess I'll go back to using that since it gets the job done.
@defionscode So I think you solved your problem? Looks like the answer is "Consistency is hard". 😉
I believe this is now complete. @defionscode Ok to close?
Yep it's good to close
On Wednesday, July 27, 2016, Sam Doran notifications@github.com wrote:
I believe this is now complete. @defionscode
https://github.com/defionscode Ok to close?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MindPointGroup/RHEL6-STIG/issues/29#issuecomment-235746078,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEcrYp_jViZ3kFcPhpL-PV3dmxRKtpCPks5qZ-EugaJpZM4FxTBu
.