February 2013 - scap-security-guide

note for the USGCB tickets
by Jeffrey Blank 11 Jul '13

11 Jul '13

Shawn (et al), The ticketing system shows me you'd opened up a bunch of tickets to add a "New rule" for items which were in the old RHEL 5 USGCB profile. Okay, great, this helps with ensuring there is continuation of that profile/baseline with some consistency. A few notes: 1) I've been able to close some of the tickets as "fixed", providing explanation as to why. Some of them are being handled through other mechanisms for RHEL 6. 2) If anybody starts executing on the other tickets, the goal is NOT to add new rules as the ticket says, but rather to conduct investigation to see if the Rule is applicable to RHEL 6 in the same way it was applicable to RHEL 5. 3) In the ticket titles, there is some of the odd CCE language which talks about disabling/enabling things "as appropriate". That's fine as an identifier (and the RHEL 6 USGCB did use some of this language). However, this style of language, which is intended for neither a human nor a machine, should never appear in the project's XCCDF. (Just in case anybody gets any ideas.) Thanks, Jeff -- ___________________________ Jeffrey Blank 410-854-8675 Technology and Systems Analysis / Network Components NSA Information Assurance

5 10

xsl:attribute: The attribute name 'xmlns' is not allowed.
by Brian Millett 05 Jun '13

05 Jun '13

Hello, I'm trying to get started with making the latest clone from the git repository and I get the following error: [bpm]$ git clone http://git.fedorahosted.org/git/scap-security-guide.gitscap-security-guide Cloning into 'scap-security-guide'... remote: Counting objects: 14016, done. remote: Compressing objects: 100% (5257/5257), done. remote: Total 14016 (delta 10574), reused 10664 (delta 7718) Receiving objects: 100% (14016/14016), 3.18 MiB | 2.17 MiB/s, done. Resolving deltas: 100% (10574/10574), done. [bpm]$ cd scap-security-guide/RHEL6/ [bpm]$ make all xsltproc -o output/rhel6-shorthand.xml input/guide.xslt input/guide.xml xmllint --format --output output/rhel6-shorthand.xml output/rhel6-shorthand.xml xsltproc -o output/unlinked-noprofiles-rhel6-xccdf.xml transforms/shorthand2xccdf.xslt output/rhel6-shorthand.xml compilation error: file transforms/shorthand2xccdf.xslt line 19 element attribute xsl:attribute: The attribute name 'xmlns' is not allowed. make: *** [shorthand2xccdf] Error 5 I've a fedora 18 , x86_64 installation. Any ideas? Thanks. -- Brian Millett "Shifts in paradigms often cause nose bleeds." Greg Glenn

4 6

scap-security-guide v0.1-10 released -- now with JBossEAP5!
by Shawn Wells 01 May '13

01 May '13

Friends, A rebase of the scap-security-guide RPM was *long* overdue! Please see the "Consume" section of the project wiki for download information: https://fedorahosted.org/scap-security-guide/ Highlights of SSG v0.1-10 include: - JBossEAP5 content! Utilizing content from the SCAP Security Guide project, on 29-JAN-2013 Red Hat corporately submitted paperwork to DISA FSO to begin the JBossEAP5 STIG process. SSG v0.1-10 reflects the OCIL, OVAL, and XCCDF content of this submission. Please refer to /usr/share/xml/scap/ssg/guide/JBossEAP5_Guide.html for details. We look forward to your feedback via the SSG mailing list! [1] - `man scap-security-guide` now provides sample usage of the content. - Several bugfixes relating to OVAL content. Many thanks to Brian Millet, Kenneth Stailey, Logan Rodrian, and all other members of the SSG community for the reports and patches! - The RHEL6 STIG profile was renamed "stig-rhel6-server" - A RHEL6 checklist has been included (/usr/share/xml/scap/ssg/guidestig-rhel6-server-guide.html). This outlines what specific rules are currently part of the profile. - A number of updates against NIST 800-53 mappings has been completed. Please see files under /usr/share/xml/scap/ssg/policytables/. [1] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

1 1

[PATCH] Add support for zipfile creation
by Shawn Wells 14 Mar '13

14 Mar '13

6 7

(no subject)
by Kenneth Stailey 01 Mar '13

01 Mar '13

Makefile:67: *** unterminated variable reference. Stop. Even in comments you must terminate variable references. Fix: ]$ git diff diff --git a/Makefile b/Makefile index d2e5e59..3a0f190 100644 --- a/Makefile +++ b/Makefile @@ -71,7 +71,7 @@ zipfile: # to cd into $(RPM_TMPDIR) cp RHEL6/output/ssg-* $(RPM_TOPDIR)/ZIP/ cp JBossEAP5/eap5-* $(RPM_TOPDIR)/ZIP/ - # Originally attempted to `cd $(RPM_TOPDIR/ZIP` and + # Originally attempted to `cd $(RPM_TOPDIR)/ZIP` and # make the zip from there, however it still placed it # at working directory. Should look into this sometime #

3 3

RHEL6 Draft STIG to DIACAP 8500 controls mapping?
by Philip Shuman 01 Mar '13

01 Mar '13

