coming soon: consistency checking scripts

David Egts degts at redhat.com
Wed Mar 14 16:38:47 UTC 2012


----- 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-5-beta/

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.


More information about the scap-security-guide mailing list