12:41 a.m.
On 2/16/13 1:35 PM, Shawn Wells wrote:
EXAMPLE USAGE:
(since generate fix only produces scripts for failed rules, change all results to fail)
if ! rpm -qa | grep -q aide; then
yum -y install aide
fi
if rpm -qa | grep -q xinetd; then
yum -y remove xinetd
fi
if rpm -qa | grep -q telnet-server; then
yum -y remove telnet-server
fi
if rpm -qa | grep -q ypserv; then
yum -y remove ypserv
fi
My patch-push script keeps dropping things it thinks are comments.
Here's the full example workflow:
# oscap xccdf eval --profile stig-rhel6-server --results
/tmp/results.xml --oval-results --cpe-dict
output/ssg-rhel6-cpe-dictionary.xml output/ssg-rhel6-xccdf.xml
since `generate fix` only does so for failed rules, change everything to
failed to get sample output:
# sed -i
's/<result>pass<\/result>/<result>fail<\/result>/g'
/tmp/results.xml
# oscap xccdf generate fix --result-id
xccdf_org.open-scap_testresult_stig-rhel6-server /tmp/results.xml
#!/bin/bash
# OpenSCAP fix generator output for benchmark: DRAFT Guide to the Secure
Configuration of Red Hat Enterprise Linux 6
# XCCDF rule: install_aide
# CCE-27024-9
if ! rpm -qa | grep -q aide; then
yum -y install aide
fi
# XCCDF rule: uninstall_xinetd
# CCE-27005-8
if rpm -qa | grep -q xinetd; then
yum -y remove xinetd
fi
# XCCDF rule: uninstall_telnet_server
# CCE-27073-6
if rpm -qa | grep -q telnet-server; then
yum -y remove telnet-server
fi
# XCCDF rule: uninstall_ypserv
# CCE-27079-3
if rpm -qa | grep -q ypserv; then
yum -y remove ypserv
fi
# generated: 2013-02-16T13:40:22-05:00
# END OF SCRIPT
7:08 p.m.
On Sun, 17 Feb 2013 01:41:06 -0500
Shawn Wells <shawn(a)redhat.com> wrote:
On 2/16/13 1:35 PM, Shawn Wells wrote:
> EXAMPLE USAGE:
>
> (since generate fix only produces scripts for failed rules, change all
> results to fail)
>
> if ! rpm -qa | grep -q aide; then
> yum -y install aide
> fi
>
> if rpm -qa | grep -q xinetd; then
> yum -y remove xinetd
> fi
>
> if rpm -qa | grep -q telnet-server; then
> yum -y remove telnet-server
> fi
>
> if rpm -qa | grep -q ypserv; then
> yum -y remove ypserv
> fi
My patch-push script keeps dropping things it thinks are comments.
Here's the full example workflow:
# oscap xccdf eval --profile stig-rhel6-server --results
/tmp/results.xml --oval-results --cpe-dict
output/ssg-rhel6-cpe-dictionary.xml output/ssg-rhel6-xccdf.xml
since `generate fix` only does so for failed rules, change everything to
failed to get sample output:
# sed -i
's/<result>pass<\/result>/<result>fail<\/result>/g'
/tmp/results.xml
# oscap xccdf generate fix --result-id
xccdf_org.open-scap_testresult_stig-rhel6-server /tmp/results.xml
#!/bin/bash
# OpenSCAP fix generator output for benchmark: DRAFT Guide to the Secure
Configuration of Red Hat Enterprise Linux 6
# XCCDF rule: install_aide
# CCE-27024-9
if ! rpm -qa | grep -q aide; then
yum -y install aide
fi
# XCCDF rule: uninstall_xinetd
# CCE-27005-8
if rpm -qa | grep -q xinetd; then
yum -y remove xinetd
fi
# XCCDF rule: uninstall_telnet_server
# CCE-27073-6
if rpm -qa | grep -q telnet-server; then
yum -y remove telnet-server
fi
# XCCDF rule: uninstall_ypserv
# CCE-27079-3
if rpm -qa | grep -q ypserv; then
yum -y remove ypserv
fi
# generated: 2013-02-16T13:40:22-05:00
# END OF SCRIPT
This looks really good. I'm ready to implement this tomorrow. I've got +-
400 "fix"es that need to be broke out so they can be maintained a bit more
easily. This is awesome.
I've been looking at the XCCDF spec, and I wish that there was a means of
having a "value-id" (as in the check-export) for a "fix". That would
allow a
remediation truly be based on a profile. The checks allow refine-values to be
adapted for each profile, but I see no way to do the same for the fixes. So I
guess a limitation to the fix is that it is a one size fits all. Unless you
all (who really know this stuff) knows of a way to add a value to a fix??
Thanks Shawn.
--
Brian Millett
"And if someone is living there?"
'Then all our races stand on the end of extinction.'
-- [ Sheridan and G'Kar (re: Z'ha'dum), "Revelations"]
8:55 p.m.
On 2/17/13 8:08 PM, Brian Millett wrote:
On Sun, 17 Feb 2013 01:41:06 -0500
Shawn Wells<shawn(a)redhat.com> wrote:
> >On 2/16/13 1:35 PM, Shawn Wells wrote:
>> > >EXAMPLE USAGE:
>> > >
>> > >(since generate fix only produces scripts for failed rules, change all
>> > >results to fail)
>> > >
>> > >if ! rpm -qa | grep -q aide; then
>> > >yum -y install aide
>> > >fi
>> > >
>> > >if rpm -qa | grep -q xinetd; then
>> > >yum -y remove xinetd
>> > >fi
>> > >
>> > >if rpm -qa | grep -q telnet-server; then
>> > >yum -y remove telnet-server
>> > >fi
>> > >
>> > >if rpm -qa | grep -q ypserv; then
>> > >yum -y remove ypserv
>> > >fi
> >
> >My patch-push script keeps dropping things it thinks are comments.
> >Here's the full example workflow:
> >
> ># oscap xccdf eval --profile stig-rhel6-server --results
> >/tmp/results.xml --oval-results --cpe-dict
> >output/ssg-rhel6-cpe-dictionary.xml output/ssg-rhel6-xccdf.xml
> >
> >since `generate fix` only does so for failed rules, change everything to
> >failed to get sample output:
> ># sed -i
's/<result>pass<\/result>/<result>fail<\/result>/g'
> >/tmp/results.xml
> >
> ># oscap xccdf generate fix --result-id
> >xccdf_org.open-scap_testresult_stig-rhel6-server /tmp/results.xml
> >#!/bin/bash
> ># OpenSCAP fix generator output for benchmark: DRAFT Guide to the Secure
> >Configuration of Red Hat Enterprise Linux 6
> >
> ># XCCDF rule: install_aide
> ># CCE-27024-9
> >
> >if ! rpm -qa | grep -q aide; then
> >yum -y install aide
> >fi
> >
> >
> ># XCCDF rule: uninstall_xinetd
> ># CCE-27005-8
> >
> >if rpm -qa | grep -q xinetd; then
> >yum -y remove xinetd
> >fi
> >
> >
> ># XCCDF rule: uninstall_telnet_server
> ># CCE-27073-6
> >
> >if rpm -qa | grep -q telnet-server; then
> >yum -y remove telnet-server
> >fi
> >
> >
> ># XCCDF rule: uninstall_ypserv
> ># CCE-27079-3
> >
> >if rpm -qa | grep -q ypserv; then
> >yum -y remove ypserv
> >fi
> >
> >
> ># generated: 2013-02-16T13:40:22-05:00
> ># END OF SCRIPT
This looks really good. I'm ready to implement this tomorrow. I've got +-
400 "fix"es that need to be broke out so they can be maintained a bit more
easily. This is awesome.
That's awesome!! Hopefully this will provide a framework to incorporate
those scripts! A few considerations, as people start thinking about
submitting fix scripts:
- There needs to be a direct mapping between an XCCDF rule and script,
meaning a script should only fix one thing at a time.
- Name the scripts against the XCCDF rule it addresses
- When submitting patches, please make each script its own patch! This
will allow peer review on each script indivudually, and should they get
ack'd, you can push the specific components which are approved.
I've been looking at the XCCDF spec, and I wish that there was a
means of
having a "value-id" (as in the check-export) for a "fix". That would
allow a
remediation truly be based on a profile. The checks allow refine-values to be
adapted for each profile, but I see no way to do the same for the fixes. So I
guess a limitation to the fix is that it is a one size fits all. Unless you
all (who really know this stuff) knows of a way to add a value to a fix??
Tresys
was working on a proper way.
I've been (lamely) working around this:
$ grep "<refine-value" ssg-rhel6-xccdf.xml | awk -F\" ' { print $2
"="
$4 } ' >/tmp/fixscript.sh
$ oscap xccdf generate fix --result-id
xccdf_org.open-scap_testresult_stig-rhel6-server /tmp/results.xml
>/tmp/fixscript.sh
Allows me to use the xccdf variables until something real gets created.
Thanks Shawn.
I'm just one of many :)
1:48 p.m.
On Sat, 16 Feb 2013 13:35:41 -0500
Shawn Wells <shawn.d.wells(a)gmail.com> wrote:
Ok, so your idea is really good. I've converted my "project" for the
company I'm at and
it works really nice.
I ran into a bit of some issues which I'll
run past you.
My bash-ks.xml is very large, so I wrote a perl script to break it up into
individual files.
[bpm]$ pwd
/home/bpm/src/scap/scap-security-guide/RHEL6/input/fixes/bash
[bpm]$ ls | wc -l
399
So you can see that there are many fixes. One of the side affects of the perl
script to parse the bash-ks.xml, is that all of the scripts had the & <
> changed
back into & < >. Which is a nice side affect in that each fix can be ran from
the
commandline to test. But combining them back into the bash-remediations.xml
left the xml file broken. Also the combinefixes.sh took a LONG time to run:
[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
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__
__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\">\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__
--
Brian Millett
"Now, Commander, I'm sure there's more to your story than that."
'Yes.'
-- [ Cynthia Torqueman and Ivanova, "And Now For A Word"]
12:39 a.m.
On 2/18/13 2:48 PM, Brian Millett wrote:
On Sat, 16 Feb 2013 13:35:41 -0500
Shawn Wells<shawn.d.wells(a)gmail.com> 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\">\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
12:41 a.m.
On 2/19/13 1: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<shawn.d.wells(a)gmail.com> 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.
Note to self: Stop doing EMails past 0130....
"It seems like this would really be only needed by a few developers to
break up 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\">\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
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
--
Shawn Wells
Technical Director,
U.S. Intelligence Programs
(e) shawn(a)redhat.com
(c) 443.534.0130
8:54 a.m.
On Tue, Feb 19, 2013 at 12:41 AM, Shawn Wells <shawn(a)redhat.com> wrote:
Note to self: Stop doing EMails past 0130....
"It seems like this would really be only needed by a few developers to
break up pre-existing scripts, vs something that should get dropped into
the project"
Could not agree more. It was just for information, maybe useful to someone
else, but not likely.
--
Brian Millett
"Shifts in paradigms
often cause nose bleeds."
Greg Glenn
6:01 p.m.
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 <shawn.d.wells(a)gmail.com> <mailto:shawn.d.wells@gmail.com>
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
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
--
___________________________
Jeffrey Blank
410-854-8675
Technology and Systems Analysis / Network Components
NSA Information Assurance
6:47 p.m.
On 02/20/2013 07:01 PM, Jeffrey Blank wrote:
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.
I think this will be icky if XCCDF <Value>s are considered useful. There
is too little coordination in XCCDF for <Value>s and where they might be
used. XCCDF <Value>s were not well thought out for use in more than just
benchmark "tailoring".
It may be long-term necessary to consider alternatives.
Shorter-term, the assembly process starting from (the woefully
namespace-less, which I think I can correct) fragments can likely be
adapted to propagate variables of interest into SCAP-compliant XML. I
don't think <xccdf:sub> is the right way.
If it is now close to the time when a namespace (or two) for
scap-security-guide fragments, and a schema for those, can be
considered, I'd be willing to put up a trial balloon. This ultimately
becomes an exercise in avoiding arbitrary limitations of XCCDF by
allowing reasonable and useful expression ahead of (SP 800-126 rev 1)
XCCDF generation. As in variables that end up manifest in checks and
fixes. Ideally, the same meaning of value/variable (e.g., password
length) in all venues.
I don't think XCCDF should be levied on content authors, rather,
something useful that can be competently turned into XCCDF should be
provided. Accompanied by a schema. It can be better than XCCDF; the
shortcomings of such a transformation can be noted so that the
proto-XCCDF/OVAL content can be dumbed-down as and if necessary.
9:37 p.m.
On Wednesday, February 20, 2013 7:48 PM, Gary Gapinski wrote:
I don't think XCCDF should be levied on content authors,
rather,
something useful that can be competently turned into XCCDF should be
provided. Accompanied by a schema. It can be better than XCCDF; the
shortcomings of such a transformation can be noted so that the
proto-XCCDF/OVAL content can be dumbed-down as and if necessary.
So the complexity of writing SCAP content is an issue that's been periodically raised
in various parts of the community. Is anyone aware of what the current recommended
best-practice is? I'm not so sure that solving the problem of overly-complex XML by
adding yet another layer of XML is really solving the problem; at some point (usually
troubleshooting) it just becomes added complexity.
At some point early in our involvement with SCAP we mucked around with doing something
similar, but with a non-XML-based domain-specific language called SC [1] (and its
compiler, SCC. This was before we knew there was a scanning tool out there of that name;
early days, etc.). The goal was to have a more human-readable syntax for authoring
content which would then be compiled into OVAL. At the time we hadn't started
tackling XCCDF. At some point I even rolled up an Eclipse plug-in to allow for
auto-completion and dropdown-niceties for the SC language, though that plug-in never made
it to a releasable state.
The project itself is neither here nor there, but from past experience going down the road
of "Let's add another authorship layer to make this easier" there are some
pitfalls to look out for. The primary one is the problem of testing your end-content that
has been produced. To drop into the narrative for a moment:
So you [the content author/protagonist here] author your content in a simpler manner. You
have some auto-complete, the syntax is simple, life is good. You then run some magic to
get the end content compiled (or transformed via XSLT). Now you've got your messy
XCCDF/OVAL/whatever, but thanks to your easy-authorship approach you don't really have
to look at that. You test the content out in your tool-of-choice, but drat! It
didn't do what you expected. What went wrong? Was it:
A ) The original content you wrote has a bug
B ) The transform/compiler you leveraged has a bug
C ) The tool you leveraged has a bug
In order to track this down you really need an in-depth knowledge of the XCCDF/OVAL.
That's what your tool is consuming, so to figure out if the problem is that content or
if it's the tool requires really looking at the XCCDF/OVAL. In order to debug
content, your content author will still need to have some deep knowledge of XCCDF/OVAL.
I'm sure everyone on this list has written a lot more XCCDF & OVAL than myself, so
I'll defer to the community's expertise here. I'm just not sure there's a
practical way to avoid having XCCDF be levied on content authors; the best solution may be
to just get a good editor UI set up. I believe SCAP Workbench [2] takes that approach.
- Francisco
[1] SCC - http://oss.tresys.com/projects/scc/wiki/GettingStarted
[2] SCAP Workbench - https://fedorahosted.org/scap-workbench/
6:26 a.m.
On 02/20/2013 10:37 PM, Francisco Slavin wrote:
So the complexity of writing SCAP content is an issue that's
been
periodically raised in various parts of the community. Is anyone aware
of what the current recommended best-practice is? I'm not so sure that
solving the problem of overly-complex XML by adding yet another layer
of XML is really solving the problem; at some point (usually
troubleshooting) it just becomes added complexity.
My personal recommendation is to use a suitably-devised XML
representation (or as many as one needs) and transform via XSLT. XML is
not essential, just easier, particularly at the final stage that
produces SCAP-compliant documents. This does not preclude
representations other than XML — it's just more difficult to parse
non-XML on its way to becoming XML. This difficulty may simply be a
personal shortcoming. Use of XML also affords schema-driven content
editing. While they likely exist, I am unaware of any alternate syntaxes
that can coerce correctness at content creation time solely using static
documents in the fashion of XML schemata.
I cannot recommend any other recommendations, particularly any using
SCAP "languages" natively or via telekinesis.
Any departure from something simple that can be easily wielded by
someone whose expertise lies in system configuration rather than arcane
"languages" is wacky, which is the current state of affairs in SCAP.
At some point early in our involvement with SCAP we mucked around
with doing something similar, but with a non-XML-based domain-specific language called SC
[1] (and its compiler, SCC. This was before we knew there was a scanning tool out there
of that name; early days, etc.). The goal was to have a more human-readable syntax for
authoring content which would then be compiled into OVAL. At the time we hadn't
started tackling XCCDF. At some point I even rolled up an Eclipse plug-in to allow for
auto-completion and dropdown-niceties for the SC language, though that plug-in never made
it to a releasable state.
That sounds perfectly reasonable.
The project itself is neither here nor there, but from past
experience going down the road of "Let's add another authorship layer to make
this easier" there are some pitfalls to look out for. The primary one is the problem
of testing your end-content that has been produced. To drop into the narrative for a
moment:
So you [the content author/protagonist here] author your content in a simpler manner.
You have some auto-complete, the syntax is simple, life is good. You then run some magic
to get the end content compiled (or transformed via XSLT). Now you've got your messy
XCCDF/OVAL/whatever, but thanks to your easy-authorship approach you don't really have
to look at that. You test the content out in your tool-of-choice, but drat! It
didn't do what you expected. What went wrong? Was it:
A ) The original content you wrote has a bug
B ) The transform/compiler you leveraged has a bug
C ) The tool you leveraged has a bug
In order to track this down you really need an in-depth knowledge of the XCCDF/OVAL.
That's what your tool is consuming, so to figure out if the problem is that content or
if it's the tool requires really looking at the XCCDF/OVAL. In order to debug
content, your content author will still need to have some deep knowledge of XCCDF/OVAL.
Yes, particularly at C, and less likely at A if the original content is
not something wacky.
Were SCAP not a consideration, how much easier would this become?
I'm sure everyone on this list has written a lot more XCCDF &
OVAL than myself, so I'll defer to the community's expertise here. I'm just
not sure there's a practical way to avoid having XCCDF be levied on content authors;
the best solution may be to just get a good editor UI set up. I believe SCAP Workbench
[2] takes that approach.
I think this can only be successful if OVAL were to disappear, and the X
in XCCDF actually lived up to its commitments.
10:14 a.m.
It may be long-term necessary to consider alternatives.
True in so very many ways. But I'd be more concerned that XCCDF is
likely to ossify irrevocably, given its current position with standards
bodies.
If it is now close to the time when a namespace (or two) for
scap-security-guide fragments, and a schema for those, can be
considered, I'd be willing to put up a trial balloon.
I'd be happy to look at it, but I have serious doubts that it's actually
a good idea. The ability to do some arbitrary things (which such
formalization is likely to forbid or inhibit) is very valuable, such as
macros for common phrases. Schemas are requirements levied upon content
developers.
I also want to keep the content language as simple as possible, and as
even Shawn's brief confusion indicated, XML namespaces don't exactly
make things more accessible.
Removing all namespaces from the (undefined) content creation language
was quite intentional. To the extent possible, I wanted to end up in a
place where the content creation language could be "monkey-see,
monkey-do." (Even though that clearly hasn't worked out, I'd at least
prefer that it not be endlessly verbose to higher primates).
This ultimately
becomes an exercise in avoiding arbitrary limitations of XCCDF by
allowing reasonable and useful expression ahead of (SP 800-126 rev 1)
XCCDF generation. As in variables that end up manifest in checks and
fixes. Ideally, the same meaning of value/variable (e.g., password
length) in all venues.
That is sane, and exactly what my little scripts actually are trying to
achieve (well, technically, undo for final output) in their "linking" phase.
I don't think XCCDF should be levied on content authors, rather,
something useful that can be competently turned into XCCDF should be
provided. Accompanied by a schema. It can be better than XCCDF; the
shortcomings of such a transformation can be noted so that the
proto-XCCDF/OVAL content can be dumbed-down as and if necessary.
Yes, as usual, yes. But I'd still prioritize vetting and creation of
(openly-available) content in the deficient (or undefined) languages
we've got now. It remains shocking to me how little high-quality SCAP
content there is, yet there seem to be thousands of people at these
conferences...
7:58 p.m.
On 02/20/2013 07:01 PM, Jeffrey Blank wrote:
2) …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 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?)
There is a problem if the remedy is not consonant with the assessment.
Usable OVAL content is useful at this point in time, since
supposedly-SCAP-compliant tools should be able to ingest and use it.
There are no current SCAP-compliant alternatives — a pity. (Good
non-SCAP-compliant alternatives can certainly be postulated or
implemented, but that is a separate discussion.)
Many (not all) assessments can be done using OVAL. That is immediately
useful.
"Actions", namely, proposed system perturbations, are separate from
assessments (certainly related, but evaluation does not entail
perturbation).
I think that high-quality *assessment* content is immediately useful and
will always remain so. When one adds correction, discussion ensues.
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.
Why not? These are just alternative representations. They need not be
normative, just serviceable. They need not be in the same code base.
I do not understand why such recipes could not exist in, or be related
to, the guide as corrective actions related to relevant assessments.
I think a reasonable goal state is "systems security posture can be
assessed" augmented by "system security posture can be automated". And,
on both, assured.
I am willing to consider alterations or alternatives to SCAP, as it has
some shortcomings with respect to both goals.
9:06 p.m.
On Wednesday, February 20, 2013 7:02 PM, Jeffrey Blank wrote:
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.
So I want to caveat that the way we do things in SecState [1] isn't necessarily robust
enough for the level of content authorship/management that the community has now reached.
It was largely POC at the time to establish how simple it could be to implement such a
mechanism. We were simply populating 3 fields:
1) A path to the script
2) A set of environment variables to populate for the script
3) A set of positional arguments to pass in to the script
I would like to point out that you cannot use arbitrary XML within the <fix> tag and
have the content be valid XCCDF. We went with using JSON in there for convenience. The
only accepted XML elements within that <fix> tag are a <sub> or
<instance> tag, and the <sub> tag is basically just a reference to a
<value> somewhere. I know I've caught some flack for the JSON usage, but it was
a practical way to get things implemented. Given that we can't use arbitrary XML to
keep the document all-XML, and that whatever we do within a <fix> tag ends up being
pseudo-standard at best, JSON has proven to be a lightweight option for use as an
intermediate solution.
I know there was a discussion about having a better way to uniquely identify fixes besides
just a path to a script on a system. Possibly some UUID which in turn maps to a script
somewhere? If there's a standards-based way to do this it would be great, but with
how immature the <fix> aspect of XCCDF is I'm not sure if that option is there.
Having some pseudo-standard in place here gives us flexibility to add fields or metadata
as needed without invalidating the XCCDF document, whereas if there were raw BASH content
in the <fix> tag we would not have that sort of flexibility.
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.
I'll chime in again with an opinion that I think BASH and non-XCCDF content should
live in files external to the XCCDF, and simply be referenced from the XCCDF. I know this
is a discussion that's been had a few times, and this may be a battle I've already
lost, so kick me if I shouldn't be bringing this back up.
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.
I've been a bit out-of-pocket lately with some other work & travel; it seems like
every time I check in here the community is moving forward by leaps and bounds. It's
great to see this project hitting its goals. I'll be prioritizing updates to SecState
soon to pull in the latest OpenSCAP (with its shiny new high-level API), and then
integrate the SecState updates in to CLIP along with new SSG content. As I work through
that you'll likely be hearing a lot more from me here.
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.
I think that for this sort of <fix> branching keeping <fix> content itself
outside of the XCCDF and referencing it is again going to be the way to go. The XCCDF
will be much more sane-looking if it has some pseudo-standard external references to BASH
or puppet content as needed, as opposed to containing all of that content in one XCCDF
document. SecState originally supported Puppet for remediation (before the content
authorship community took a heavy lean toward BASH). We could use JSON to reference out
to Puppet again if needed, it would simply be a different set of parameters.
[1] - https://fedorahosted.org/secstate/wiki/RemediationContentHowTo
- Francisco
11:09 a.m.
tag is basically just a reference to a <value> somewhere. I
know
I've caught some flack for the JSON usage, but it was a practical way
to get things implemented. Given that we can't use arbitrary XML to
keep the document all-XML, and that whatever we do within a <fix> tag
ends up being pseudo-standard at best, JSON has proven to be a
lightweight option for use as an intermediate solution.
We can do whatever we want with XML in our authoring language, and we're
not writing in any particular schema (as Gary has pointed out). As far
as I'm concerned, final output should be valid XCCDF, but you can do
anything you want with XML until then. (And tooling that prepares the
fixes for execution can take care of preparing the environment to run
the bash script, such as instantiating environment variables.)
And your perception is correct: attempts to introduce JSON (or Perl)
into SSG should expect serious resistance. Had we started all
development in JSON, then I'd say the same about XML.
I know there was a discussion about having a better way to uniquely
identify fixes besides just a path to a script on a system. Possibly
some UUID which in turn maps to a script somewhere?
I want fixes to identify what they're for (by referencing a Rule id),
not the other way around. What <fix> to run is not the concern of the
baseline or guidance creator, and remediation is not the raison d'etre
of scap-security-guide. But we're happy to work closely together and
include simple bash fixes inside the project.
In essence, I would encourage remediation developers to refer to items
in the input/system and input/services (and input/profiles) directories,
and develop tooling that permits combination and integration with the
content generated from there.
If there's a
standards-based way to do this it would be great, but with how
immature the <fix> aspect of XCCDF is I'm not sure if that option is
there. Having some pseudo-standard in place here gives us
flexibility to add fields or metadata as needed without invalidating
the XCCDF document, whereas if there were raw BASH content in the
<fix> tag we would not have that sort of flexibility.
My motivation to look into the "right" way to do remediation will be far
higher when someone can assure me that the OVAL has actually been QA'ed.
Could you advise on current status of this? Is this still a dependency
of CLIP?
I'll chime in again with an opinion that I think BASH and
non-XCCDF
content should live in files external to the XCCDF, and simply be
referenced from the XCCDF.
Absolutely! Like we do now in SSG, for development.
I'm assuming there will be one XCCDF file from SSG with simple bash
fixes, and one without. In fact, that reminds me to adjust the Makefile
so that what is perceived as the "main" one does not include fixes.
I'll chime in again with an opinion that I think BASH and
non-XCCDF
content should live in files external to the XCCDF, and simply be
referenced from the XCCDF. I know this is a discussion that's been
had a few times, and this may be a battle I've already lost, so kick
me if I shouldn't be bringing this back up.
Definitely -- no development of <fix> tags is occurring inline with the
main content. The fix tags live inside their own directories away from
where the usual XCCDF content is written.
I don't expect issuers of baselines to include <fix> tags, and the act
of adding fixes is intentionally seperable/separated. It may be
possible to ship one version of the XCCDF file with bash fixes, and some
tooling may be able to process this, but this shouldn't preclude any
other approaches.
4078
days inactive
4086
days old
scap-security-guide@lists.fedorahosted.org
15 comments
6 participants
participants (6)
-
Brian Millett -
Francisco Slavin -
Gary Gapinski -
Jeffrey Blank -
Shawn Wells -
Shawn Wells