We are currently trying to map 8500 controls to the RHEL6 draft content (either the version from git or DISA's website would work). The RHEL5 STIG benchmark contains references to the IA controls, which allows the auditors to tie each check back to 8500. Here is an example from RedHat_5-V1R1_STIG_Benchmark-xccdf: Rule Title: The operating system must be a supported release. STIG ID: GEN000100 Rule ID: SV-27049r1_rule Vuln ID: V-11940 IA Controls:VIVM-1 Is there any mapping either between RHEL6 and 8500 or even between RHEL6 and RHEL5 that we could use to map these? It seems none of the RHEL6 identifiers in either the build from git or the DISA website are common with the past STIG content. Thanks, Philip

2 4

Interested in a SCAP Security Guide / STIG hack session?
by Saxon, William G CIV SPAWARSYSCEN-ATLANTIC, 58810 25 Feb '13

25 Feb '13

Yes, I'd be very interested in such a conference. As I read through your list of items, I kept thinking..."Yes, I need that". I'm in Norfolk, Virginia and would prefer Tysons, Corner. I would need some lead time to get funding in place as funding is difficult these days. If you plan to do this, how will it be advertised...I want to make sure I hear about it. Oh yes...the sooner the better. Thanks, Bill William G. (Bill) Saxon ND-0854-04 SPAWAR Atlantic NMCI email: bill.saxon(a)navy.mil (Preferred) SPAWAR email: saxon(a)spawar.navy.mil Desk: 757.443.0359 Cell: 757.292.3237 Chat: william.saxon(a)chat.dco.dod.mil Message: 4 Date: Wed, 20 Feb 2013 14:06:13 -0500 From: Shawn Wells <shawn(a)redhat.com> To: scap-security-guide(a)lists.fedorahosted.org Subject: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <51251EA5.3010404(a)redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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. ------------------------------ Message: 5 Date: Wed, 20 Feb 2013 19:24:03 +0000 From: Robert Sanders <rsanders(a)TrustedCS.com> 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? Message-ID: <848FB1215E2AD643A5E10D906091D3FB5B7A66(a)TCSEXCH1.tcs-sec.com> Content-Type: text/plain; charset="us-ascii" 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

2 1

RE: Interested in a SCAP Security Guide / STIG hack session?
by Mackanick, Jason W CIV DISA RE (US) 25 Feb '13

25 Feb '13

I like the idea about the session. Be careful in any advertising of using the word "conference". I know at DISA, with the pending sequestration/furlough, all conference attendance has been halted. -----Original Message----- From: scap-security-guide-bounces(a)lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of scap-security-guide-request(a)lists.fedorahosted.org Sent: Monday, February 25, 2013 8:23 AM To: scap-security-guide(a)lists.fedorahosted.org Subject: scap-security-guide Digest, Vol 18, Issue 28 Send scap-security-guide mailing list submissions to scap-security-guide(a)lists.fedorahosted.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide or, via email, send a message with subject or body 'help' to scap-security-guide-request(a)lists.fedorahosted.org You can reach the person managing the list at scap-security-guide-owner(a)lists.fedorahosted.org When replying, please edit your Subject line so it is more specific than "Re: Contents of scap-security-guide digest..." Today's Topics: 1. Re: [PATCH] Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI (Shawn Wells) 2. Re: [PATCH] Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI (Gary Gapinski) 3. Re: [PATCH] Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI (Gary Gapinski) 4. Re: [PATCH] [RFC] Modularized the fix scripts (Jeffrey Blank) 5. Re: [PATCH] [RFC] Modularized the fix scripts (Jeffrey Blank) 6. Re: Interested in a SCAP Security Guide / STIG hack session? (Jeffrey Blank) 7. Interested in a SCAP Security Guide / STIG hack session? (Saxon, William G CIV SPAWARSYSCEN-ATLANTIC, 58810) ---------------------------------------------------------------------- Message: 1 Date: Thu, 21 Feb 2013 22:34:56 -0500 From: Shawn Wells <shawn(a)redhat.com> To: scap-security-guide(a)lists.fedorahosted.org Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI Message-ID: <5126E760.6010103(a)redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed On 2/21/13 8:42 PM, Gary Gapinski wrote: > -<Benchmark xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:dc="http://purl.org/dc/elements/1.1/" id="RHEL-6" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1 xccdf-1.1.4.xsd" resolved="false" xml:lang="en-US" > > +<Benchmark xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:dc="http://purl.org/dc/elements/1.1/" id="RHEL-6" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1 http://scap.nist.gov/schema/xccdf/1.1/xccdf-1.1.4.xsd" resolved="false" xml:lang="en-US" > The new schemaLocation has two URLs in it (but you're right, that needs to be http://scap.nist.gov/schema/xccdf/1.1/xccdf-1.1.4.xsd) ------------------------------ Message: 2 Date: Thu, 21 Feb 2013 22:46:26 -0500 From: Gary Gapinski <Gapinski(a)nasa.gov> To: "scap-security-guide(a)lists.fedorahosted.org" <scap-security-guide(a)lists.fedorahosted.org> Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI Message-ID: <5126EA12.8070901(a)nasa.gov> Content-Type: text/plain; charset="UTF-8" On 02/21/2013 10:34 PM, Shawn Wells wrote: > > The new schemaLocation has two URLs in it Not sure what you mean by this. The first space-separated URI is the namespace; the second is the associated schema. ------------------------------ Message: 3 Date: Thu, 21 Feb 2013 22:49:21 -0500 From: Gary Gapinski <Gapinski(a)nasa.gov> To: <scap-security-guide(a)lists.fedorahosted.org> Subject: Re: [PATCH] Changed xsi:schemalocation to cite "canonical" XCCDF 1.1.4 schema URI Message-ID: <5126EAC1.3050902(a)nasa.gov> Content-Type: text/plain; charset="UTF-8" On 02/21/2013 10:46 PM, Gary Gapinski wrote: > On 02/21/2013 10:34 PM, Shawn Wells wrote: >> The new schemaLocation has two URLs in it > Not sure what you mean by this. The first space-separated URI is the > namespace; the second is the associated schema. > The diff is not showing proper old and new. The old had xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1 xccdf-1.1.4.xsd". The new has xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.1 http://scap.nist.gov/schema/xccdf/1.1/xccdf-1.1.4.xsd". ------------------------------ Message: 4 Date: Sun, 24 Feb 2013 11:14:51 -0500 From: Jeffrey Blank <blank(a)eclipse.ncsc.mil> To: scap-security-guide(a)lists.fedorahosted.org Subject: Re: [PATCH] [RFC] Modularized the fix scripts Message-ID: <512A3C7B.5060109(a)eclipse.ncsc.mil> Content-Type: text/plain; charset=UTF-8 > It may be long-term necessary to consider alternatives. True in so very many ways. But I'd be more concerned that XCCDF is likely to ossify irrevocably, given its current position with standards bodies. > If it is now close to the time when a namespace (or two) for > scap-security-guide fragments, and a schema for those, can be > considered, I'd be willing to put up a trial balloon. I'd be happy to look at it, but I have serious doubts that it's actually a good idea. The ability to do some arbitrary things (which such formalization is likely to forbid or inhibit) is very valuable, such as macros for common phrases. Schemas are requirements levied upon content developers. I also want to keep the content language as simple as possible, and as even Shawn's brief confusion indicated, XML namespaces don't exactly make things more accessible. Removing all namespaces from the (undefined) content creation language was quite intentional. To the extent possible, I wanted to end up in a place where the content creation language could be "monkey-see, monkey-do." (Even though that clearly hasn't worked out, I'd at least prefer that it not be endlessly verbose to higher primates). > This ultimately > becomes an exercise in avoiding arbitrary limitations of XCCDF by > allowing reasonable and useful expression ahead of (SP 800-126 rev 1) > XCCDF generation. As in variables that end up manifest in checks and > fixes. Ideally, the same meaning of value/variable (e.g., password > length) in all venues. That is sane, and exactly what my little scripts actually are trying to achieve (well, technically, undo for final output) in their "linking" phase. > I don't think XCCDF should be levied on content authors, rather, > something useful that can be competently turned into XCCDF should be > provided. Accompanied by a schema. It can be better than XCCDF; the > shortcomings of such a transformation can be noted so that the > proto-XCCDF/OVAL content can be dumbed-down as and if necessary. Yes, as usual, yes. But I'd still prioritize vetting and creation of (openly-available) content in the deficient (or undefined) languages we've got now. It remains shocking to me how little high-quality SCAP content there is, yet there seem to be thousands of people at these conferences... ------------------------------ Message: 5 Date: Sun, 24 Feb 2013 12:09:50 -0500 From: Jeffrey Blank <blank(a)eclipse.ncsc.mil> To: scap-security-guide(a)lists.fedorahosted.org Subject: Re: [PATCH] [RFC] Modularized the fix scripts Message-ID: <512A495E.3040607(a)eclipse.ncsc.mil> Content-Type: text/plain; charset=UTF-8 > tag is basically just a reference to a <value> somewhere. I know > I've caught some flack for the JSON usage, but it was a practical way > to get things implemented. Given that we can't use arbitrary XML to > keep the document all-XML, and that whatever we do within a <fix> tag > ends up being pseudo-standard at best, JSON has proven to be a > lightweight option for use as an intermediate solution. We can do whatever we want with XML in our authoring language, and we're not writing in any particular schema (as Gary has pointed out). As far as I'm concerned, final output should be valid XCCDF, but you can do anything you want with XML until then. (And tooling that prepares the fixes for execution can take care of preparing the environment to run the bash script, such as instantiating environment variables.) And your perception is correct: attempts to introduce JSON (or Perl) into SSG should expect serious resistance. Had we started all development in JSON, then I'd say the same about XML. > I know there was a discussion about having a better way to uniquely > identify fixes besides just a path to a script on a system. Possibly > some UUID which in turn maps to a script somewhere? I want fixes to identify what they're for (by referencing a Rule id), not the other way around. What <fix> to run is not the concern of the baseline or guidance creator, and remediation is not the raison d'etre of scap-security-guide. But we're happy to work closely together and include simple bash fixes inside the project. In essence, I would encourage remediation developers to refer to items in the input/system and input/services (and input/profiles) directories, and develop tooling that permits combination and integration with the content generated from there. > If there's a > standards-based way to do this it would be great, but with how > immature the <fix> aspect of XCCDF is I'm not sure if that option is > there. Having some pseudo-standard in place here gives us > flexibility to add fields or metadata as needed without invalidating > the XCCDF document, whereas if there were raw BASH content in the > <fix> tag we would not have that sort of flexibility. My motivation to look into the "right" way to do remediation will be far higher when someone can assure me that the OVAL has actually been QA'ed. Could you advise on current status of this? Is this still a dependency of CLIP? > I'll chime in again with an opinion that I think BASH and non-XCCDF > content should live in files external to the XCCDF, and simply be > referenced from the XCCDF. Absolutely! Like we do now in SSG, for development. I'm assuming there will be one XCCDF file from SSG with simple bash fixes, and one without. In fact, that reminds me to adjust the Makefile so that what is perceived as the "main" one does not include fixes. > I'll chime in again with an opinion that I think BASH and non-XCCDF > content should live in files external to the XCCDF, and simply be > referenced from the XCCDF. I know this is a discussion that's been > had a few times, and this may be a battle I've already lost, so kick > me if I shouldn't be bringing this back up. Definitely -- no development of <fix> tags is occurring inline with the main content. The fix tags live inside their own directories away from where the usual XCCDF content is written. I don't expect issuers of baselines to include <fix> tags, and the act of adding fixes is intentionally seperable/separated. It may be possible to ship one version of the XCCDF file with bash fixes, and some tooling may be able to process this, but this shouldn't preclude any other approaches. ------------------------------ Message: 6 Date: Sun, 24 Feb 2013 13:54:39 -0500 From: Jeffrey Blank <blank(a)eclipse.ncsc.mil> To: scap-security-guide(a)lists.fedorahosted.org Subject: Re: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <512A61EF.5040002(a)eclipse.ncsc.mil> Content-Type: text/plain; charset=UTF-8 Let DISA FSO know if there are problems in what they've shipped in their official content, using their established process. Given that the SSG's intention is to be an upstream producer of content that meets their requirements, it may also make sense to notify us if we have the same problem (assuming it hasn't already been fixed upstream). On 02/20/2013 02:24 PM, Robert Sanders wrote: > 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 ------------------------------ Message: 7 Date: Mon, 25 Feb 2013 08:22:42 -0500 From: "Saxon, William G CIV SPAWARSYSCEN-ATLANTIC, 58810" <bill.saxon(a)navy.mil> To: <scap-security-guide(a)lists.fedorahosted.org> Subject: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <9E3670CE3E72114D8FDF5E0384EC030901966DE9(a)naeanrfkez38v.nadsusea.nads.navy.mil> Content-Type: text/plain; charset="US-ASCII" Yes, I'd be very interested in such a conference. As I read through your list of items, I kept thinking..."Yes, I need that". I'm in Norfolk, Virginia and would prefer Tysons, Corner. I would need some lead time to get funding in place as funding is difficult these days. If you plan to do this, how will it be advertised...I want to make sure I hear about it. Oh yes...the sooner the better. Thanks, Bill William G. (Bill) Saxon ND-0854-04 SPAWAR Atlantic NMCI email: bill.saxon(a)navy.mil (Preferred) SPAWAR email: saxon(a)spawar.navy.mil Desk: 757.443.0359 Cell: 757.292.3237 Chat: william.saxon(a)chat.dco.dod.mil Message: 4 Date: Wed, 20 Feb 2013 14:06:13 -0500 From: Shawn Wells <shawn(a)redhat.com> To: scap-security-guide(a)lists.fedorahosted.org Subject: Interested in a SCAP Security Guide / STIG hack session? Message-ID: <51251EA5.3010404(a)redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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. ------------------------------ Message: 5 Date: Wed, 20 Feb 2013 19:24:03 +0000 From: Robert Sanders <rsanders(a)TrustedCS.com> 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? Message-ID: <848FB1215E2AD643A5E10D906091D3FB5B7A66(a)TCSEXCH1.tcs-sec.com> Content-Type: text/plain; charset="us-ascii" 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 ------------------------------ _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide End of scap-security-guide Digest, Vol 18, Issue 28 ***************************************************

1 0

Interested in a SCAP Security Guide / STIG hack session?
by Shawn Wells 24 Feb '13

24 Feb '13

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.

3 2

[PATCH] [RFC] Modularized the fix scripts
by Shawn Wells 24 Feb '13

24 Feb '13

6 15

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

21 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 21 Feb '13

21 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 20 Feb '13

20 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) 20 Feb '13

