Okay, I've fallen behind on email.... A few quick points: 1) Ditto on the exporting of variables to achieve flexibility with regard to values. SecState may provide some inspiration, as I believe they populate environment variables to handle this (see Francisco's earlier post). This will have to be addressed by tooling (and careful sync between tooling and content authors). Presumably the openscap developers can cook up something in their fix-generation.
2) I am concerned about the presence of what are effectively bash checking scripts in the fix tags. In the presence of adequate tooling and SCAP checking content it seems unnecessary. I also fear that this will divert effort away from QA on the OVAL content, which is the checking system used in baselines (and against which your systems would be "officially" scanned in most compliance regimes, including DoD's). I'm not trying to start a fun flamewar (again) and I don't disagree with Gary about OVAL deficiencies, and I also like the fact that SCE exists, I'm just saying that this project still has high-quality OVAL content as a goal. And the point of formatting the script actions into <fix> tags is that they'd only be activated in case of check failure anyway. (Right?) It is also a goal to simplify. Overall, I like much of Shawn's patch for fix content as a first step, and grant it an ACK (except for the script checking parts). It seems like a reasonable place to start and we can iterate forward with OpenSCAP and Aqueduct and SecState developers. Another goal to keep in mind is how to link this to other types of remediation (or systems management) resources. For example, I cannot really imagine Puppet modules or Ansible playbooks or Chef recipes living in scap-security-guide. Ensuring that providers of such *very valuable* resources (which allow administrators to actually, uh, manage their systems instead of just do C&A and deploy them) can interoperate is worthwhile. On 02/19/2013 01:39 AM, Shawn Wells wrote: > On 2/18/13 2:48 PM, Brian Millett wrote: >> On Sat, 16 Feb 2013 13:35:41 -0500 >> Shawn Wells <[email protected]> <mailto:[email protected]> wrote: >> >>> > >> Ok, so your idea is really good. I've converted my "project" for the >> company I'm at and >> it works really nice. > > Well.... It's a complete hack, until we can think of a > clever/appropriate/scalable/non-sucky way to get the variable names into > the fix content. > > >> ....... >> [root@localhost RHEL6]# time transforms/combinefixes.sh input/fixes/bash/ >> output/bash-remediations2.xml >> >> real 4m41.432s >> user 0m5.427s >> sys 0m53.876s >> >> So I rewrote it in perl which took: >> >> [root@localhost RHEL6]# time transforms/combinefixes.pl input/fixes/bash/ >> output/bash-remediations.xml >> >> real 0m1.131s >> user 0m0.095s >> sys 0m0.184s > > Hah, this is hilarious. Thank you for cleaning up my bilge quality bash > script! > >> So here are the perl scripts. One to break up a large bash-ks.xml file and >> one to combinefixes. >> >> __BEGIN__ parseFix.pl >> #!/usr/bin/perl >> >> use XML::Simple qw(:strict); >> use Data::Dumper; >> >> my $xmlFile = $ARGV[0]; >> my $xmlDir = $ARGV[1]; >> >> my $DEBUG=0; >> >> my $config = XMLin($xmlFile, >> KeyAttr => { fix => 'rule' }, >> ForceArray => [ 'fix' ]); >> >> #print Dumper($config) if $DEBUG; >> >> my $fixes = $config->{'fix'}; >> >> for my $rule (keys %{$fixes}) { >> printf "%s => %s\n", $rule, $fixes->{$rule}->{'content'} if $DEBUG; >> open my $fix, '>', $xmlDir."/". $rule.".sh"; >> printf $fix "%s\n", $fixes->{$rule}->{'content'}; >> } >> __END__ > It seems like this would really be only needed a few developers end, to > breakup your pre-existing scripts, vs something that should get dropped > into the project. > > >> __BEGIN__ combinefixes.pl >> #!/usr/bin/perl >> >> use Data::Dumper; >> use File::Basename; >> >> ## First argument: directory with .sh scripts >> ## Second argument: where to put combined xml file >> >> my $fixDir=$ARGV[0]; >> my $output=$ARGV[1]; >> >> sub encode { >> my($toencode) = @_; >> $toencode =~ s/\&/\&/g; >> $toencode =~ s/>/\>/g; >> $toencode =~ s/</\</g; >> return $toencode; >> } >> >> open my $XML, '>', $output; >> >> print $XML "<fix-group id=\"bash\" system=\"urn:xccdf:fix:script:sh\" >> xmlns=\"http://checklists.nist.gov/xccdf/1.1\"; >> <http://checklists.nist.gov/xccdf/1.1%5C>>\n"; >> >> opendir(my $dh, $fixDir) || die "can't opendir $fixDir: $!"; >> @files = grep { !/^\./ && -f "$fixDir/$_" } readdir($dh); >> closedir $dh; >> >> for my $fixScript (@files) { >> my $fixName = basename($fixScript,".sh"); >> open my $FIX,'<', $fixDir."/".$fixScript; >> my @lines = <$FIX>; >> close $FIX; >> @lines = map { encode($_) } @lines; >> print $XML "<fix rule=\"$fixName\">\n"; >> print $XML (@lines); >> print $XML "</fix>\n"; >> } >> >> print $XML "</fix-group>\n"; >> close $XML; >> __END__ > Running this locally: > > $ make content > $ oscap xccdf eval --profile stig-rhel6-server --results > /tmp/results.xml --cpe-dict output/ssg-rhel6-cpe-dictionary.xml > output/ssg-rhel6-xccdf.xml > $ oscap xccdf generate fix --result-id > xccdf_org.open-scap_testresult_stig-rhel6-server /tmp/results.xml >>>/tmp/fixscript.sh > $ cat /tmp/fixscript.sh > #!/bin/bash > # OpenSCAP fix generator output for benchmark: DRAFT Guide to the Secure > Configuration of Red Hat Enterprise Linux 6 > > # generated: 2013-02-19T01:37:13-05:00 > > > Something appears to be off.... will look at this more tomorrow (err, > later today?). Changed Makefile to run the pl script: > ./$(TRANS)/combinefixes.pl $(IN)/fixes/bash/ > $(OUT)/bash-remediations.xml > > > > _______________________________________________ > scap-security-guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide -- ___________________________ Jeffrey Blank 410-854-8675 Technology and Systems Analysis / Network Components NSA Information Assurance _______________________________________________ scap-security-guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
