adding "fix"es to the xccdf

Shawn Wells shawn at redhat.com
Wed Feb 6 05:05:00 UTC 2013


On 2/4/13 5:40 PM, Jeffrey Blank wrote:
>> At some point it makes sense to create a unique fix directory, similar
>> >to the OVAL check directory, and drop unique scripts in there to be
>> >merged during the make process.
> Depends on what output you're making, but that's the basic idea.
>
>> >We just have to convince Jeff to drop
>> >his objections on including fix content... ;)
> Well, my objection was toward automated fix content preceding the
> creation and QA of guidance/checking content.  High-quality guidance and
> checking content is very hard to create, and it is also difficult to
> create remediation content for baselines which do not exist.
>
> But anyway, looks like the time is getting closer.
> Several important scoping questions must be considered:
>
> 1) Is the intent to provide a collection of remediation modules/scripts,
> which are parameterized when needed, and which would be activated
> through some kind of selection mechanism?  IIRC, this would be different
> from the current Aqueduct approach, which is to maintain separate
> directories for each baseline.

Given that our rules can be part of multiple profiles, and assuming a 
parametrized approach, there seems a clear path to support multiple 
baselines.

IMO we'd want to create a "/fixes" directory analogous to /checks: 
Individualized files which we aggregate together during the build.


> 2) Is there interest in providing remediation modules in formats other
> than bash, such as Puppet or Chef?  Whether we wanted such flexibility
> would influence our approach.

I *want* to use Puppet.

However, it seems more important to use a remediation technology that 
will be widely adopted. While Puppet is in RHEL EPEL, it's not shipped 
on the disk. This has caused several issues with shops not being able to 
run it, as Puppet isn't officially supported.


> 3) Would we prioritize (or only) create fixes for those things that do
> not pass "out of the box"?
If there is an XCCDF rule there should be a corresponding OVAL and 
remediation.


> 4) Should much/any attention be paid to CRE?
> It may be worth a quick glance at Appendix C here:
> http://csrc.nist.gov/publications/drafts/nistir-7831/Draft-NISTIR-7831.pdf
> Is it desired as an output?
Given the lack of maturity around CRE it seems not worth the time (yet?).


> I'm just trying to think aloud about what this would look like, since I
> think it's really important for us to synchronize on goals before
> building anything.
>
> I also consider some familiarity with scap-security-guide, Aqueduct, and
> secstate to be prerequisites for technical discussion.  I need to review
> the Aqueduct and secstate code sometime over the next week to
> familiarize myself with their approaches.  At present I would not feel
> qualified to start integrating code/scripts for remediation.

One constant feedback of current remediation scripts is they do not have 
"rollback." Do we want to assume that responsibility?



> (I'm not sure if it's proper Netiquette to email multiple lists at once,
> but this is certainly relevant to Aqueduct and OpenSCAP too.)
http://www.youtube.com/watch?v=EgIpj25iMDw



More information about the scap-security-guide mailing list