20 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 19 Feb '13

19 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

Fwd: SCAP Compliance Checker 3.1 Final Release
by Shawn Wells 13 Feb '13

13 Feb '13

Question for the group: The SCC tool requires that content be packaged in a zip file, and has no current or planned capability to read files from the industry accepted location of /usr/share/xml/scap/*. Should we create a zip file in addition to the RPM? -------- Original Message -------- Subject: SCAP Compliance Checker 3.1 Final Release Date: Wed, 13 Feb 2013 11:16:33 -0500 From: SSC LANT-SCC <ssc_lant-scc.fcm(a)navy.mil> To: SSC LANT-SCC <ssc_lant-scc.fcm(a)navy.mil> We would like to thank everyone that was involved in the SCC 3.1 Beta and Release Candidate testing over the past month. We are pleased to announce that we have finished development of SCC 3.1. Since several bugs were fixed from SCC 3.0.2 to SCC 3.1, we highly recommend upgrading to SCC 3.1. You'll be receiving an email from AMRDEC in the next hour with download instructions Primary Changes from SCC 3.0.x to 3.1 For All Platforms . Updated default location for Logs and Results to be dynamic based on each user's profile/home directory. . Added applicable DISA STIG SCAP Benchmarks to each installer. . Added new OVAL Processing Options, which allows the user to exclude certain OVAL features which known to cause system resource issues. . Added support for OVAL 'unique' function. . Added support for OVAL 'count' function. . Added ability to copy results via SSH to a centralized server. . Improved OCIL functionality to allow for resuming of partially completed questionnaires. . Improved documentation in the User Manual. For Windows . Added ability to install and run as a service. . Added support for case insensitivity to several OVAL tests . Added support for OVAL windows cmdlet test, object, state. . Updated registry tests to support OVAL 5.10 'windows_view'. . Updated file test to support OVAL 5.10 'windows_view'. For UNIX For all UNIX (Linux, Solaris, Mac OS X) . Added support for OVAL UNIX fileextendedattribute test, object, state. . Added support for UNIX sysctl test, object, state. For Linux . Added support for linux selinuxboolean test, object, state. . Added support for linux selinuxsecuritycontext test, object, state. . Added support for linux rpmverifyfile test, object, state. . Added support for linux rpmverify test, object, state. . Added support for linux rpmverifypackage test, object, state. For Solaris . Added support for Solaris packagecheck test, object, state. For Mac OS X Added support for Mac OS X including all applicable UNIX, Independent and all macos oval tests. Kyle R. Stone SPAWAR Systems Center Atlantic Code 58600 (843) 218-5091 kyle.r.stone(a)navy.mil

6 5

Ok, a new attempt at submitting a patch to accounts_password_hashing_algorithm.xml
by Brian Millett 12 Feb '13

12 Feb '13

Here is a patch for RHEL6/input/checks/accounts_password_hashing_algorithm.xml -- Brian Millett "Shifts in paradigms often cause nose bleeds." Greg Glenn

1 0

[PATCH 0/2] *** SUBJECT HERE ***
by Brian Millett 11 Feb '13

11 Feb '13

*** BLURB HERE *** root (2): Some minor cosmetic changes, but a major change to the REGEX to correctly match sha512 no matter where it is on the line see: "^[\s]*password[\s]+sufficient[\s]+(?:[\w_\.\-=\s]+[\s])sha512" vs "^\s*password\s+sufficient\s+pam_unix.so\s+sha512.*$" added extra values for the dcredit, ucredit, etc. then removed the comments so the oval check will be created. .../checks/accounts_password_hashing_algorithm.xml | 20 +++++++++++------ RHEL6/input/system/accounts/pam.xml | 22 ++++++++++---------- 2 files changed, 24 insertions(+), 18 deletions(-)

2 3

some questions about the checks / oval tests
by Brian Millett 11 Feb '13

11 Feb '13

I'm trying to understand (as an example) the following results from an evaluation on a rhel6.3 box using the stig-rhel6-server profile. And I apologize if these questions are answered in a FAQ somewhere. 1) Ensure Log Files Are Owned By Appropriate Group unknown Ensure System Log Files Have Correct Permissions unknown 2) All GIDs referenced in /etc/passwd must be defined in /etc/group notchecked Ensure All Accounts on the System Have Unique Names notchecked I understand that the "notchecked" is because there is not an oval test defined and the "unknown" is a specific "I don't know", as in the rsyslog_files_groupownership.xml: <ind:unknown_test check="all" comment="use extended content to evaluated this test" id="test_20155" version="1" /> So I've been reading the oval language definitions and I cannot see how to address the "unknown" tests which require parsing a file to get parts out of it (rsyslog wants defined log paths). Q) How does one go about writing a test that takes the result from evaluating a script? What is the "extended content"?? Q) Are the "notchecked" tests because the check is too vague? Or just not written yet? Any documents I should be reading? Thanks. -- Brian Millett "Terrible to see places I grew up going up in flames." -- [ Sinclair, "A Voice in the Wilderness I"]

4 5

[PATCH] added CCEs
by David Smith 11 Feb '13

11 Feb '13

--- RHEL6/input/services/base.xml | 30 ++++++++++---------- RHEL6/input/services/nfs.xml | 2 +- RHEL6/input/services/obsolete.xml | 4 +- RHEL6/input/system/accounts/banners.xml | 2 +- RHEL6/input/system/accounts/pam.xml | 6 ++-- .../accounts/restrictions/password_storage.xml | 2 +- RHEL6/input/system/auditing.xml | 12 ++++---- RHEL6/input/system/logging.xml | 4 +- RHEL6/input/system/network/ipv6.xml | 8 ++-- RHEL6/input/system/permissions/mounting.xml | 2 +- RHEL6/input/system/software/integrity.xml | 6 ++-- 11 files changed, 39 insertions(+), 39 deletions(-) diff --git a/RHEL6/input/services/base.xml b/RHEL6/input/services/base.xml index b0ebf16..5b1aae4 100644 --- a/RHEL6/input/services/base.xml +++ b/RHEL6/input/services/base.xml @@ -20,7 +20,7 @@ system such as RHTSupport. <rationale> Mishandling crash data could expose sensitive information about vulnerabilities in software executing on the local machine, as well as sensitive information from within a process's address space or registers.</rationale> -<ident cce="TODO" /> +<ident cce="27247-6" /> <oval id="service_abrtd_disabled" /> <ref nist="AC-17(8),CM-7" disa="381" /> </Rule> @@ -58,7 +58,7 @@ out activities outside of a normal login session, which could complicate accountability. Furthermore, the need to schedule tasks with <tt>at</tt> or <tt>batch</tt> is not common. </rationale> -<ident cce="TODO" /> +<ident cce="27249-2" /> <oval id="service_atd_disabled" /> <ref nist="CM-7" disa="381" /> </Rule> @@ -75,7 +75,7 @@ solution to aid in the management of certificates. <rationale>The services provided by certmonger may be essential for systems fulfilling some roles a PKI infrastructure, but its functionality is not necessary for many other use cases.</rationale> -<ident cce="TODO" /> +<ident cce="27267-4" /> <oval id="service_certmonger_disabled" /> <ref nist="CM-7" /> </Rule> @@ -91,7 +91,7 @@ a system. The <tt>cgconfig</tt> daemon starts at boot and establishes the predef <rationale>Unless control groups are used to manage system resources, running the cgconfig service is not necessary. </rationale> -<ident cce="TODO" /> +<ident cce="27250-0" /> <oval id="service_cgconfig_disabled" /> <ref nist="CM-7" /> </Rule> @@ -106,7 +106,7 @@ parameters set in the <tt>/etc/cgrules.conf</tt> configuration file. <rationale>Unless control groups are used to manage system resources, running the cgred service service is not necessary. </rationale> -<ident cce="TODO" /> +<ident cce="27252-6" /> <oval id="service_cgred_disabled" /> <ref nist="CM-7" /> </Rule> @@ -243,7 +243,7 @@ serial consoles are impractical. <rationale>The <tt>netconsole</tt> service is not necessary unless there is a need to debug kernel panics, which is not common. </rationale> -<ident cce="TODO" /> +<ident cce="27254-2" /> <oval id="service_netconsole_disabled" /> <ref nist="AC-17(8),CM-7" disa="381" /> </Rule> @@ -262,7 +262,7 @@ system time. are rebooted frequently enough that clock drift does not cause problems between reboots. In any event, the functionality of the ntpdate service is now available in the ntpd program and should be considered deprecated.</rationale> -<ident cce="TODO" /> +<ident cce="27256-7" />  <ref nist="AC-17(8),AU-8,CM-7" disa="382" /> <tested by="DS" on="20121024"/> @@ -281,7 +281,7 @@ applications. Communication with <tt>oddjobd</tt> through the system message bus some environments but it can be disabled if it is not needed. Execution of tasks by privileged programs, on behalf of unprivileged ones, has traditionally been a source of privilege escalation security issues.</rationale> -<ident cce="TODO" /> +<ident cce="27257-5" /> <oval id="service_oddjobd_disabled" /> <ref nist="CM-7" disa="381" /> <tested by="DS" on="20121024"/> @@ -298,7 +298,7 @@ required for other services. <rationale>The <tt>portreserve</tt> service provides helpful functionality by preventing conflicting usage of ports in the reserved port range, but it can be disabled if not needed.</rationale> -<ident cce="TODO" /> +<ident cce="27258-3" /> <oval id="service_portreserve_disabled" /> <ref nist="AC-17(8),CM-7" /> <tested by="DS" on="20121024"/> @@ -316,7 +316,7 @@ user activity, such as commands issued by users of the system. view into some user activities. However, it should be noted that the auditing system and its audit records provide more authoritative and comprehensive records.</rationale> -<ident cce="TODO" /> +<ident cce="27259-1" /> <oval id="service_psacct_enabled" /> <ref nist="AU-12,CM-7" /> <tested by="DS" on="20121024"/> @@ -356,7 +356,7 @@ last accessed. remain enabled. However, if disk quotas are not used or user notification of disk quota violation is not desired then there is no need to run this service.</rationale> -<ident cce="TODO" /> +<ident cce="27260-9" /> <oval id="service_quota_nld_disabled" /> <ref nist="CM-7" /> <tested by="DS" on="20121024"/> @@ -375,7 +375,7 @@ updated with a corresponding default route. By default this daemon is disabled. information configured statically by a system administrator. Workstations or some special-purpose systems often use DHCP (instead of IRDP) to retrieve dynamic network configuration information.</rationale> -<ident cce="TODO" /> +<ident cce="27261-7" /> <oval id="service_rdisc_disabled" /> <ref nist="AC-17(8),AC-4,CM-7" disa="382" /> <tested by="DS" on="20121024"/> @@ -413,7 +413,7 @@ additional control over which of their systems are entitled to particular subscriptions. However, for systems that are managed locally or which are not expected to require remote changes to their subscription status, it is unnecessary and can be disabled.</rationale> -<ident cce="TODO" /> +<ident cce="27262-5" /> <oval id="service_rhsmcertd_disabled" /> <ref nist="CM-7" /> <tested by="DS" on="20121024"/> @@ -433,7 +433,7 @@ based authentication. performing authentication in some directory environments, such as those which use Kerberos and LDAP. For others, however, in which only local files may be consulted, it is not necessary and should be disabled.</rationale> -<ident cce="TODO" /> +<ident cce="27263-3" /> <oval id="service_saslauthd_disabled" /> <ref nist="AC-17(8),CM-7" /> <tested by="DS" on="20121024"/> @@ -490,7 +490,7 @@ at boot time. boot to reset the statistics, which can be retrieved using programs such as <tt>sar</tt> and <tt>sadc</tt>. These may provide useful insight into system operation, but unless used this service can be disabled.</rationale> -<ident cce="TODO" /> +<ident cce="27265-8" /> <oval id="service_sysstat_disabled" /> <ref nist="CM-7" /> <tested by="DS" on="20121024"/> diff --git a/RHEL6/input/services/nfs.xml b/RHEL6/input/services/nfs.xml index d9f8d8f..1dec65d 100644 --- a/RHEL6/input/services/nfs.xml +++ b/RHEL6/input/services/nfs.xml @@ -125,7 +125,7 @@ communicate with. Unless RPC services are needed on the local system it is recommended to disable this service. <service-disable-macro service="rpcbind" /> </description> -<ident cce="TODO" /> +<ident cce="27268-2" /> <oval id="service_rpcbind_disabled" /> </Rule> diff --git a/RHEL6/input/services/obsolete.xml b/RHEL6/input/services/obsolete.xml index c07a15e..9105152 100644 --- a/RHEL6/input/services/obsolete.xml +++ b/RHEL6/input/services/obsolete.xml @@ -201,7 +201,7 @@ of an Rsh trust relationship. <rationale>Trust files are convenient, but when used in conjunction with the R-services, they can allow unauthenticated access to a system.</rationale> -<ident cce="TODO" /> +<ident cce="27270-8" /> <ref nist="AC-17(8),CM-7" disa="1436" /> <oval id="no_rsh_trusted_host_files" /> <tested by="DS" on="20121026"/> @@ -316,7 +316,7 @@ flag, matching the example below: <pre> # grep "server_args" /etc/xinetd.d/tftp server_args = -s /var/lib/tftpboot</pre> </ocil> -<ident cce="TODO" /> +<ident cce="27272-4" /> <oval id="tftpd_uses_secure_mode" /> <ref nist="AC-17(8),CM-7" disa="366"/> </Rule> diff --git a/RHEL6/input/system/accounts/banners.xml b/RHEL6/input/system/accounts/banners.xml index 0b22d71..1a441e0 100644 --- a/RHEL6/input/system/accounts/banners.xml +++ b/RHEL6/input/system/accounts/banners.xml @@ -168,7 +168,7 @@ The output should be <tt>true</tt>. <rationale>Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to quickly enumerate known user accounts without logging in.</rationale> -<ident cce="TODO" /> +<ident cce="27230-2" /> <ref nist="AC-23" /> </Rule> diff --git a/RHEL6/input/system/accounts/pam.xml b/RHEL6/input/system/accounts/pam.xml index 9089911..5c8344a 100644 --- a/RHEL6/input/system/accounts/pam.xml +++ b/RHEL6/input/system/accounts/pam.xml @@ -238,7 +238,7 @@ Look for the value of the <tt>maxrepeat</tt> parameter. The DoD requirement is <rationale> Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks. </rationale> -<ident cce="TODO" /> +<ident cce="27227-8" /> <ref disa="366"/> </Rule> @@ -535,7 +535,7 @@ Inspect <tt>/etc/login.defs</tt> and ensure the following line appears: Using a stronger hashing algorithm makes password cracking attacks more difficult. </rationale>  -<ident cce="TODO" /> +<ident cce="27228-6" /> <ref nist="IA-5" disa="803"/> <tested by="DS" on="20121024"/> </Rule> @@ -557,7 +557,7 @@ in the <tt>[default]</tt> section: Using a stronger hashing algorithm makes password cracking attacks more difficult. </rationale>  -<ident cce="TODO" /> +<ident cce="27229-4" /> <ref nist="IA-5" disa="803"/> <tested by="DS" on="20121026"/> </Rule> diff --git a/RHEL6/input/system/accounts/restrictions/password_storage.xml b/RHEL6/input/system/accounts/restrictions/password_storage.xml index 53bc053..be8ed82 100644 --- a/RHEL6/input/system/accounts/restrictions/password_storage.xml +++ b/RHEL6/input/system/accounts/restrictions/password_storage.xml @@ -105,7 +105,7 @@ Unencrypted passwords for remote FTP servers may be stored in <tt>.netrc</tt> files. DoD policy requires passwords be encrypted in storage and not used in access scripts. </rationale> -<ident cce="TODO" /> +<ident cce="27225-2" /> <oval id="TODO" /> <ref nist="IA-5" disa="196" /> </Rule> diff --git a/RHEL6/input/system/auditing.xml b/RHEL6/input/system/auditing.xml index 6943c14..2142b44 100644 --- a/RHEL6/input/system/auditing.xml +++ b/RHEL6/input/system/auditing.xml @@ -304,7 +304,7 @@ minimizes the chances of the system unexpectedly running out of disk space by being overwhelmed with log data. However, for systems that must never discard log data, or which use external processes to transfer it and reclaim space, <tt>keep_logs</tt> can be employed.</rationale> -<ident cce="TODO" /> +<ident cce="27237-7" /> <oval id="auditd_data_retention_max_log_file_action" value="var_auditd_max_log_file_action" /> <ref nist="AU-1(b),AU-4,AU-11" /> <tested by="DS" on="20121024"/> @@ -355,7 +355,7 @@ disk space is starting to run low: </ocil> <rationale>Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.</rationale> -<ident cce="TODO" /> +<ident cce="27238-5" /> <oval id="auditd_data_retention_space_left_action" value="var_auditd_space_left_action"/> <ref nist="AU-1(b),AU-4" disa="140,143,1339" /> <tested by="DS" on="20121024"/> @@ -396,7 +396,7 @@ when disk space has run low: audit records. If a separate partition or logical volume of adequate size is used, running low on space for audit records should never occur. </rationale> -<ident cce="TODO" /> +<ident cce="27239-3" /> <oval id="auditd_data_retention_admin_space_left_action" value="var_auditd_admin_space_left_action" /> <ref nist="AU-1(b),AU-4" disa="140,1343" /> <tested by="DS" on="20121024"/> @@ -419,7 +419,7 @@ account when it needs to notify an administrator: </ocil> <rationale>Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action.</rationale> -<ident cce="TODO" /> +<ident cce="27241-9" /> <oval id="auditd_data_retention_action_mail_acct" value="var_auditd_action_mail_acct" /> <ref nist="AU-1(b),AU-4" disa="139,144" /> </Rule> @@ -695,7 +695,7 @@ Audit logs must be mode 0640 or less permissive. <rationale> If users can write to audit logs, audit trails can be modified or destroyed. </rationale> -<ident cce="TODO" /> +<ident cce="27243-5" /> <oval id="file_permissions_var_log_audit" /> <ref nist="AC-6,AU-1(b),AU-9" disa="166" /> <tested by="DS" on="20121024"/> @@ -711,7 +711,7 @@ If users can write to audit logs, audit trails can be modified or destroyed. </ocil> <rationale>Failure to give ownership of the audit log file(s) to root allows the designated owner, and unauthorized users, potential access to sensitive information.</rationale> -<ident cce="TODO" /> +<ident cce="27244-3" /> <oval id="file_ownership_var_log_audit" /> <ref nist="AC-6,AU-1(b),AU-9" disa="166" /> <tested by="DS" on="20121024"/> diff --git a/RHEL6/input/system/logging.xml b/RHEL6/input/system/logging.xml index 12bf472..9ff9334 100644 --- a/RHEL6/input/system/logging.xml +++ b/RHEL6/input/system/logging.xml @@ -314,7 +314,7 @@ $InputTCPServerRun 514</pre> If the system needs to act as a log server, this ensures that it can receive messages over a reliable TCP connection. </rationale> -<ident cce="TODO" /> +<ident cce="27235-1" />  <ref nist="AU-9" /> </Rule> @@ -333,7 +333,7 @@ Many devices, such as switches, routers, and other Unix-like systems, may only s the traditional syslog transmission over UDP. If the system must act as a log server, this enables it to receive their messages as well. </rationale> -<ident cce="TODO" /> +<ident cce="27236-9" />  <ref nist="AU-9" /> </Rule> diff --git a/RHEL6/input/system/network/ipv6.xml b/RHEL6/input/system/network/ipv6.xml index 336e619..f273d0d 100644 --- a/RHEL6/input/system/network/ipv6.xml +++ b/RHEL6/input/system/network/ipv6.xml @@ -60,7 +60,7 @@ For each network interface, add or correct the following lines in prevention mechanism: <pre>IPV6INIT=no</pre> </description> -<ident cce="TODO" /> +<ident cce="27231-0" /> <ref nist="CM-7" /> <tested by="DS" on="20121024"/> </Rule> @@ -75,7 +75,7 @@ following two lines in <tt>/etc/netconfig</tt>: <pre>udp6 tpi_clts v inet6 udp - - tcp6 tpi_cots_ord v inet6 tcp - -</pre> </description> -<ident cce="TODO" /> +<ident cce="27232-8" /> <oval id="network_ipv6_disable_rpc" /> <ref nist="CM-7" /> </Rule> @@ -171,7 +171,7 @@ Manually assigning an IP address is preferable to accepting one from routers or from the network otherwise. The example address here is an IPv6 address reserved for documentation purposes, as defined by RFC3849. </description> -<ident cce="TODO" /> +<ident cce="27233-6" /> <oval id="network_ipv6_static_address" /> <ref nist="" /> </Rule> @@ -202,7 +202,7 @@ the following line (substituting your gateway IP as appropriate): Router addresses should be manually set and not accepted via any auto-configuration or router advertisement. </description> -<ident cce="TODO" /> +<ident cce="27234-4" /> <oval id="network_ipv6_default_gateway" /> <ref nist="" /> </Rule> diff --git a/RHEL6/input/system/permissions/mounting.xml b/RHEL6/input/system/permissions/mounting.xml index b5a2f22..636aee6 100644 --- a/RHEL6/input/system/permissions/mounting.xml +++ b/RHEL6/input/system/permissions/mounting.xml @@ -302,7 +302,7 @@ file to exploit this flaw. Assuming the attacker could place the malicious file (via a web upload for example) and assuming a user browses the same location using Nautilus, the malicious file would exploit the thumbnailer with the potential for malicious code execution. It is best to disable these thumbnailer applications unless they are explicitly required.</rationale> -<ident cce="TODO" /> +<ident cce="27224-5" /> <oval id="disable_gnome_thumbnailers" /> <ref nist="CM-7" /> </Rule> diff --git a/RHEL6/input/system/software/integrity.xml b/RHEL6/input/system/software/integrity.xml index e8a2a19..86fbc66 100644 --- a/RHEL6/input/system/software/integrity.xml +++ b/RHEL6/input/system/software/integrity.xml @@ -57,7 +57,7 @@ Next, the following command to return binaries to a normal, non-prelinked state The prelinking feature can interfere with the operation of AIDE, because it changes binaries. </rationale> -<ident cce="TODO" /> +<ident cce="27221-1" /> <ref nist="CM-6(d),CM-6(3),SC-28, SI-7" /> </Rule> @@ -97,7 +97,7 @@ To determine that periodic AIDE execution has been scheduled, run the following By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files. </rationale> -<ident cce="TODO" /> +<ident cce="27222-9" /> <ref nist="CM-6(d),CM-6(3),SC-28,SI-7" disa="374,416,1069,1263,1297,1589"/> </Rule> <!-- @@ -188,7 +188,7 @@ have file hashes different from what is expected by the RPM database. The hash on important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system.</rationale> -<ident cce="TODO" /> +<ident cce="27223-7" /> <oval id="rpm_verify_hashes" /> <ref nist="CM-6(d),CM-6(3),SI-7" disa="1496" /> </Rule> -- 1.7.1

1 0

[PATCH 5/6] Finished USGCB profile
by Shawn Wells 07 Feb '13

07 Feb '13

6 10

Getting the umask tests/checks to finally work
by Brian Millett 06 Feb '13

06 Feb '13

See attached patch for the following files scap-security-guide/RHEL6/input/system/accounts/session.xml scap-security-guide/RHEL6/input/checks/accounts_umask_etc_profile.xml scap-security-guide/RHEL6/input/checks/accounts_umask_bash_users.xml scap-security-guide/RHEL6/input/checks/accounts_umask_csh.xml scap-security-guide/RHEL6/input/checks/accounts_umask_login_defs.xml scap-security-guide/RHEL6/input/profiles/usgcb-rhel6-server.xml scap-security-guide/RHEL6/input/profiles/common.xml scap-security-guide/RHEL6/input/profiles/maritz-rhel6-server.xml scap-security-guide/RHEL6/input/profiles/test.xml scap-security-guide/RHEL6/input/profiles/stig-rhel6-server.xml result now are Ensure the Default Bash Umask is Set Correctly fail Ensure the Default C Shell Umask is Set Correctly fail Ensure the Default Umask is Set Correctly in /etc/profile fail Ensure the Default Umask is Set Correctly in login.defs pass Set Daemon Umask fail -- Brian Millett Enterprise Consulting Group "Shifts in paradigms (314) 205-9030 often cause nose bleeds." bpmATec-groupDOTcom Greg Glenn ------------------------------------------------------------------------- The information transmitted in this e-mail is intended only for the person or entity to which it is addressed, and may contain confidential and privileged information. Any review, retransmission, dissemination, reproduction, or other uses of this information by persons or entities other than the intended recipient is prohibited by law. If you believe that you have received this e-mail in error, please notify the sender and delete the message and any attachments from your computer. The recipient of this e-mail is solely responsible for checking for the presence of computer viruses or other malicious software code. Enterprise Consulting Group accepts no liability for any damage caused by any such code transmitted by or accompanying this e-mail or any attachment.

2 1

[PATCH] Renamed manpage to scap-security-guide
by Shawn Wells 06 Feb '13

06 Feb '13

3 2

[PATCH] [bugfix] Updates to UMASK settings
by Shawn Wells 06 Feb '13

06 Feb '13

Combined patch of changes that Brian and Jeff made to update the umask rules. Many thanks to both!

2 1

[PATCH] Patch to include JBoss content in the RPM
by Shawn Wells 06 Feb '13

06 Feb '13

2 1

adding "fix"es to the xccdf
by Brian Millett 05 Feb '13

05 Feb '13

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. -- Brian Millett "My brain feels like its been sucked out through my ear." -- [ Londo, "Born to the Purple"]

4 8

Getting the umask tests/checks to finally work
by Brian Millett 05 Feb '13

05 Feb '13

See attached patch for the following files scap-security-guide/RHEL6/input/system/accounts/session.xml scap-security-guide/RHEL6/input/checks/accounts_umask_etc_profile.xml scap-security-guide/RHEL6/input/checks/accounts_umask_bash_users.xml scap-security-guide/RHEL6/input/checks/accounts_umask_csh.xml scap-security-guide/RHEL6/input/checks/accounts_umask_login_defs.xml scap-security-guide/RHEL6/input/profiles/usgcb-rhel6-server.xml scap-security-guide/RHEL6/input/profiles/common.xml scap-security-guide/RHEL6/input/profiles/maritz-rhel6-server.xml scap-security-guide/RHEL6/input/profiles/test.xml scap-security-guide/RHEL6/input/profiles/stig-rhel6-server.xml result now are Ensure the Default Bash Umask is Set Correctly fail Ensure the Default C Shell Umask is Set Correctly fail Ensure the Default Umask is Set Correctly in /etc/profile fail Ensure the Default Umask is Set Correctly in login.defs pass Set Daemon Umask fail -- Brian Millett "If anyone asks, say it fell from the sky." -- [ Delenn to Sinclair (re: Vorlon files), "The Gathering"]

1 0

[PATCH] Renamed manpage to scap-security-guide
by Shawn Wells 05 Feb '13

05 Feb '13

1 0

[PATCH] [bugfix] Updated URN for bash fix scripts
by Shawn Wells 05 Feb '13

05 Feb '13

4 4

[PATCH] fix for typo'ed refine-values
by Jeffrey Blank 05 Feb '13

05 Feb '13

Thanks very much to Brian Millett for his testing. And perhaps at some point we'll consistently rename all Values to end in "_value" or begin with "var_" , but that's a foppish concern that can wait for now... Jeffrey Blank (1): fixed typo in refine-value for user umasks RHEL6/input/profiles/stig-rhel6-server.xml | 4 +--- RHEL6/input/profiles/test.xml | 2 +- 2 files changed, 2 insertions(+), 4 deletions(-)

1 1

[PATCH 6/6] Created SSG Manpage, shortened RPM "Description" text
by Shawn Wells 05 Feb '13

05 Feb '13

3 3

a small problem with some profiles umask_user_value is user_umask_value
by Brian Millett 05 Feb '13

05 Feb '13

Ensure the Default Bash Umask is Set Correctly *error* Ensure the Default C Shell Umask is Set Correctly *error* Ensure the Default Umask is Set Correctly in /etc/profile *error* Ensure the Default Umask is Set Correctly in login.defs *error* I was pulling out my hair (and I don't have much left anyways) why the umask_bashrc, umask_cshrc, etc were giving the results of "error" during an evaluation. Well, come to find out the variables are typoed, ( user_umask_value instead of umask_user_value) so cd scap-security-guide/RHEL6/input/profiles perl -pi -e 's/user_umask_value/umask_user_value/' $(grep -Rl user_umask_value *) fixes that problem. -- Brian Millett "Shifts in paradigms often cause nose bleeds." Greg Glenn

2 1

playing with the testcheck.py yields errors
by Brian Millett 05 Feb '13

05 Feb '13

Ok, so I've a rhel-6.3 system [root@localhost checks]# uname -r 2.6.32-279.19.1.el6.x86_64 [root@localhost checks]# rpm -qa | grep libxslt libxslt-1.1.26-2.el6_3.1.x86_64 I've been looking at the RHEL6/input/checks to see how it is done, and I wanted to test the checks. So following the documentation https://fedorahosted.org/scap-security-guide/wiki/newoval, I ran 'sshd_idle_timeout_value=30 ./testcheck.py sshd_idle_timeout.xml' and got the following error: [root@localhost checks]# sshd_idle_timeout_value=30 ./testcheck.py sshd_idle_timeout.xml external_variable with id : sshd_idle_timeout_value Evaluating with OVAL tempfile : /tmp/sshd_idle_timeoutUDK_FW.xml File '/tmp/sshd_idle_timeoutUDK_FW.xml' line 7: Element '{ http://oval.mitre.org/XMLSchema/oval-definitions-5}definition', attribute 'id': [facet 'pattern'] The value 'oval:oval:scap-security-guide.testing:def:108' is not accepted by the pattern 'oval:[A-Za-z0-9_\-\.]+:def:[1-9][0-9]*'. Looking into the code, I see that idtranslate.idtranslator already is adding the namespace to the id str_id = "%s:%s:%s:%d" % (namespace_to_prefix(tagname), self.content_id, tagname_to_abbrev(tagname), i) So the 'oval:oval:scap-security-guide.testing:def:108' being generated is redundant. the following patch fixes that. [root@localhost checks]# diff -wruN testcheck.py.orig ./testcheck.py --- testcheck.py.orig 2013-02-05 10:54:44.579854555 -0600 +++ ./testcheck.py 2013-02-05 10:54:57.889884072 -0600 @@ -102,7 +102,7 @@ if element.getchildren(): ovaltree.append(element) # re-map all the element ids from meaningful names to meaningless numbers - testtranslator = idtranslate.idtranslator("testids.ini", "oval:scap-security-guide.testing") + testtranslator = idtranslate.idtranslator("testids.ini", "scap-security-guide.testing") ovaltree = testtranslator.translate(ovaltree) (ovalfile, fname) = tempfile.mkstemp(prefix=defname,suffix=".xml") os.write(ovalfile, ET.tostring(ovaltree)) so now [root@localhost checks]# sshd_idle_timeout_value=30 ./testcheck.py sshd_idle_timeout.xml external_variable with id : sshd_idle_timeout_value Evaluating with OVAL tempfile : /tmp/sshd_idle_timeoutt_n33_.xml Definition oval:scap-security-guide.testing:def:111: false Definition oval:scap-security-guide.testing:def:109: false Definition oval:scap-security-guide.testing:def:108: false Evaluation done. -- Brian Millett "Shifts in paradigms often cause nose bleeds." Greg Glenn

2 2

[PATCH] fixed bug which unnecessarily prepended "oval:" to IDs
by Jeffrey Blank 05 Feb '13

05 Feb '13

Signed-off-by: Jeffrey Blank <blank(a)eclipse.ncsc.mil> --- RHEL6/input/checks/testcheck.py | 10 +--------- 1 files changed, 1 insertions(+), 9 deletions(-) diff --git a/RHEL6/input/checks/testcheck.py b/RHEL6/input/checks/testcheck.py index 3b410dd..66b8381 100755 --- a/RHEL6/input/checks/testcheck.py +++ b/RHEL6/input/checks/testcheck.py @@ -102,20 +102,12 @@ def main(): if element.getchildren(): ovaltree.append(element) # re-map all the element ids from meaningful names to meaningless numbers - testtranslator = idtranslate.idtranslator("testids.ini", "oval:scap-security-guide.testing") + testtranslator = idtranslate.idtranslator("testids.ini", "scap-security-guide.testing") ovaltree = testtranslator.translate(ovaltree) (ovalfile, fname) = tempfile.mkstemp(prefix=defname,suffix=".xml") os.write(ovalfile, ET.tostring(ovaltree)) os.close(ovalfile) print "Evaluating with OVAL tempfile : " + fname - # temporary workaround for fedora/redhat oscap version differences - # (distname, distversion, distcodename) = platform.linux_distribution(full_distribution_name=0) - # if distname == 'redhat': - # subprocess.call("oscap oval eval --result-file "+ fname + "-results " + fname, shell=True) - # else: - - # content requires OVAL 5.8 support, which is only supported by openscap 0.8 or later - # for RHEL 6, this implies installing openscap from source until RPM is released subprocess.call("oscap oval eval --results "+ fname + "-results " + fname, shell=True) # perhaps delete tempfile? definitions = ET.Element("definitions") -- 1.7.1

1 0

[PATCH] [bugfix] Updated .spec to reflect $RPM_BUILD_ROOT for chcon'ing manpage
by Shawn Wells 05 Feb '13

05 Feb '13

1 0

Inconsistent guidance and tests for disabling kernel modules (e.g. disable_protocol_dccp)
by Philip Shuman 04 Feb '13

04 Feb '13

A number of the kernel modules that need to be disabled have inconsistent guidance and tests. The guidance says to add a file in /etc/modprobe.d/ with the content: "install <module> /bin/true" However, the actual check in the scan tests for: "install <module> /bin/false" This is a list of the ones I found: $ cd scap-security-guide/RHEL6/dist/content $ grep -h install * | grep -E "rds|ticp|usb-storage|cramfs|freevsfs|jffs2|hfs|hfsplus|squashfs|udf|dccp|sctp" | grep -E "true|false" <ind:pattern operation="pattern match">^\s*install\s+hfs\s+/bin/false$</ind:pattern> <ind:pattern operation="pattern match">^\s*install\s+sctp\s+/bin/false$</ind:pattern> <ind:pattern operation="pattern match">^\s*install\s+rds\s+/bin/false$</ind:pattern> <ind:pattern operation="pattern match">^\s*install\s+jffs2\s+/bin/false$</ind:pattern> <ind:pattern operation="pattern match">^\s*install\s+cramfs\s+/bin/false$</ind:pattern> <ind:pattern operation="pattern match">^\s*install\s+dccp\s+/bin/false$</ind:pattern> <ind:pattern operation="pattern match">^\s*install\s+udf\s+/bin/false$</ind:pattern> <ind:pattern operation="pattern match">^\s*install\s+hfsplus\s+/bin/false$</ind:pattern> <ind:pattern operation="pattern match">^\s*install\s+squashfs\s+/bin/false$</ind:pattern> <ind:pattern operation="pattern match">^\s*install\s+usb-storage\s+/bin/false$</ind:pattern> <xhtml:pre xml:space="preserve">install usb-storage /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install cramfs /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install freevsfs /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install jffs2 /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install hfs /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install hfsplus /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install squashfs /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install udf /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install dccp /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install sctp /bin/true</xhtml:pre> <xhtml:pre xml:space="preserve">install rds /bin/true</xhtml:pre> Either /bin/true or /bin/false should work to disable the modules. Setting our files to /bin/false causes the scans to pass right now. Thanks, Philip

3 4

[PATCH] Replace xsl:attribute name="xmlns" with xsl:element
by Gary Gapinski 04 Feb '13

04 Feb '13

libxslt 1.1.27 now (correctly) prohibits xsl:attribute with name="xmlns". This change uses an explicit xsl:element with explicit namespace. This change should be removed (in favor of just identity transform) when input document has desired explicit namespace declaration. Gary Gapinski (1): Remove invalid attempt to use xsl:attribute to set xmlns. Replace with xsl:element with explicit namespace (namely, XCCDF 1.1). Note that this overrides any namespace set in input document. This should be removed when input document has explicit namespace declaration. RHEL6/transforms/shorthand2xccdf.xslt | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) -- 1.7.10.4

3 3

[PATCH] [bugfix] Inconsistent kernel checking
by Shawn Wells 04 Feb '13

04 Feb '13

3 2

patch to the xccdf-addfixes.xslt to get it to work
by Brian Millett 03 Feb '13

03 Feb '13

RHEL-6, libxslt-1.1.26 Ok, so now when I try to make with fixes, the following errors happen: Attribute nodes must be added before any child nodes to an element. runtime error: file transforms/xccdf-addfixes.xslt line 37 element copy The patch is [root@localhost transforms]# diff -wruN xccdf-addfixes.xslt.orig xccdf-addfixes.xslt --- xccdf-addfixes.xslt.orig 2013-02-01 14:40:40.580808238 -0600 +++ xccdf-addfixes.xslt 2013-02-01 14:35:31.607797643 -0600 @@ -11,7 +11,8 @@ <xsl:template match="xccdf:Rule"> <xsl:copy>  - <xsl:apply-templates select="@*|node()[not(self::xccdf:check)]"/> + <xsl:copy-of select="@*" /> + <xsl:apply-templates select="node()[not(self::xccdf:check)]"/> <xsl:variable name="rule_id" select="@id"/> <xsl:for-each select="$fixgroup/xccdf:fix"> And it works. Nice way to end the week! -- Brian Millett "Shifts in paradigms often cause nose bleeds." Greg Glenn

2 3

Initial setup
by Christopher Anderson 02 Feb '13

02 Feb '13

Walking through the initial setup was pretty quick an easy. I had no problems with the main wiki page and the usage guide page. I did find what appear to be small errors here and there, which I'll walk through. The page titled "Becoming an SCAP Security Guide Developer" (https://fedorahosted.org/scap-security-guide/wiki/becomeadeveloper) seems to have a few issues. First, under "Establishing your Accounts", there are three items all numbered 1. Second, under "Performing your first git clone", the command example shows acquiring the source via git and the ssh protocol. This should fail as the Fedora Account setup and request to join this group (and gaining ssh access) happens in step 6 of the next section. Consider changing the protocol to git: git clone git://git.fedorahosted.org/git/scap-security-guide.git Third, under "Submitting Proposed Changes" step 1, the command example asks the user to ensure their changes are valid by running "make; make validate" without specifying a directory. With a little experimentation it is easy to figure out that "make" will work from the top level directory in the source tree, but "make validate" must be run from the RHEL6 directory. I'm not sure if validate should be added to the top level Makefile, or if a rewording of the item to clarify would be better. With the exception of that page, I haven't found anything else. The pages are well thought out and I have yet to find even a spelling error in the wiki. Chris

2 1

[PATCH] Correct prototype namespace and schema location
by Gary Gapinski 02 Feb '13

02 Feb '13

RHEL6/input/guide.xml lacked a namespace declaration for <Benchmark> as well as citing a non-existent relative URI for schema location. Gary Gapinski (1): Correct xsi:schemalocation to cite XCCDF 1.1.4 schema. Place <Benchmark> element in XCCDF namespace. RHEL6/input/guide.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.10.4

2 2

Account lockout problems in RHEL6.3
by Philip Shuman 01 Feb '13

01 Feb '13

I'm in the process of implementing lockdowns for RHEL 6.3 based on the draft scap-security-guide as downloaded via git. The account lockout timeouts in /etc/pam.d/ have proven problematic for me. There are a couple issues I wanted to bring up. First, the current security guide checks for unlock_time=100000000 in the /etc/pam.d/ files; however, the max value that pam_faillock.so will accept is 604800. Anything larger than this value results in unlock_time defaulting back to 600 seconds. >From Linux-PAM-1.1.1/modules/pam_faillock/pam_faillock.c: ... #define MAX_TIME_INTERVAL 604800 /* 7 days */ ... else if (strncmp(argv[i], "unlock_time=", 12) == 0) { unsigned int temp; if (sscanf(argv[i]+12, "%u", &temp) != 1 || temp > MAX_TIME_INTERVAL) { pam_syslog(pamh, LOG_ERR, "Bad number supplied for unlock_time argument"); } else { opts->unlock_time = temp; } } Second, the STIG guidance asks for the authfail and authsucc lines to be added directly below pam_env.so. I've found that causes login prompt to never reach asking for a password, both on the console and when running X. I am using the example provided below additionally uses the preauth line before pam_unix.so and that is working as I would expect: https://access.redhat.com/knowledge/solutions/62949 auth required pam_env.so auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 auth sufficient pam_faillock.so authsucc audit deny=3 auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so (Tip: remove the "silent" from the preauth line for testing. faillock will tell you when it is kicking in to block a user. Remove for production so you don't leak valid usernames.) Third, when implemented, this long lock time does not persist a reboot. A locked user is able to login after rebooting the machine. Is this expected? I apprciate any help or working example system-auth or password-auth files. Best regards, Philip

