[Open-scap] USGCB Content Issue on RHEL 5.8 and 6.2

Martin Preisler mpreisle at redhat.com
Fri Jul 20 08:22:47 UTC 2012


Hi,

----- Original Message -----
> From: "Francisco Slavin" <fslavin at tresys.com>
> To: "Martin Preisler" <mpreisle at redhat.com>
> Cc: open-scap-list at redhat.com
> Sent: Wednesday, July 18, 2012 7:48:23 PM
> Subject: RE: [Open-scap] USGCB Content Issue on RHEL 5.8 and 6.2
> 
> Hi Martin,
> Thanks for the follow-up on this; I saw the quick resolution to Bug
> 141, and I'm curious if there's been any progress on 142.  It would

I am currently busy implementing datastreams but will eventually get to #142. In the meantime I suggest to fix the content. The bug sure is there but if you can reproduce it your content is flawed (as described in the ticket). Feel free to email me off list if you are unsure about the details.

> be excellent to see these fixes backported in to maintenance
> versions as you mentioned; does this still seem likely?  I am
> supporting the CLIP (Certifiable Linux Integration Platform) effort
> which integrates aqueduct and scap-security-guide content for RHEL
> 6.2, and we would like to determine whether this effort will involve
> using a base maintained version of OpenSCAP or carrying a patched
> version.

We plan to backport fixes to RHEL6 and RHEL5 so it is very likely.

> 
> Thank you
> 
>  - Francisco Slavin
> 
> -----Original Message-----
> From: Martin Preisler [mailto:mpreisle at redhat.com]
> Sent: Friday, June 15, 2012 8:11 AM
> To: Francisco Slavin
> Cc: Boyd.fletcher at us.army.mil; open-scap-list at redhat.com
> Subject: Re: [Open-scap] USGCB Content Issue on RHEL 5.8 and 6.2
> 
> Hi,
> 
> > For oscap, I manually edited the XCCDF document to switch all of
> > the
> > selected="false" attributes of the <Rule> elements to
> > selected="true" to avoid messing with the profiles and assure
> > everything would be run by default.
> >
> 
> The root of the problem is that XCCDF Values used by the checks don't
> have any default value, they have to be refined in the profiles.
> Since you are running the default profile, there are no refines. The
> value ends up being NULL and being exported as so twice and it
> triggers a bug in openscap.
> 
> > In both cases, it seems that something from the OpenSCAP library is
> > throwing up a segmentation fault.
> > 
> > I used SecState to do some more selection and deselection and
> > discovered something particularly strange.
> > It seems that most of the content works, but some of the content
> > cannot be run concurrently.
> > For instance, a seg fault will happen if you run rule 2.3.7.1.a and
> > rule 2.3.7.2.a concurrently.  However, if you deselect either one
> > of
> > these rules then you can have a whole set of other content selected
> > and there will not be a seg fault.
> > There is one other sensitive area of this content that behaves
> > similarly.  I can confirm that this set behaves the same:
> > 3.4.2.3.a
> > 3.4.2.3.b
> > 3.4.2.3.c
> > 3.4.2.3.d
> > 
> 
> Exactly the same problem.
> 
> > I am wondering if anybody else in the community or dev team has run
> > into a similar issue with this content.  Is there a known issue for
> > this that a newer version of OpenSCAP would resolve?
> 
> This manifests itself even in openscap from git master, I don't
> recall this ever being triggered. I am working on fixing this issue
> and hope to have that fix backported into maintenance versions. The
> segfault was already addressed a minute ago in
> https://fedorahosted.org/openscap/ticket/141 but the real issue is a
> bit deeper and outlined in
> https://fedorahosted.org/openscap/ticket/142
> 
> Thanks a lot for reporting this issue!
> 
> --
> Martin Preisler
> 




More information about the Open-scap-list mailing list