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