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.
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>
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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Shawn Wells