You rang? Or, y'know, whatever sound emails make. The internet is obviating the need
for the onomatopoeia.
On Monday, March 25, 2013 10:15 PM, 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. Here's a few of the common questions and my
thoughts to get us started.
I feel like I wade into this conversation from time to time and end up repeating
myself a bit. A couple past threads [1] for context [2] should keep me from being too
repetitive.
(1) What language(s) should be used?
IMO, bash. I'm leaning this way because it's included in *every* RHEL
release, whereas puppet modules would require the installation of 3rd party
software. I'd like to see as much done through 'native' tools as possible.
There's certainly advantages to Perl (e.g., potential speed) however I don't
think we want to assume Perl is installed on all RHEL machines.
Puppet 's high-level language lets you statefully define system configurations.
This is nice considering ostensibly XCCDF follows a very similar modeling approach. The
problem is government applicability - Puppet is in EPEL and is not enterprise-supported as
such the last I checked, so for some areas it's simply not an option. Additionally
some people targeting embedded environments don't want to pull Puppet in.
BASH is everywhere and as such makes the most sense.
From a tools side it would make sense to support numerous 'fix' mechanisms, and
from a content side it may make sense to have fix content in various formats. For the
first steps it seems like BASH is the way to go.
(2) Do we perform checking in the scripts?
Defined further, should the scripts contain conditional checks to see if they
should be ran?
IMO, no. That's what OVAL is for.
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.
(3) Where do we begin?
- Name remediation scripts after corresponding XCCDF rule
- Build process includes them into final ssg-rhel6-xccdf.xml
Known challenge on passing XCCDF variables through to the scripts,
however I wouldn't let this hold us up. Still *tons* of work to be done
while this gets sorted.
I'm not sure what challenge you're referencing here. We've gotten
variable passing to work pretty simply [3].
There's a good bit of RHEL6 content in the Aqueduct project that (I
believe) Tresys committed. Perhaps we could reuse those scripts?
The Tresys CLIP team did contribute a lot of scripts to Aqueduct which were written
specifically to go alongside SSG SCAP content [4]. These scripts were mapped back
directly to SSG rules [5]. They were written against an older version of the SSG repo and
as such likely need a bit of an update, but I think they would be a very good starting
place.
There are a lot of design concerns to keep in mind when approaching remediation content
and the balance between authorship time and effort must be considered for each of those.
Unfortunately I missed the registration for your SCAP workshop this time around, but I
would be happy to support a call to talk through some of this.
Thank you
- Francisco
[1] Sep 2012 -
https://lists.fedorahosted.org/pipermail/scap-security-guide/2012-Septemb...
[2] Feb 2013 -
https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-Februar...
[3] SecState XCCDF variable passing -
https://fedorahosted.org/secstate/wiki/RemediationContentHowTo
[4] -
https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG
[5] -
https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG/tools...