From pvrabec at redhat.com Tue Nov 1 15:08:00 2011 From: pvrabec at redhat.com (Peter Vrabec) Date: Tue, 1 Nov 2011 16:08:00 +0100 Subject: [Open-scap] Timeout checks In-Reply-To: <4EAEAF64.8060709@gtri.gatech.edu> References: <4EAEAF64.8060709@gtri.gatech.edu> Message-ID: <201111011608.01050.pvrabec@redhat.com> thanks Josh. On Monday, October 31, 2011 03:23:32 PM Josh Kayse wrote: > We're running the RHEL6 open scap benchmark and we keep failing > rule-1070 and rule-1071. These rules check for TMOUT and autologout > being set to a specific value. I propose that the check ensures that > the configured value is less than or equal rather than equals. A patch > for this change is attached. > > Thanks, > Josh From vbatts at hashbangbash.com Wed Nov 2 23:43:02 2011 From: vbatts at hashbangbash.com (Vincent Batts) Date: Wed, 2 Nov 2011 19:43:02 -0400 Subject: [Open-scap] Editing XCCDF/OVAL In-Reply-To: <201110312247.59732.pvrabec@redhat.com> References: <20111031160253.GA6145@siphos.be> <6A1F6FD3001BDD40A94503E2223CEBD501B202@IMCMBX03.MITRE.ORG> <201110312247.59732.pvrabec@redhat.com> Message-ID: > https://fedorahosted.org/scap-security-guide/ > > It's a combination of: Makefiles, XSLT, XML, SCC and GIT. > Please don't get scared now. It might look like a mess but it's not. ;) > Personally, I like it more then GUI approach. > > * Version control system comes very handy in process of content development. > (Undo, Redo, History, ...) > * SCC gets you thru OVAL disadventages. > * XML for XCCDF is doable. You can also use XML editor. > * XSLT for html. > * Finally, Makefile to "build" it a all. > > Please take a look and I'll be glad if you share your opinion with us. > > Peter. Nice! Thanks Peter. This is part of what I had in mind, when I sent you an email shortly ago. I look forward to this approach more than the GI approach as well. Take care, vb http://hashbangbash.com/ From blank at eclipse.ncsc.mil Tue Nov 15 21:42:59 2011 From: blank at eclipse.ncsc.mil (Jeffrey Blank) Date: Tue, 15 Nov 2011 16:42:59 -0500 Subject: [Open-scap] XCCDF validation issue Message-ID: <4EC2DCE3.3040002@eclipse.ncsc.mil> Hi Peter (and list), I'm having 2 unexpected issues validating some XCCDF from scap-security-guide. (There were some other validation issues, but I assume those are problems with my content!) After the "make all", my "make validate" tries to run: $ oscap xccdf validate-xml output/rhel6-xccdf-scap-security-guide.xml And I get 2 issues that I cannot explain. (I'm using the openscap RPM provided with RHEL 6.) 1) There seems to be an issue with handling the tag inside a : 1 1871 In file 'output/rhel6-xccdf-scap-security-guide.xml' on line 4247: Element '{http://checklists.nist.gov/xccdf/1.1}reference': This element is not expected. Expected is one of ( {http://checklists.nist.gov/xccdf/1.1}check, {http://checklists.nist.gov/xccdf/1.1}signature ). 2) There seems to be a problem with handling XHTML tags (such as ) inside a : 1 1871 In file 'output/rhel6-xccdf-scap-security-guide.xml' on line 5448: Element '{http://www.w3.org/1999/xhtml}code': This element is not expected. Expected is ( {http://checklists.nist.gov/xccdf/1.1}sub ). (I assumed this was allowed, but if not, I can change the XCCDF.) Or if I should be using a later version of openscap (built from source), let me know... Thanks! Jeff ___________________________ Jeffrey Blank 410-854-8675 From mpreisle at redhat.com Wed Nov 16 16:01:59 2011 From: mpreisle at redhat.com (Martin Preisler) Date: Wed, 16 Nov 2011 11:01:59 -0500 (EST) Subject: [Open-scap] XCCDF validation issue In-Reply-To: <4EC2DCE3.3040002@eclipse.ncsc.mil> Message-ID: <3abc77e1-ff4e-4eed-a9f4-3a4d2559e756@zmail15.collab.prod.int.phx2.redhat.com> Hi! > 1) > There seems to be an issue with handling the <reference> tag inside a > <Rule>: > > 1 1871 In file 'output/rhel6-xccdf-scap-security-guide.xml' on line > 4247: Element '{http://checklists.nist.gov/xccdf/1.1}reference': This > element is not expected. Expected is one of ( > {http://checklists.nist.gov/xccdf/1.1}check, > {http://checklists.nist.gov/xccdf/1.1}signature ). I find this really strange. The specification clearly mentions that reference is a valid sub element of Item, Rule inherits the Item so it should be allowed there as well. This may be caused by the way the schema enforces this. There are fairly complex inheritance trees, each extension appends elements and ordering matters in XSD. You can get rid of it by reordering the elements, making reference appear before any elements specified in types inheriting from itemType. In this case putting <reference> before <rationale>. Example: <Rule id="partition_for_tmp"> <title>... ... CM-6 ... ... the rest of the tags ... < reference used to be here > The XSD schema should be more relaxed towards this IMO and I am convinced this would work just fine with openscap if you skip validation. Regardless, I think this should be patched so the generated xccdf have reference elements where they should be. > > > 2) > There seems to be a problem with handling XHTML tags (such as > ) inside a : > > 1 1871 In file 'output/rhel6-xccdf-scap-security-guide.xml' on line > 5448: Element '{http://www.w3.org/1999/xhtml}code': This element is > not > expected. Expected is ( {http://checklists.nist.gov/xccdf/1.1}sub ). > > (I assumed this was allowed, but if not, I can change the XCCDF.) "xhtml" namespace elements are only allowed inside some elements, for example description (and other htmlTextWithSubType types). According to the XSD, title shouldn't contain xhtml tags (and other textWithSubType types). What I find strange is that the specification PDF doesn't mention this clearly (or maybe I missed it). > > > Or if I should be using a later version of openscap (built from > source), > let me know... Both of these issues are reproducible outside of openscap with official XSD schemas and XML validating tools so getting newer openscap shouldn't make any difference (unless the target XSD schema changes of course). > > > Thanks! > Jeff HTH :-) -- Martin Preisler From blank at eclipse.ncsc.mil Wed Nov 16 16:22:16 2011 From: blank at eclipse.ncsc.mil (Jeffrey Blank) Date: Wed, 16 Nov 2011 11:22:16 -0500 Subject: [Open-scap] XCCDF validation issue In-Reply-To: <3abc77e1-ff4e-4eed-a9f4-3a4d2559e756@zmail15.collab.prod.int.phx2.redhat.com> References: <3abc77e1-ff4e-4eed-a9f4-3a4d2559e756@zmail15.collab.prod.int.phx2.redhat.com> Message-ID: <4EC3E338.3080408@eclipse.ncsc.mil> > You can get rid of it by reordering the elements, making reference > appear before any elements specified in types inheriting from > itemType. In this case putting<reference> before<rationale>. I'll try to follow this as a convention, and maybe a future version will allow more flexible ordering. I'd also considered testing reordering, but figured putting the question forward might be helpful too. > "xhtml" namespace elements are only allowed inside some elements, for > example description (and other htmlTextWithSubType types). According > to the XSD, title shouldn't contain xhtml tags (and other > textWithSubType types). What I find strange is that the specification > PDF doesn't mention this clearly (or maybe I missed it). Ah -- I had looked only at the specification PDF, and didn't study the XSD carefully. (Hoping someone else might do so for me :) ) It's no big deal to lose some prettiness of formatting inside a <title>. Thanks for letting everyone know where exactly to look in the XSD for future reference. > HTH :-) Indeed! From joe at nall.com Thu Nov 17 18:17:52 2011 From: joe at nall.com (Joe Nall) Date: Thu, 17 Nov 2011 10:17:52 -0800 Subject: [Open-scap] RHEL6 oval error in trunk Message-ID: <01F55E62-D3B8-4A56-9EBE-EE6A24AA9119@nall.com> Using the current openscap in RHEL6 and the current git oval and xccdf, I get the following error: > ./scap-rhel6-oval.xml' on line 3195: Element '{http://oval.mitre.org/XMLSchema/oval-definitions-5}filter': This element is not expected. > oscap was unable to validate the XML document you provided. > Please ensure that the XML document is valid and well-formed, and try again. is this just a mismatch between the parser and the xml versions? > FAIL: test_mitre.sh > ========================================== > 1 of 1 test failed > Please report to open-scap-list at redhat.com > ========================================== > make[3]: *** [check-TESTS] Error 1 > make[3]: Leaving directory `/home/joe/openscap/tests/mitre' > make[2]: *** [check-am] Error 2 > make[2]: Leaving directory `/home/joe/openscap/tests/mitre' > make[1]: *** [check-recursive] Error 1 > make[1]: Leaving directory `/home/joe/openscap/tests' > make: *** [check-recursive] Error 1 A make check on RHEL 6 fails for the current git checkout. joe From slukasik at redhat.com Sun Nov 27 19:10:24 2011 From: slukasik at redhat.com (Simon Lukasik) Date: Sun, 27 Nov 2011 20:10:24 +0100 Subject: [Open-scap] [PATCH] Minor documentation fix Message-ID: <4ED28B20.5090205@redhat.com> Hello, Earlier this year, the oscap command-line options --report-file --result-file has been renamed. Please consider the following patch which fixes their remaining occurrences. Furthermore, I believe that http://www.open-scap.org/page/Tutorial page needs to be amended as well. Thank You, -- Simon Lukasik -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Fix-documentation-of-command-line-options.patch URL: <http://listman.redhat.com/archives/open-scap-list/attachments/20111127/b8894ea6/attachment.ksh> From pvrabec at redhat.com Tue Nov 29 15:39:50 2011 From: pvrabec at redhat.com (Peter Vrabec) Date: Tue, 29 Nov 2011 16:39:50 +0100 Subject: [Open-scap] [PATCH] Minor documentation fix In-Reply-To: <4ED28B20.5090205@redhat.com> References: <4ED28B20.5090205@redhat.com> Message-ID: <1381810.78OKADe9RA@wrabco.brq.redhat.com> thnx. Simon. On Sunday, November 27, 2011 08:10:24 PM Simon Lukasik wrote: > Hello, > > Earlier this year, the oscap command-line options > > --report-file > --result-file > > has been renamed. Please consider the following patch which fixes > their remaining occurrences. Furthermore, I believe that > > http://www.open-scap.org/page/Tutorial > > page needs to be amended as well. > > Thank You,