Citing an extant schema URI propagates into generated XCCDF documents
which can then be validated using that schema.
The guide.xml document previously cited a non-existent relative URI.
Gary Gapinski (1):
Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI
RHEL6/input/guide.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
I intend to do a lot of editing. Is there a style guide?
It would help to have a uniform choice of line lengths, indent size,
etc. Or maybe no need in most places.
I use <oXygen/> XML Editor where a single click formats and indents a
Aside from line length, there's also attribute formatting, white space
preservation, empty line preservation, etc.
It does a pretty good job of detecting and preserving such
characteristics, but I'm unsure what's been chosen, if anything.
I prefer a 4-character indent to a two-character one.
Line length of about 140 seems reasonable. Some people go all-out and
choose 1000 or more, but that means a lot of horizontal scrolling just
to make diffs tidier. Less than 140 is a bit cramped.
For many documents, they'll ultimately be transformed, so perhaps there
should be a style for fragments as well as a different one for final
output. Again, this really only affects diff output, so I'd prefer
minimal style constraints over B&D ones, at least for fragments.
I'm sure there will be doctrinal discussions over white space line
breaks and such (white-space:(normal|pre|nowrap|pre-wrap|pre-line) stuff).
It would help as well to deliberately choose either an .xslt or .xsl
file name suffix convention. Either is fine with me.
> Shawn Wells <shawn(a)redhat.com> wrote:
> On 2/20/13 12:49 PM, Shaw, Ray V CTR (US) wrote:
> > Classification: UNCLASSIFIED
> > Caveats: NONE
> > During the public comment period, should I be sending comments to
> > regarding the benchmark content (which they didn't include in their
> > download), or just regarding the prose (e.g. "I would like to see ___
> > as an acceptable setting as well as the stated value of ____")?
> It is a little awkward and confusing.
> Feedback against the DISA RHEL6 STIG prose should be sent to DISA FSO.
> They are the publishing authority of the STIG and we don't want to
> avoid a situation where FSO is unaware of said feedback (and thus the
> feedback doesn't make it into the final STIG). Their EMail address is:
> With that said, the SSG serves as upstream for the RHEL6 STIG content.
> If you give us a heads up, we may be able to get it fixed before the
> public comment period even ends :) We also track feedback via our
> ticketing system, which allows us to correlate any reported findings
> with DISA FSO:
Thanks. I'll be sure to report anything where I would like to see a change in the actual requirement to the DISA address.
As a "for instance" for other cases, the prose for the password_min_age check appears to want this in login.defs:
which is fine, and is what we have. But the actual check appears to be looking for a value of "7 or higher", so it fails (using both tools; based on your comments regarding SCC, I won't report anything that fails on SCC but passes with Open SCAP).
I'm running into similar issues with the "gconftool-2" type rules, where I've run the indicated commands and they appear to have written to the appropriate places, but the checks are still failing. Should I just report things like that here?
[We also have an interesting issue where there is an inspection coming up, and we're not sure whether they're going to use the RHEL5 or RHEL6 draft STIG to evaluate RHEL6 systems. This is a problem, because there are a bunch of rules in them that conflict, e.g. /bin/true vs /bin/false or always,exit vs exit,always; explainable as equivalent and false positives, but makes scans for one or the other look awful. Hopefully the team will let us know shortly.]
Unix support, Army Research Labs
For those tracking such things, the SSG project has had dependency on
EPEL versions of OpenSCAP tooling. The choice was made to develop
against the EPEL version of OpenSCAP as it contained needed OVAL and
XCCDF resolve capabilities that were not yet in RHEL6. We planned
(err... crossed our fingers) that we'd be finishing up the SSG STIG work
approximately at the same time that RHEL6 rebases OpenSCAP, which would
be the approximate time DISA releases the Public and Final drafts....
.... And the stars aligned :)
RHEL 6.4 has just been released, which rebased to openscap-0.9.3-1. This
means both users and developers should have all the SCAP toolchain
components you need provided directly in RHEL6 . No more EPEL.
I was able to run a scan, generate the findings report, and create the
remediation scripts this morning. Everything appears working. Let the
mailing list know if you see anything in your own testing.
Would also love to attend such a session.
Sent from my mobile phone
From: Robert Sanders [rsanders(a)TrustedCS.com]
Received: Wednesday, 20 Feb 2013, 20:24
To: 'scap-security-guide(a)lists.fedorahosted.org' [scap-security-guide(a)lists.fedorahosted.org]
Subject: RE: Interested in a SCAP Security Guide / STIG hack session?
I think this is an *outstanding* idea. Most of my experience with the STIGs was tied to the old SRR scripts, and the learning curve on the new format has been steep. I'd also suggest to cover topics that have been addressed here a bit such as :
False positives (both identification of said and how to refer suggestions/fixes back to SSG/Disa)
> -----Original Message-----
> From: scap-security-guide-bounces(a)lists.fedorahosted.org
> On Behalf Of Shawn Wells
> Sent: Wednesday, February 20, 2013 2:06 PM
> To: scap-security-guide(a)lists.fedorahosted.org
> Subject: Interested in a SCAP Security Guide / STIG hack session?
> Over the past few months there has been a good bit of
> off-list chatting about hosting a hack session/meetup for the
> SSG. With the recent DISA publication of the draft STIG the
> timing seems right.
> So, would anyone be interested in meeting up where we could
> do things like:
> - Share knowledge on the installation of SSG. How do I
> run a scan?
> How do I customize settings? How do I get a report that I can
> show my ISSE/ISSM? How do I generate a Certification Test
> Plan, based off my customized rules?
> - Go a bit deeper, and understand how the code works.
> What is XCCDF? OVAL? OCIL? How do I add my own custom rules?
> - Prep your environment to submit patches back to the
> SSG. How do I setup git? How do I create a FedoraHosted account?
> - Chat about what additional profiles are needed. How
> should we handle CNSSI 12-53? What about PCI compliance?
> I'd like to specifically go through the RHEL6 STIG content,
> scans and generating C&A artifacts. Part of the idea on this would be
> attendees could take this setup home and use it to start providing
> feedback against the draft STIG.
> What do you guys think? Good idea? What topics should be covered?
> Jeff and I were chatting, and we'll likely be able to host
> either at the
> Red Hat office in Tysons Corner, VA, or at the IAD Mobility Lab in
> Annapolis Junction, MD. And there's nothing saying we wouldn't do two
> sessions, one per location.... we can work all that out once
> topics/agenda get sorted.
> scap-security-guide mailing list
scap-security-guide mailing list
During the public comment period, should I be sending comments to DISA
regarding the benchmark content (which they didn't include in their download),
or just regarding the prose (e.g. "I would like to see ___ as an acceptable
setting as well as the stated value of ____")?
I have about 67 total checks that are failing (using SCC 3.1...getting
somewhat different results with Open SCAP 0.9.3, which I will have more
details on later). Many of them are false positives (they comply with the
prose, but - IMHO - the benchmark check is getting it wrong). For the others,
I'd like a change in the actual requirement. I just want to make sure I'm
reporting the right things to the right place.
[I also plan to try to "become a developer" and make contributions so I don't
just feel like I'm complaining, but editing this sort of content is new to
The benchmark content I'm using is the recently rebased RPM
Unix support, Army Research Labs
I'd like to get some feedback on GEN001780. Asked DISA about this in a direct email some time ago and never heard anything back.
We had a customer having *major* problems with cronjobs after implementing this STIG. Lots of messages showing up in the logs about:
Bad item passed to pam_*_item()
pam_env(crond:setcred): pam_putenv: delete non-existent entry; mesg n
Back tracked finally to having 'mesg n' in /etc/environment.
So my questions:
1) Is this line item looking for *at least* of the listed files, or all files, to contain 'mesg n'?
2) The SCC tool seems to be looking for at a different set of files than the manual-xccdf document. Which is correct?
Manual doc - /etc/bashrc /etc/csh.cshrc /etc/csh.login /etc/csh.logout /etc/environment /etc/ksh.kshrc /etc/profile /etc/suid_profile /etc/profile.d/*
SCC - /etc/bashrc /etc/profile /etc/environment /etc/security/environ /etc/.login /etc/profile.d/*
3) Why is /etc/environment on this list? The pam_env.so module will process this file expecting to find "name=val" pairs, of which 'mesg n' isn't, so it barfs and this seems to upset the apple cart.
4) Why is /etc/security/environ in this list? I thought that was an AIX specific file, not Linux?
I'm posting this to another mailing list also, so folks may see it twice.
DISA has released and posted the Draft RHEL6 STIG here:
I've written up some language around what this means, timelines,
and usage here:
2013-02-12: DISA Initial Draft Released. Gives public a chance to
comment on the requirements (e.g., "this will break my system!").
2013-02-26: Public comment period ends. SCAP Security Guide community
addresses any findings.
2013-03-19: "Final Draft" release. Cycle of feedback repeats. OVAL
content to be included (the automated scanning piece).
2013-04/05: Production STIG released
Red Hat Public Sector