2 5

libxslt-1.2.27 appears to be really brain dead
by Brian Millett 01 Feb '13

01 Feb '13

[bpm]$ rpm -qa | grep libxslt libxslt-1.1.27-2.fc18.x86_64 libxslt-devel-1.1.27-2.fc18.x86_64 libxslt-python-1.1.27-2.fc18.x86_64 Ok, so I've been working really hard to understand why the xsltproc commands just were not working as advertised in the make file for the latest (20130201) git clone of scap-security-guide. I've got a fedora 18 system with the libxslt1.1.27-2 packages. Well, the build just breaks. The following commands work, they just do not produce the desired output xsltproc -stringparam notes "../input/auxiliary/transition_notes.xml" -o output/table-rhel5-stig-manual-withnotes.html \ transforms/xccdf2table-stig.xslt \ references/disa-stig-rhel5-v1r0.6-xccdf-manual.xml xsltproc -stringparam profile "stig-rhel6-server" -stringparam testinfo "y" -o output/table-stig-rhel6-server-shorttitles.html \ transforms/xccdf2table-profileccirefs.xslt \ output/unlinked-rhel6-xccdf.xml xsltproc -stringparam alttitles "../input/auxiliary/alt-titles-stig.xml" -o output/unlinked-stig-rhel6-xccdf.xml \ transforms/xccdf-alt-titles.xslt \ output/unlinked-rhel6-xccdf.xml xsltproc -stringparam profile "stig-rhel6-server" -o output/table-stig-rhel6-server.html \ transforms/xccdf2table-profileccirefs.xslt \ output/unlinked-stig-rhel6-xccdf.xml xsltproc --html -o output/table-stig-rhel6-server.html transforms/table-add-vulnids.xslt output/table-stig-rhel6-server.html xsltproc -stringparam profile "stig-rhel6-server" -stringparam format "flat" -o output/table-stig-rhel6-server-flat.html \ transforms/xccdf2table-profileccirefs.xslt \ output/unlinked-stig-rhel6-xccdf.xml So I did a git clone on a new RHEL-6 box which has libxslt-1.1.26 and guess what?? IT WORKS. So, this is beyond my pay grade. But at least I know that for this, I'm not insane. I had my doughts after spending 2 days staring at the xccdf2table-profileccirefs.xslt and xccdf-addfixes.xslt wondering why they were not working. So, I'll stay on RHEL-6 for now to understand the build process better. Thanks. -- Brian Millett "Shifts in paradigms often cause nose bleeds." Greg Glenn

