Remediation Scripts

Simon Lukasik slukasik at redhat.com
Tue Mar 26 14:23:55 UTC 2013


On 03/26/2013 03:14 AM, Shawn Wells 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.

Guys, thanks for bringing this up. I also the one that still believes
that on-list discussion can be valuable.


Fist of all, I agree with Francisco that having the fix content
(scripts) separated from XCCDF file would great. On the other hand, I
work on implementing the tool so I need to stick with the standard as
much as possible.

That being said, I added support for embedded scripts to openscap
following NISTIR-7275r4. Note that some of the aspects of remediation
are not specified in the great detail in NISTIR-72775r4. When
implementing the tool, I always preferred defensive approach over features.

In the long run, we may need to separate XCCDF and scripts again, but
for that I would like to see some support from the standard bodies.
Maybe we just need the NISTIR-7670 to be amended for work with scripts
(as opposed to the OVRL). Or we can use the "urn:xccdf:fix:urls" and
design own file format ... but I am not fond of that json usage.


Regarding the selection of fix languages, I don't think that you need to
use the only one language exclusively. If some goal is easier to achieve
with python than in bash, go for it. OpenSCAP will handle it correctly.
Python fix will not be issued unless the python interpreter is available.


On 03/26/2013 05:18 AM, Francisco Slavin wrote:
> This conversation gets a bit muddied by the definition of
> 'checking'.  The fix scripts should not be written to check system
> state at the granularity targeted by OVAL checks.  But they should
> still be doing basic error checking and error handling.  As such they
> would need to report errors and the tool calling out to the fix
> scripts would have to act on them, so some common dictionary of
> return code values may be useful.  Using CEE has been brought up in
> the past as well.  Basically whichever front-end is calling out to
> SCAP libraries for check content gets its fine-grained error
> reporting taken care of thanks to those libraries; but the fix side
> will be done ad-hoc and having granular error reporting would still
> be a huge benefit.  The quick-and-dirty way would simply be to have
> 'success' and 'fail' RCs defined and to capture the stderr and stdout
> of the script according to whether it passes or fails, and what
> degree of logging your tool is set to (debug/verbose/etc.).  This
> last approach is what SecState is currently doing.

I feel like some of these question might be answered by current
implementation in OpenSCAP:

 - The output of script is captured and stored
   in the rule-result/message element
 - The output of script has no effect on evaluation result
 - The return value of script is captured and stored
   in the rule-result/message element
 - The return value of script has no effect on evaluation
   result.
 - The fix scripts are applied only for those rules which has 'fail'
   result from OVAL check.
 - For those the OVAL check is evaluated twice. The second run is
   immediately after the fix is applied. The result of second OVAL
   evaluation decides between 'fixed' and 'error' result.
 - That assures that fix element is not run twice for the same
   TestResult

I hope this helps,

-- 
Simon Lukasik
Security Technologies


More information about the scap-security-guide mailing list