----- Original Message -----
On 3/13/12 9:44 PM, Steve Grubb wrote:
> On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
>> > A nicely loaded question.
>> >
>> > As you've noticed, we don't have any<fix> tags.
>> > Such commands, when available, are just in the<description> or
>> > possibly
>> > <rationale>, and marked up with xhtml.
>> >
>> > I also might expect there to be plenty of<Rule>s which simply
>> > won't
>> > have<fix> tags (such as edits to configuration files like
>> > pam.d/system-auth or sshd_config, or disk partitioning
>> > instructions).
>> > On the plus side, it would obviously be a cheap/easy way to
>> > annotate
>> > remediation instructions. On the minus side, I see it as
>> > leading to
>> > sed/awk in some of our output documents, and think this will
>> > make them
>> > less approachable/comprehensible. (I'm certainly fine with it
>> > being
>> > there, and hidden.)
>> >
>> > Is there a project/effort/output which would benefit from<fix>
>> > tags?
> Yes. openscap can generate shell scripts from<fix> tags. The
> gentoo demo shows
> this. The aqueduct project is creating remediation scripts in
> shell. So, it
> sounds like we ought to work towards one document with guidance,
> check, and fix
> so that we can make remediation easy.
FWIW, a big +1 to this.
> There are some fixes that are hard. I'd like to say we should
> incorprate the easy
> ones and identify the hard ones. Whene we have several of these,
> then we can
> start looking for how to solve the hard problems.
I'm not to concerned about the hard fixes, largely as they've already
been addressed through CLIP and/or Aqueduct. For example, DoDIIS open
sourced their baseline (accredited to PL3) and we can pull a good bit
from that.
Note that Aqueduct didn't address many of the hard fixes depending upon how you define
hard.
For instance, we do what we can via automated remediation (prod) and save the rest for
manual checks (manual-checks)...
http://svn.fedorahosted.org/svn/aqueduct/trunk/compliance/Bash/STIG/rhel-...
If you want, you can poke around the prod directory to see how we do the remediation for
each STIG configuration element. One design goal is to allow the script to be run
multiple times without making things crufty. This makes the scripts more complex, but the
benefit is that they are smarter.
In my mind, these scripts look a lot like what /could/ be output from oscap using
<fix> tags. I wonder if review of the Aqueduct content as examples could help ease
the addition of <fix> content in SSG?
Side note: We made the decision for the time being to use bash instead of Puppet since not
all DAAs allow code from community supported sources (i.e., Puppet from EPEL). As Red
Hat's next generation systems management tools may include general commercial support
for Puppet, Aqueduct will re-evaluate its position and act accordingly.
Good discussion!
Dave
--
David D. Egts, RHCA, RHCSS #805007796228001
Principal Architect, Red Hat, Inc.