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