question about fix-common code

[Jeffrey Blank]

Francisco, Shawn,

What was your thinking behind the common-fix elements?
Please also see (shortly) my new patches for fix insertion.
I've re-written the fix insertion stuff.  So that people can "declare"
their use of particular environment variables in bash (using a bash
function).

Then the reworked combinefixes.py will pick up on the declaration and
assign an XCCDF <sub idref/> to that variable.  <sub idref/> is how oscap
supports inserting particular values inside a fix.

For unit testing (still incomplete), the bash function "needs" should grab
the right value from XCCDF and populate it accordingly.

Do we still need the fix-common elements, to insert them into the XCCDF?
I like to delete unused code.

Jeff

[Francisco Slavin]

On Sunday, June 02, 2013 1:57 PM, Jeff Blank wrote: 
>  Francisco, Shawn,
>  What was your thinking behind the common-fix elements? 
I believe those elements
were an attempt at allowing for function re-use.  The inspiration was a set of examples
posted to this list by Simon Lukasik (of OpenSCAP fame).  The discussion that led up to my
patch was in this thread:
https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-April/0...


>  Please also see (shortly) my new patches for fix insertion.
>  I've re-written the fix insertion stuff.  So that people can "declare"
> their use of particular environment variables in bash (using a bash function).
>  Then the reworked combinefixes.py will pick up on the declaration and assign an XCCDF
> <sub idref/> to that variable.  <sub idref/> is how oscap supports inserting
> particular values inside a fix. 
>  For unit testing (still incomplete), the bash function "needs" should grab the
> right value from XCCDF and populate it accordingly.
>  Do we still need the fix-common elements, to insert them into the XCCDF?
>  I like to delete unused code. 
I need to look through your new patches to properly respond here.  The original goal was
to populate some top-level <plain-text> elements with common functions.  Per
Simon's examples, the <sub idref/> can refer directly to these
<plain-text> elements.  This follows the way Mike P's original SSG-targeted
remediation scripts were authored in Aqueduct:
https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG/dev
Where there were a series of scripts ending in "common" which were referenced as
appropriate by the other ".sh" scripts.
My approach was just to drop all of the "common" content into <plain-text>
elements and have the ".sh" content be specific to individual <fix>
elements. 

 - Francisco

>  Jeff

[Jeffrey Blank]

Thanks for the reminder on mailing list posts!

Ah, okay, I was wondering how the plain-text was getting properly
associated/inserted with the individual fixes inside the XCCDF; this
explains it.  My newer combinefixes.py does not yet solve that problem,
but it certainly makes sense for it to do so.

Was there any support for parameters in your scripts on Aqueduct, or was
it STIG-hardcoded?




On 06/03/2013 02:41 PM, Francisco Slavin wrote:
>  On Sunday, June 02, 2013 1:57 PM, Jeff Blank wrote: 
> > Francisco, Shawn,
> > What was your thinking behind the common-fix elements?
>  I believe those elements were an attempt at allowing for function re-use.  The
> inspiration was a set of examples posted to this list by Simon Lukasik (of OpenSCAP fame).
>  The discussion that led up to my patch was in this thread:
>  https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-April/0...
>  
>  
> > Please also see (shortly) my new patches for fix insertion.
> > I've re-written the fix insertion stuff.  So that people can "declare"
> their use of particular environment variables in bash (using a bash function).
> > Then the reworked combinefixes.py will pick up on the declaration and assign an XCCDF
> <sub idref/> to that variable.  <sub idref/> is how oscap supports inserting
> particular values inside a fix. 
> > For unit testing (still incomplete), the bash function "needs" should grab
> the right value from XCCDF and populate it accordingly.
> > Do we still need the fix-common elements, to insert them into the XCCDF?
> > I like to delete unused code.
>  
>  I need to look through your new patches to properly respond here.  The original goal was
> to populate some top-level <plain-text> elements with common functions.  Per
> Simon's examples, the <sub idref/> can refer directly to these
> <plain-text> elements.  This follows the way Mike P's original SSG-targeted
> remediation scripts were authored in Aqueduct:
>  https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG/dev
>  Where there were a series of scripts ending in "common" which were referenced
> as appropriate by the other ".sh" scripts.
>  My approach was just to drop all of the "common" content into
> <plain-text> elements and have the ".sh" content be specific to individual
> <fix> elements. 
>  
>   - Francisco
>  
> > Jeff
>  _______________________________________________
>  scap-security-guide mailing list
>  scap-security-guide(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>

[Vincent Passaro]

The scripts in Aqueduct are hard coded (rhel 5).

Vince



-------- Original message --------
From: Jeffrey Blank <blank(a)eclipse.ncsc.mil&gt;
Date: 06/03/2013 5:32 PM (GMT-06:00)
To: scap-security-guide(a)lists.fedorahosted.org
Subject: Re: question about fix-common code


Thanks for the reminder on mailing list posts!

Ah, okay, I was wondering how the plain-text was getting properly
associated/inserted with the individual fixes inside the XCCDF; this
explains it.  My newer combinefixes.py does not yet solve that problem,
but it certainly makes sense for it to do so.

Was there any support for parameters in your scripts on Aqueduct, or was
it STIG-hardcoded?




On 06/03/2013 02:41 PM, Francisco Slavin wrote:
>  On Sunday, June 02, 2013 1:57 PM, Jeff Blank wrote:
> > Francisco, Shawn,
> > What was your thinking behind the common-fix elements?
>  I believe those elements were an attempt at allowing for function re-use.  The
> inspiration was a set of examples posted to this list by Simon Lukasik (of OpenSCAP fame).
>  The discussion that led up to my patch was in this thread:
>  https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-April/0...
>
>
> > Please also see (shortly) my new patches for fix insertion.
> > I've re-written the fix insertion stuff.  So that people can "declare"
> their use of particular environment variables in bash (using a bash function).
> > Then the reworked combinefixes.py will pick up on the declaration and assign an XCCDF
> <sub idref/> to that variable.  <sub idref/> is how oscap supports inserting
> particular values inside a fix.
> > For unit testing (still incomplete), the bash function "needs" should grab
> the right value from XCCDF and populate it accordingly.
> > Do we still need the fix-common elements, to insert them into the XCCDF?
> > I like to delete unused code.
>
>  I need to look through your new patches to properly respond here.  The original goal was
> to populate some top-level <plain-text> elements with common functions.  Per
> Simon's examples, the <sub idref/> can refer directly to these
> <plain-text> elements.  This follows the way Mike P's original SSG-targeted
> remediation scripts were authored in Aqueduct:
>  https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG/dev
>  Where there were a series of scripts ending in "common" which were referenced
> as appropriate by the other ".sh" scripts.
>  My approach was just to drop all of the "common" content into
> <plain-text> elements and have the ".sh" content be specific to individual
> <fix> elements.
>
>   - Francisco
>
> > Jeff
>  _______________________________________________
>  scap-security-guide mailing list
>  scap-security-guide(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>  
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide