scap-security-guide February 2013

scap-security-guide@lists.fedorahosted.org

24 participants
50 discussions

[PATCH] Changed xsi:schemalocation to use real XCCDF schema URI.
by Gary Gapinski 22 Feb '13

22 Feb '13

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(-) -- 1.7.10.4

3 4

Is there an XML style guide?
by Gary Gapinski 22 Feb '13

22 Feb '13

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 document. 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.

1 0

Re: Draft RHEL6 STIG Released! (UNCLASSIFIED)
by Shaw, Ray V CTR USARMY RDECOM ARL (US) 21 Feb '13

21 Feb '13

Classification: UNCLASSIFIED Caveats: NONE > 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 > 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 ____")? > > 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: > disa.letterkenny.FSO.mbx.stig-customer-support-mailbox(a)mail.mil > > 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: > https://fedorahosted.org/scap-security-guide/report/3 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: PASS_MIN_DAYS 1 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.] -- Ray Shaw Contractor, STG Unix support, Army Research Labs Classification: UNCLASSIFIED Caveats: NONE

3 3

RHEL 6.4 released, OpenSCAP rebased
by Shawn Wells 21 Feb '13

21 Feb '13

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.

1 0

RE: Interested in a SCAP Security Guide / STIG hack session?
by Thorsten Scherf 21 Feb '13

21 Feb '13

Would also love to attend such a session. Sent from my mobile phone -----Original Message----- 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) -Rob > -----Original Message----- > From: scap-security-guide-bounces(a)lists.fedorahosted.org > [mailto:scap-security-guide-bounces@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, > performing > 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(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

1 0

New RHEVM3 and OpenStack directories
by Shawn Wells 21 Feb '13

21 Feb '13

Hey Guys, I just pushed a patch to create two new working directories: OpenStack and RHEVM3. The patch was ~12MB hence not sending it to the list. Right now there is no content for either, just a skeleton of XCCDF. Same build scripts & processes. Over the next few weeks we should see activities mapping these against the Application SRG's. Progress can be tracked here: http://people.redhat.com/swells/scap-security-guide/OpenStack/output/table-… http://people.redhat.com/swells/scap-security-guide/RHEVM3/output/table-rhe… (again, nothing is there yet!)

2 3

Re: Draft RHEL6 STIG Released! (UNCLASSIFIED)
by Shaw, Ray V CTR USARMY RDECOM ARL (US) 21 Feb '13

21 Feb '13

Classification: UNCLASSIFIED Caveats: NONE 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 me.] The benchmark content I'm using is the recently rebased RPM (scap-security-guide-0.1-10.el6.noarch.rpm). Thanks, -- Ray Shaw Contractor, STG Unix support, Army Research Labs Classification: UNCLASSIFIED Caveats: NONE

3 2

RHEL5 GEN001780 questions
by Robert Sanders 20 Feb '13

20 Feb '13

Afternoon folks, 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. -Rob

2 2

Draft RHEL6 STIG Released!
by Shawn Wells 20 Feb '13

20 Feb '13

Hey Guys, DISA has released and posted the Draft RHEL6 STIG here: http://iase.disa.mil/stigs/os/unix/red_hat.html I've written up some language around what this means, timelines, and usage here: https://blog-shawndwells.rhcloud.com/2013/02/draft-rhel6-stig-released/ In short: 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 -Shawn -- Shawn Wells Red Hat Public Sector (e) shawn(a)redhat.com (c) 443.534.0130

7 13

[PATCH] Changes to log file Rules
by David Smith 15 Feb '13

15 Feb '13

1) New Rule for log file permissions 2) New Rule for log file location 3) Removed audit log permissions Rules 4) Added alt titles for the new Rules 5) Added new Rules to common.xml David Smith (1): Log file Rule changes RHEL6/input/auxiliary/alt-titles-stig.xml | 6 +++ RHEL6/input/profiles/common.xml | 8 ++-- RHEL6/input/system/auditing.xml | 4 +- RHEL6/input/system/logging.xml | 62 +++++++++++++++------------- RHEL6/input/system/permissions/files.xml | 22 ++++++++++ 5 files changed, 67 insertions(+), 35 deletions(-)

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide February 2013