On 3/29/13 3:08 PM, Aaron Lamb wrote:
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 ID
3: Write stdout and stderr to a log file.  Whatever happens, I want to know about it.

I agree with the logic behind #3, however note that output is captured by OpenSCAP natively (thus the scripts don't need their own log files). Check out Simon Lukasik's awesome writeup here:

Specifically, the <message> tags within <rule-result>'s

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.
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.

Currently there are some 430 OVAL checks:
$ ls RHEL6/input/checks/ | wc -l

Lets say, on average, the conditional check is 1.5 lines of code. Over 434 checks, that's an extra 651 lines of code we'd have to QA and support. Why bother when OVAL does this for us?

Certain scripts will have checks in them, such as sysctl settings. e.g.

if (value present in /etc/sysctl.conf)
    perform sed -i
    echo value >> /etc/sysctl.conf

However, there's no reason that script should check for the need to be ran. OVAL will do this for us.

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.    

I, too, envision people wrapping the remediation scripts into their %post section.

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.
Patches welcome!

Although, as OVAL determines if a remediation is even needed, we *must* ensure the corresponding OVAL code is functioning properly before committing associated remediation code.