[PATCH] Update for input/system/software/updating.xml
by Michael J. McConachie
Added verbaige for systems that don't specifically use /etc/yum.conf in
the case of looking for "gpgcheck=1".
Many consider using /etc/yum.conf for all repo information to be an
odler, and depreciated method.
Most systems use /etc/yum.repos.d/(reponame).repo method, of which the check didn't have
an explanation for.
Added this "/etc/yum.repos.d/(reponame).repo" text, and retested rule.
<PASS>
11 years, 6 months
[PATCH] CCI fixes
by David Smith
fixed CCI mappings
David Smith (1):
moved CCIs appropriately
RHEL6/input/auxiliary/srg_support.xml | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
11 years, 6 months
RE: SSG Audit + Aqueduct Remediation Linking
by Ronayne, James K.
It might help to at least add the id attribute to fix.
Here is an example of how we initially planned to include CREs in a Windows benchmark.
<fixtext fixref="cre_com.example_31-5_fix">Set Domain Group Policy Object (Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options) using the IGroupPolicyObject interface. Network security: LAN Manager authentication level should be set to <sub idref=”lan_manager_authentication_level_var” />.</fixtext>
<fix id="cre_com.example_31-5_fix" system=”http://cre.mite.org/cre.xsd”>
cre:com.example:31-5:
lan_manager_authentication_level:<sub idref=”lan_manager_authentication_level_var” />
</fix>
Adding an id (ideally an id unique across across all remediations) provides the option of adding fixtext and makes it easier for us to turn it into a CRE at a later point if we want.
Jim
------------------------------
Message: 2
Date: Fri, 28 Sep 2012 16:26:11 +0000
From: Francisco Slavin <fslavin(a)tresys.com>
To: "scap-security-guide(a)lists.fedorahosted.org"
<scap-security-guide(a)lists.fedorahosted.org>
Subject: RE: SSG Audit + Aqueduct Remediation Linking
Message-ID:
<24EF0A937B77C942811D893DF06A28353A115D(a)Exchange10.columbia.tresys.com>
Content-Type: text/plain; charset="utf-8"
Feedback in-line. Unfortunately, I believe using unique XML markup under a <fix> tag invalidates the XCCDF document.
> -----Original Message-----
> From: scap-security-guide-bounces(a)lists.fedorahosted.org [mailto:scap-
> security-guide-bounces(a)lists.fedorahosted.org] On Behalf Of Jeffrey
> Blank
>
> I think it might make more sense to do it in XML instead of JSON.
> Mixing JSON and XML makes one's eyes bleed in two different ways
> instead of one way. But I suppose it's parseable and transformable
> either way.
Using XML occurred to me in order to be consistent with the rest of the document - I don't particularly like the mixed-up look, either.
Unfortunately, using XML in the document would render it invalid XCCDF. According to the XCCDF schema, the <sub> tag is the only XML tag that can be a child to a <fix> element. I tested out a simple JSON <fix> tag example to make sure it validated using xmllint. I tried the same <fix> tag example using some invented XML tags which don't occur elsewhere in the XCCDF schema and the document would no longer validate.
I feel that keeping the XCCDF document valid according to schema is a significant constraint for our approach with this, which takes unique XML markup out of consideration. If there's another way to do that I would be willing to consider it; I will readily admit I am not an XML expert.
Just to keep the SSG community posted, our approach for the next SecState release is to consume <fix> content with JSON markup. Based on the use cases I described previously and the constraint of keeping the XCCDF valid it seems to be the cleanest approach to me. We will certainly be open to shifting in the future if the community moves in a different direction or the schemas mature to the point where we can leverage SCAP-specific mechanisms to represent this information. This JSON <fix> tag support is targeted for the version of SecState that will ship with CLIP for RHEL 6.2.
>
> Have you given though to making it look (a little bit) like what's in
> the CRE spec for a cre_entry (pg 25)?
> http://csrc.nist.gov/publications/drafts/nistir-7831/Draft-NISTIR-
> 7831.pdf
>
> But perhaps in a more-convenient-for-human-editing format (something
> for which automated transformation may be possible to CRE)?
>
We did want to make sure we picked a standard, easily-transformable means of representing this information when we landed on JSON. We want to be able to support SCAP remediation specifications in the future as they mature. From taking a quick look at the CPE schema it seems like we could easily boilerplate in RHEL 6.2 info for the <platform> information that the CPE spec will track as the remediation content being developed matures.
Thank you
- Francisco Slavin
------------------------------
11 years, 6 months
SSG Audit + Aqueduct Remediation Linking
by Francisco Slavin
Hello,
As you may be aware, one of the key use cases for SecState has been automated remediation. We have shifted away from Puppet remediation to BASH remediation in response to community input & direction. At this time our core target is enabling users to use SSG content to audit a system and Aqueduct content to remediate a system. As we move forward with designing the "glue" to link the content together we would appreciate input from the community about the approach we're planning for this. We want to help find an approach for this which is agreeable to the content maintainers and lets us meet our use cases.
We are planning to continue using the <fix> tag with a custom system attribute string to indicate that the <fix> tag contains BASH remediation content. We are currently considering JSON notation as the leading candidate for writing the <fix> content because it is both easy to write and easy to parse. The information we want to make sure we cover for running a remediation script is:
* Path to the script
* Environment variables to define
* Positional arguments to pass in to the script
Using JSON notation in a <fix> tag, this would be the representation of that info:
<fix system="urn:xccdf:fix:script:bash">
{
"script" : "/usr/libexec/ssg/scripts/remediate_foo.sh"
"environment-variables" : {"FOO" : "12", "TEST" : "<sub idref="xccdf_variable_foo" />"}
"positional-args" : ["test","<sub idref=" other_xccdf_variable" />"]
}
</fix>
The array of positional-args would be assumed to be ordered. So this example would call:
FOO=12 TEST=<value of xccdf_variable_foo> /bin/bash /usr/libexec/ssg/scripts/remediate_foo.sh test <value of other_xccdf_variable>
We would appreciate any input & feedback regarding this approach.
Thank you
- Francisco Slavin
11 years, 6 months
[PATCH] more OCIL additions
by David Smith
Added more OCIL text, marked one fix text as pending further investigation
David Smith (1):
additional OCIL check text
RHEL6/input/services/dhcp.xml | 10 ++++++++++
RHEL6/input/services/nfs.xml | 12 ++----------
RHEL6/input/services/smb.xml | 11 +++++++++++
RHEL6/input/services/xorg.xml | 10 ++++++++++
RHEL6/input/system/accounts/pam.xml | 8 +++++++-
RHEL6/input/system/network/wireless.xml | 5 ++++-
RHEL6/input/system/permissions/execution.xml | 6 ++++++
RHEL6/input/system/permissions/mounting.xml | 3 +++
RHEL6/input/system/software/integrity.xml | 5 +++++
9 files changed, 58 insertions(+), 12 deletions(-)
11 years, 6 months
pam_passwdqc vs pam_cracklib
by Spencer R. Shimko
Is anyone strongly bound to pam_cracklib? The reason I ask is that the prose and OVAL checks are currently written for pam_cracklib. pam_cracklib doesn't enforce complexity requirements on UID 0. pam_passwdqc can enforce password complexity requirements on root with the "enforce=everyone" option. Many requirement sets do not differentiate between privilege users and unprivileged users in the I&A sections. As a result I'd like to switch to passwdqc. Unless there is opposition we'll put together a patch to make the switch.
Thanks,
--Spencer
11 years, 6 months
[PATCH] additional OCIL check text
by David Smith
Added and modified a few more of the OCIL checks.
David Smith (1):
added and modified OCIL check text
RHEL6/input/services/ldap.xml | 4 ++++
RHEL6/input/services/nfs.xml | 5 +++--
RHEL6/input/services/xorg.xml | 4 +++-
RHEL6/input/system/accounts/pam.xml | 6 ++++++
RHEL6/input/system/accounts/physical.xml | 6 ++++++
RHEL6/input/system/auditing.xml | 21 ++++++++++++++++++++-
RHEL6/input/system/software/integrity.xml | 4 ++++
7 files changed, 46 insertions(+), 4 deletions(-)
11 years, 6 months