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.
At least, that is what it seems. I uncommented the line in the Makefile and remade it, however, nothing was added to the final xccdf.xml file, and there are not any make errors, so
Any documentation or ideas where to look?
Thanks.
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?
Do you mind posting your bash-ks.xml file and an example script? I may be able to help.
--Mike
At least, that is what it seems. I uncommented the line in the Makefile and remade it, however, nothing was added to the final xccdf.xml file, and there are not any make errors, so
Any documentation or ideas where to look?
Thanks.
On Thu, Jan 31, 2013 at 9:49 AM, Mike Palmiotto mpalmiotto@tresys.comwrote:
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=" http://checklists.nist.gov/xccdf/1.1"> <fix rule="password_min_len">##According to the OVAL check, there are two places to check for the MINLEN #1 in /etc/login.defs sed --follow-symlinks -i '/^PASS_MIN_LEN/s/[0-9][0-9]*/14/' /etc/login.defs
# and # 2 in /etc/pam.d/system-auth grep -q minlen /etc/pam.d/system-auth if [ $? = "0" ]; then sed --follow-symlinks -i '/pam_cracklib.so/s/minlen=[0-9]/minlen=14/' /etc/pam.d/system-auth else sed --follow-symlinks -i '/pam_cracklib.so/s/pam_cracklib.so/pam_cracklib.so minlen=14 /' /etc/pam.d/system-auth fi</fix> <fix rule="password_min_age">sed --follow-symlinks -i '/^PASS_MIN_DAYS/s/[0-9][0-9]*/7/' /etc/login.defs</fix> <fix rule="password_max_age">sed --follow-symlinks -i '/^PASS_MAX/s/[0-9][0-9]*/90/' /etc/login.defs</fix> <fix rule="password_warn_age">sed --follow-symlinks -i '/^PASS_WARN_AGE/s/[0-9][0-9]*/14/' /etc/login.defs</fix> <fix rule="account_disable_post_pw_expiration">sed --follow-symlinks -i '/^INACTIVE/s/[-]*[0-9][0-9]*/35/' /etc/default/useradd</fix> <fix rule="account_unique_name" /> <fix rule="password_retry">sed --follow-symlinks -i '/ pam_cracklib.so/s/retry=[0-9]/retry=3/' /etc/pam.d/system-auth</fix> <fix rule="password_require_consecrepeat">grep -q maxrepeat /etc/pam.d/system-auth if [ $? = "0" ]; then sed --follow-symlinks -i '/pam_cracklib.so/s/maxrepeat=[0-9]/maxrepeat=3/' /etc/pam.d/system-auth else sed --follow-symlinks -i '/pam_cracklib.so/s/pam_cracklib.so/pam_cracklib.so maxrepeat=3 /' /etc/pam.d/system-auth fi</fix> <fix rule="password_require_digits">grep -q dcredit /etc/pam.d/system-auth if [ $? = "0" ]; then sed --follow-symlinks -i '/pam_cracklib.so/s/dcredit=[0-9]/dcredit=1/' /etc/pam.d/system-auth else sed --follow-symlinks -i '/pam_cracklib.so/s/pam_cracklib.so/pam_cracklib.so dcredit=1 /' /etc/pam.d/system-auth fi</fix> <fix rule="password_require_uppercases">grep -q ucredit /etc/pam.d/system-auth if [ $? = "0" ]; then sed --follow-symlinks -i '/pam_cracklib.so/s/ucredit=[0-9]/ucredit=2/' /etc/pam.d/system-auth else sed --follow-symlinks -i '/pam_cracklib.so/s/pam_cracklib.so/pam_cracklib.so ucredit=2 /' /etc/pam.d/system-auth fi</fix> </fix-group>
On 1/31/2013 11:20 AM, Brian Millett wrote:
On Thu, Jan 31, 2013 at 9:49 AM, Mike Palmiotto mpalmiotto@tresys.comwrote:
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/compl...)
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On Thu, 31 Jan 2013 13:56:41 -0500 Mike Palmiotto mpalmiotto@tresys.com wrote:
On 1/31/2013 11:20 AM, Brian Millett wrote:
On Thu, Jan 31, 2013 at 9:49 AM, Mike Palmiotto mpalmiotto@tresys.comwrote:
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.
<snip if really good info >
Good stuff. Thanks
I've been trying to get the sample bash-ks.xml to work, but when I run
make
no fixes referenced in the bask-ks.xml gets added to the finalized xccdf.xml file.
I removed the comment in the Makefile so the xccdf-addfixes.xslt is fired, but not output.
Kind of wanted to take baby steps with just the supplied before I dive into other projects/efforts to add fixes.
Thanks. --
Hi Brian,
Yeah. I'd try to leverage secstate -- you may find that a lot of the work has already been done for you.
Merger or formal interoperation of the multiple projects involved is on the radar, but it's not there yet. Meetings among the various stakeholders is probably called for before too long.
Jeff
On 01/31/2013 03:18 PM, Brian Millett wrote:
On Thu, 31 Jan 2013 13:56:41 -0500 Mike Palmiotto mpalmiotto@tresys.com wrote:
On 1/31/2013 11:20 AM, Brian Millett wrote:
On Thu, Jan 31, 2013 at 9:49 AM, Mike Palmiotto mpalmiotto@tresys.comwrote:
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.
<snip if really good info >
Good stuff. Thanks
I've been trying to get the sample bash-ks.xml to work, but when I run
make
no fixes referenced in the bask-ks.xml gets added to the finalized xccdf.xml file.
I removed the comment in the Makefile so the xccdf-addfixes.xslt is fired, but not output.
Kind of wanted to take baby steps with just the supplied before I dive into other projects/efforts to add fixes.
Thanks.
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@tresys.comwrote:
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/compl...)
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... ;)
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.
Depends on what output you're making, but that's the basic idea.
We just have to convince Jeff to drop his objections on including fix content... ;)
Well, my objection was toward automated fix content preceding the creation and QA of guidance/checking content. High-quality guidance and checking content is very hard to create, and it is also difficult to create remediation content for baselines which do not exist.
But anyway, looks like the time is getting closer. Several important scoping questions must be considered:
1) Is the intent to provide a collection of remediation modules/scripts, which are parameterized when needed, and which would be activated through some kind of selection mechanism? IIRC, this would be different from the current Aqueduct approach, which is to maintain separate directories for each baseline.
2) Is there interest in providing remediation modules in formats other than bash, such as Puppet or Chef? Whether we wanted such flexibility would influence our approach.
3) Would we prioritize (or only) create fixes for those things that do not pass "out of the box"?
4) Should much/any attention be paid to CRE? It may be worth a quick glance at Appendix C here: http://csrc.nist.gov/publications/drafts/nistir-7831/Draft-NISTIR-7831.pdf Is it desired as an output?
I'm just trying to think aloud about what this would look like, since I think it's really important for us to synchronize on goals before building anything.
I also consider some familiarity with scap-security-guide, Aqueduct, and secstate to be prerequisites for technical discussion. I need to review the Aqueduct and secstate code sometime over the next week to familiarize myself with their approaches. At present I would not feel qualified to start integrating code/scripts for remediation.
(I'm not sure if it's proper Netiquette to email multiple lists at once, but this is certainly relevant to Aqueduct and OpenSCAP too.)
On 2/4/13 5:40 PM, Jeffrey Blank wrote:
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.
Depends on what output you're making, but that's the basic idea.
We just have to convince Jeff to drop his objections on including fix content... ;)
Well, my objection was toward automated fix content preceding the creation and QA of guidance/checking content. High-quality guidance and checking content is very hard to create, and it is also difficult to create remediation content for baselines which do not exist.
But anyway, looks like the time is getting closer. Several important scoping questions must be considered:
- Is the intent to provide a collection of remediation modules/scripts,
which are parameterized when needed, and which would be activated through some kind of selection mechanism? IIRC, this would be different from the current Aqueduct approach, which is to maintain separate directories for each baseline.
Given that our rules can be part of multiple profiles, and assuming a parametrized approach, there seems a clear path to support multiple baselines.
IMO we'd want to create a "/fixes" directory analogous to /checks: Individualized files which we aggregate together during the build.
- Is there interest in providing remediation modules in formats other
than bash, such as Puppet or Chef? Whether we wanted such flexibility would influence our approach.
I *want* to use Puppet.
However, it seems more important to use a remediation technology that will be widely adopted. While Puppet is in RHEL EPEL, it's not shipped on the disk. This has caused several issues with shops not being able to run it, as Puppet isn't officially supported.
- Would we prioritize (or only) create fixes for those things that do
not pass "out of the box"?
If there is an XCCDF rule there should be a corresponding OVAL and remediation.
- Should much/any attention be paid to CRE?
It may be worth a quick glance at Appendix C here: http://csrc.nist.gov/publications/drafts/nistir-7831/Draft-NISTIR-7831.pdf Is it desired as an output?
Given the lack of maturity around CRE it seems not worth the time (yet?).
I'm just trying to think aloud about what this would look like, since I think it's really important for us to synchronize on goals before building anything.
I also consider some familiarity with scap-security-guide, Aqueduct, and secstate to be prerequisites for technical discussion. I need to review the Aqueduct and secstate code sometime over the next week to familiarize myself with their approaches. At present I would not feel qualified to start integrating code/scripts for remediation.
One constant feedback of current remediation scripts is they do not have "rollback." Do we want to assume that responsibility?
(I'm not sure if it's proper Netiquette to email multiple lists at once, but this is certainly relevant to Aqueduct and OpenSCAP too.)
scap-security-guide@lists.fedorahosted.org