I've been meaning to chime in on this topic but have been extremely busy as of late.Thanks for taking time to contribute to the conversation! Many people seem to think commuting code is the only way to contribute; getting engaged in conversations is *extremely* valuable.
I have already been writing scripts based off the SSG output and slowly working towards something usable. The main thing I have been working towards follows these 3 rules when it comes to remediation..
1: If we need to change a file, make a time stamped copy before changing the file.2: If a file is modified, lets put a comment on what was done with a date and SSG Rule ID3: Write stdout and stderr to a log file. Whatever happens, I want to know about it.
From a performance standpoint you're correct, overhead should be minimal. The counterpoint (which is where I personally fall) has to do with the longterm support of the code snippets.The other things I have done is written all the the remediations into in file specific scripts like audit.rules.sh with their own checks. Check if its there, check if it is the right value, ect. I know its redundant to double check but it hurts nothing to do so in my book but also leaves the option to run the scripts separately.
$ ls RHEL6/input/checks/ | wc -l
434
I figured at a bare minimum with what I am working on based off the SSG findings of a base install, these scripts could be kickstarted to wrap up the base install. I also agree to keep it all bash. Consider it from a minimal install and then built up from there. I would have to test out python and see if it would work from my images I have to ensure there are no deps involved. If it was a big system already in production then maybe python might be applicable from a resource perspective.
Patches welcome!
Not sure if what I am presently doing is being reiterated buy other people but thought I would throw my 2 cents in. Seems like a good time to pool resources.