adding "fix"es to the xccdf

Shawn Wells shawn at redhat.com
Sun Feb 3 01:18:32 UTC 2013


On 1/31/13 1:56 PM, Mike Palmiotto wrote:
> On 1/31/2013 11:20 AM, Brian Millett wrote:
>> On Thu, Jan 31, 2013 at 9:49 AM, Mike Palmiotto 
>> <mpalmiotto at 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/compliance/Bash/SSG/tools/fix_mapper.py) 
>
That's definitely the path forward. The bash-ks.xml file was created as 
an example on how to build in fix content. Not meant to reflect the 
desired method.

At some point it makes sense to create a unique fix directory, similar 
to the OVAL check directory, and drop unique scripts in there to be 
merged during the make process. We just have to convince Jeff to drop 
his objections on including fix content... ;)



More information about the scap-security-guide mailing list