adding fixes -- a proposed patch

Jeffrey Blank blank at eclipse.ncsc.mil
Wed Apr 18 22:32:05 UTC 2012


Almost.
Except the fix info would not be added into individual Rules.  Fixes
would live in the fixes directory and be expected to note which Rule
they apply to.

To this end, each <fix> tag (by virtue of my abuse of the XCCDF
namespace) inside the fixes/ directory includes a new attribute "rule="
that specifies which Rules it applies to.

Set of fixes for each fix "system" e.g. bash, puppet (or fixes from the
same "system" but different use-cases) would be kept in their own file.

Naming the file bash-ks.xml was intended to suggest that it's intended
for generation of a shell script appropriate for a kickstart (or
hardening script at initial provisioning).


The transform shoves these <fix>es into the correct Rule in final output
(adding "system=" as identified by the <fix-group>, and stripping out
the "rule=" namespace abuse).

The transform is designed to permit easy additions of whatever set (or
sets) of fixes you'd like to have in the final XCCDF (or to make it easy
to add a set of fixes to the XCCDF).  This was done to allow multiple
parties to add their own groups of fixes to our output easily, and to
keep semantically-related things near each other (e.g. sets of fixes for
a particular fix system).

It has already been pointed out that some fixes will need variables
(<Value>s), and the transform (with some further namespace abuse) can be
made to support this.

In your example, I might call the id= for the fix-group something that
relates to the entire set of fixes you'd plan to place in the file.
That said, multiple groups of fixes could be added to final output.




On 04/16/2012 11:30 PM, Shawn Wells wrote:
> On 4/13/12 2:20 PM, Jeffrey Blank wrote:
>> Attached is a patch that demonstrates a method for adding fixes in a
>> modular way.
>>
>> It should allow fixes from different "systems"  (bash, puppet, chef(?),
>> well whatever) and even different sets of fixes from the same "system"
>> (such as different sets of Puppet modules designed for different use
>> cases) to be linked into XCCDF output easily, and also would keep
>> remediation resources discrete from both each other and the main
>> project.  It depends on linkage to Rules via id.
>>
>> Comments are solicited.
> 
> Assuming I understand correctly (and that's a big assumption!....) this
> would allow us to modify our existing content and include something like:
> 
> 
> <Rule id="audit_config_immutable">
>     <title>Make the <tt>auditd</tt> Configuration Immutable</title>
>     <description>Add the following to <tt>/etc/audit/audit.rules</tt> in
> order
> to make the configuration immutable:
> <pre>-e 2</pre>
> With this setting, a reboot will be required to change any
> audit rules.
>     </description>
>     <rationale>Making the audit configuration immutable prevents the
> accidential as
> well as malicious modification of the audit rules.</rationale>
>     <ident cce="14692-8" />
>     <oval id="audit_rules_immutable" />
>     <ref nist="AU-2" />/
> *    <fix group="audit_config_immutable">*/
> </Rule>
> 
> 
> Then within input/fixes/bash.xml I would add something like this?
> 
> <fix-group id="audit_config_immutable" system="urn:xccdf:fix:script:bash" xmlns="http://checklists.nist.gov/xccdf/1.1">
> 	<fix rule="audit_selinux_perms">do something in bash</fix>
> 	<fix rule="audit_append_e">do something else in bash</fix>
> </fix-group>
> 
> 
> 
> 
> 
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/scap-security-guide



More information about the scap-security-guide mailing list