1 0

[PATCH] [bugfix] var_accounts_passwords_pam_faillock_unlock_time value exceeded MAX_TIME_INTERVAL
by Shawn Wells 01 Feb '13

01 Feb '13

Thanks to Philip S. for reporting this!

1 0

patch to the RHEL6/Makefile
by Brian Millett 01 Feb '13

01 Feb '13

When running make, I get the following error Duplicate ID, which will not be added: state_mode_0000 Duplicate ID, which will not be added: state_uid_0 Duplicate ID, which will not be added: state_gid_0 xmllint --format --output output/unlinked-rhel6-oval.xml output/unlinked-rhel6-oval.xml transforms/cpe_generate.py output/unlinked-rhel6-oval.xml input/checks/platform/rhel6-cpe-dictionary.xml ssg transforms/relabelids.py unlinked-rhel6-xccdf.xml ssg transforms/relabelids.py unlinked-ocilrefs-rhel6-xccdf.xml ssg mkdir -p dist/guide dist/content dist/policytables cp output/rhel6-guide.html dist/guide cp output/ssg-rhel6-xccdf.xml dist/content cp output/ssg-rhel6-oval.xml dist/content cp: cannot stat ‘output/ssg-rhel6-oval.xml’: No such file or directory patch to get it to make correctly [bpm]$ diff -wruN Makefile.orig Makefile --- Makefile.orig 2013-01-30 13:47:55.554661112 -0600 +++ Makefile 2013-01-30 13:48:07.914662435 -0600 @@ -109,6 +109,7 @@ $(TRANS)/cpe_generate.py $(OUT)/unlinked-rhel6-oval.xml $(IN)/checks/platform/rhel6-cpe-dictionary.xml $(ID) $(TRANS)/relabelids.py unlinked-rhel6-xccdf.xml $(ID) $(TRANS)/relabelids.py unlinked-ocilrefs-rhel6-xccdf.xml $(ID) + $(TRANS)/relabelids.py unlinked-rhel6-oval.xml $(ID) # not ready until oscap resolve behavior resolved content-stig: shorthand2xccdf guide checks -- Brian Millett "I'd like to live just long enough to be there when they cut off your head and stick it on a pike as a warning to the next ten generations that some favors some with too high a price. I want to look up into your lifeless eyes and wave like this. Can you and your associates arrange that for me, Mr. Morden?" -- [ Vir (re: What do you want?), "In the Shadow of Z'Ha'Dum"]

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide February 2013