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
On Sun, 17 Feb 2013 01:41:06 -0500 Shawn Wells shawn@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.
On 2/17/13 8:08 PM, Brian Millett wrote:
On Sun, 17 Feb 2013 01:41:06 -0500 Shawn Wellsshawn@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 :)
On Sat, 16 Feb 2013 13:35:41 -0500 Shawn Wells 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.
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%5C%22%3E%5Cn";
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__
On 2/18/13 2:48 PM, Brian Millett wrote:
On Sat, 16 Feb 2013 13:35:41 -0500 Shawn Wellsshawn.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%5C%22%3E%5Cn";
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
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 Wellsshawn.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.
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%5C%22%3E%5Cn";
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Tue, Feb 19, 2013 at 12:41 AM, Shawn Wells shawn@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.
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@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%5C" 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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 02/20/2013 07:01 PM, Jeffrey Blank wrote:
- 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.
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/
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.
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...
On 02/20/2013 07:01 PM, Jeffrey Blank wrote:
- …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.
On Wednesday, February 20, 2013 7:02 PM, Jeffrey Blank wrote:
A few quick points:
- 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.
- 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
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.
scap-security-guide@lists.fedorahosted.org