On 1/31/2013 11:20 AM, Brian Millett wrote:
On Thu, Jan 31, 2013 at 9:49 AM, Mike Palmiotto <[email protected]>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/compliance/Bash/SSG/tools/fix_mapper.py)

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
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Reply via email to