On 1/31/2013 11:20 AM, Brian Millett wrote:
On Thu, Jan 31, 2013 at 9:49 AM, Mike Palmiotto
<mpalmiotto(a)tresys.com>wrote:
> On 1/31/2013 9:38 AM, Brian Millett wrote:
>
>> I'm really interested in adding fixes, or having a set of fixes I can
>> apply to
>> the xccdf for rhel6. I've looked at the line in the Makefile:
>>
>> xsltproc -stringparam fixes "../$(IN)/fixes/bash-ks.xml" -o
>> $(OUT)/unlinked-rhel6-xccdf.**xml $(TRANS)/xccdf-addfixes.xslt
>> $(OUT)/unlinked-rhel6-xccdf.**xml
>>
>> and it looks like, following the bas-ks.xml, I can create a file with
>> each fix
>> as long as each fix-id is the same as the rule-id so that the fix can be
>> merged with the appropriate rule into a final xccdf.xml file.
>>
>
> When you say fix-id, do you mean the rule attribute for each fix tag?
>
Ok, silly me, I went back and looked at the bash-ks.xml and I had totally
miss read the fix.
In the bash-ks.xml a fix is as
<fix rule="disable_vsftp">service vsftpd stop</fix>
while in a xccdf Rule tag, the fix is as
<fix id="service_restorecond_enabled" reboot="false"
platform=""
system="">chkconfig restorecond on</fix>
So, I didn't grok the "id=" vs the "rule=".
That makes sense.
So the bash-ks.xml is
<fix-group id="bash" system="urn:xccdf:fix:script:bash"
xmlns="
<snip>
fi</fix>
</fix-group>
You've got it.
A point worth noting: Imagine a full bash-ks.xml file created in that
fashion. I've worked pretty extensively with the fix scripts and they
are often more than just simple one-liners.
One way of getting around this issue (massive fix files) is to have
scripts do the work and reference them in the fix tags. The CLIP
project leverages a neat little script that maps rules in a profile to
the remediation [fix] scripts. Each script is given with the name of
the corresponding Rule, so the mapping is pretty straightforward.
(see:
http://oss.tresys.com/projects/clip/browser/packages/aqueduct/aqueduct/co...)
The fix-mapping and the corresponding bash scripts are
hosted upstream in the aqueduct project, here:
https://fedorahosted.org/aqueduct/browser/trunk/compliance/Bash/SSG
We use SecState to process the scripts and run them. The format is as
seen here:
https://fedorahosted.org/secstate/wiki/RemediationContentHowTo
As you can see, SecState supports passing variables into scripts through
use of '<sub idref="variable_id"/>.' If I'm not mistaken,
this is the
mechanism that XCCDF uses to pass variables from profiles to scripts.
CLIP has something (to be put upstream very soon), which grabs
refine-variables from idrefs in a profile and shoves them into fix tags.
This allows you to customize tunables on-the-fly, without having to
change your fix content every time you want to change a variable.
Instead you would just edit the variables in the corresponding profile.
If you want to grab a copy of CLIP and play around with the source, feel
free to visit:
http://oss.tresys.com/projects/clip/wiki/DownloadRelease
CLIP includes a snapshot of SSG, which we plan on getting up-to-date, a
snapshot of Aqueduct, and a glue-script, which binds the remediation
content and XCCDF in a fashion that is consumable by SecState.
I recommend looking at the final build, since we used a bunch of patches
to fill in the gaps left from multiple moving targets. The build-system
is well-documented, with various Help-Topic files in the root directory.
Let me know if you have any questions!
--Mike
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide