(altering the subject appropriately)
What about small/embedded devices. Or some medical appliances with
small
memory, augeas is simply too heavy for them. So it boils down to shell
or even C. (Maybe these devices are out of concern for this list. (?))
In fact this list is primarily concerned with security guidance and SCAP
content. If a device can run oscap, it should be able to generate a
report about the system's configuration (and whether this meets a
compliance goal).
We wish to generally remain agnostic with regard to
hardening/remediation resources. There is a variety of tools for
managing/deploying systems and the most appropriate one varies by use case.
HOWEVER, we respect the utility of Bash as a lowest common denominator.
In a recent meeting, it was decided to permit <fix> tags in
scap-security-guide and for these to include Bash content.
It was left undecided whether these tags should be inlined with the
other XCCDF content (in "shorthand" in src/input/services and
src/input/system) or if they should be kept in a separate file or files
(and then merged into the final XCCDF), perhaps linked by Rule id. The
argument for keeping it separate is that some of the Bash content may
turn into several lines, and separation may simplify matters. This may
also be more consistent with the eventual form of proposed CRE content
(
http://scap.nist.gov/specifications/cre/).
In any event, the <fix> tags would be available as part of final XCCDF
output, and would enable generation of some remediation resources
directly from the SCAP content such as in
http://dev.gentoo.org/~swift/docs/genoval.xml
Puppet is very compelling for certain use cases. A decision was also
made to develop Puppet content elsewhere (and this would link to
compliance items on scap-security-guide). It would simply be too much
for one project/versioning system to handle SCAP content and Puppet
modules. (It would also be out of scope. Well, even further out of
scope than the Bash.)
The best way to express a linkage between the XCCDF Rules and Puppet
modules is also somewhat of an open question. More information about
the relationship between an XCCDF document and the remediation resources
available for it may be helpful; the CRE draft from NIST/Mitre did not
yet seem to concretely express what this would look like.