Remediation Scripts
Brian Millett
bmillett at gmail.com
Tue Mar 26 13:33:17 UTC 2013
On Mon, 25 Mar 2013 22:14:40 -0400
Shawn Wells <shawn at redhat.com> wrote:
> I've been taking a few off-list questions around remediation lately,
> namely from interested parties asking "where do we start?" Wanted to
> move those conversations to on-list. Here's a few of the common
> questions and my thoughts to get us started.
>
>
> (1) What language(s) should be used?
>
> IMO, bash. I'm leaning this way because it's included in *every* RHEL
> release, whereas puppet modules would require the installation of 3rd
> party software. I'd like to see as much done through 'native' tools as
> possible. There's certainly advantages to Perl (e.g., potential speed)
> however I don't think we want to assume Perl is installed on all RHEL
> machines.
>
>
> (2) Do we perform checking in the scripts?
>
> Defined further, should the scripts contain conditional checks to see if
> they should be ran?
> IMO, no. That's what OVAL is for.
>
>
> (3) Where do we begin?
>
> - Name remediation scripts after corresponding XCCDF rule
> - Build process includes them into final ssg-rhel6-xccdf.xml
>
> Known challenge on passing XCCDF variables through to the scripts,
> however I wouldn't let this hold us up. Still *tons* of work to be done
> while this gets sorted.
>
>
> There's a good bit of RHEL6 content in the Aqueduct project that (I
> believe) Tresys committed. Perhaps we could reuse those scripts?
Agree with your points above.
As for scripts, I've got +- 400 scripts that I'm ready to commit, but being
new to the git process, I do not want to make a mistake sending all at once to
the list as patches.
There is also a new combinefixes.py script that fixes having the characters
"<", ">", and "&" in them.
How should I proceed?
Thanks.
--
Brian Millett
"I hope that isn't the sign of some frailty in her."
'Why don't you check her *teeth* while you're at it?'
"Think that's a good idea?"
-- [ Na'Toth and Ivanova (re: Alisa Beldon), "Legacies"]
More information about the scap-security-guide
mailing list