OVAL checks that work correctly

Peter Vrabec pvrabec at redhat.com
Thu Dec 22 11:10:18 UTC 2011


On Wednesday, December 21, 2011 04:33:20 PM Jeffrey Blank wrote:
> Yes -- good catch again.  I realized this, and I believe I've already
> fixed it.  (Let me know if not.)
It works. :)

> In transforms/xccdf2oscapvalid.xslt, I added a transform to add
> attribute selected="false" to all rules.  (I should probably move this
> to shorthand2xccdf.xslt, since it's not related to oscap's validation
> requirements.  Or perhaps to xccdf-addprofiles.xslt, since it's related
> to making Profiles work.)
> 
> Originally, I had tried adding "selected=false" to the toplevel Groups,
> but oscap did not make the Group/Rule children inherit this when it
> builds its internal "policy" for each profile.
> 
> (Page 18 of the XCCDF 1.1.4 spec, and
> Page 20 of the XCCDF 1.2 spec,
> which describe the behavior of "selected,"
> suggests this should work. But no big deal.  It's simpler to just set
> the rules directly anyway.)
Thanks, I have filed a bug report[1]. We have to fix this.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=769813


> 
> Thanks,
> Jeff

Peter.

> 
> > It seems to me we have different understanding how profiles in XCCDF
> > work. As far as I know (need to check spec. one more time) profiles
> > inherit rules selection from a "default" profile. Default profile == no
> > profile. (I don't know how to call it :) )
> > 
> > example.
> > <profile id="desktop">
> > 
> >     <select idref="partition_for_tmp" selected="true"/>
> > 
> > </profile>
> > <group>
> > 
> >   <rule id="no_unpackaged_sgid_files">
> >   
> >    </rule>
> > 
> > </group>
> > 
> > 
> > If you evaluate "desktop" profile both checks "partition_for_tmp" and
> > "no_unpackaged_sgid_files" will be executed. Why?
> > 1. inheritance
> > 2. all groups and rules have @selected attribute set to "true" by
> > default.
> > 
> > The results is that the profiles in your content does not work in oscap
> > tool correctly. Whenever you want to evaluate certain profile all the
> > rules from the content are executed. I doubt that's an intention. :)
> > 
> > 
> > Peter.
> > 
> >> 3) Do the real research about the RHEL 6 platform and add additional
> >> checks.
> >> 
> >> I will consider it a major milestone when we can execute the desktop
> >> or
> >> server profile with oscap.  (I plan to send messages to the list when
> >> we
> >> can do so.)
> >> 
> >> At that time, we'd want reports of problems.  Until then, we're trying
> >> to fix up as much as possible.
> >> 
> >> Also note:
> >> The testcheck.py script can't handle external variables right now, so
> >> I
> >> was considering updating it to:
> >> replace external vars with local vars,
> >> using values from (the shell's) environment variables.
> >> 
> >> Or perhaps we should try using oscap directly for unit tests of the
> >> OVAL
> >> checks, since we have valid XCCDF and OVAL to use now ...
> >> 
> >> 
> >> Thanks,
> >> Jeff
> >> 
> >> On 12/14/2011 08:59 AM, Peter Vrabec wrote:
> >>> Hi all,
> >>> 
> >>> I'd like to test the content but I don't know which OVAL tests are
> >>> considered to be OK. I mean they are "implemented" correctly.
> >>> 
> >>> My assumption is that tests from one of the XCCDF profiles should be
> >>> OK. Could you please clarify it. The reason I'm asking is that I
> >>> don't want to report you issues that you are already aware of. :)
> >>> 
> >>> Peter.
> >>> 
> >>> _______________________________________________
> >>> scap-security-guide mailing list
> >>> scap-security-guide at lists.fedorahosted.org
> >>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
> >> 
> >> _______________________________________________
> >> scap-security-guide mailing list
> >> scap-security-guide at lists.fedorahosted.org
> >> https://fedorahosted.org/mailman/listinfo/scap-security-guide
> 
> \


More information about the scap-security-guide mailing list