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:
http://isimluk.livejournal.com/3573.html
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 <
http://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
434
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
else
echo value >> /etc/sysctl.conf
fi
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.