Yes -- good catch again. I realized this, and I believe I've already
fixed it. (Let me know if not.)
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.)
It seems to me we have different understanding how profiles in XCCDF
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
how to call it :) )
<select idref="partition_for_tmp" selected="true"/>
If you evaluate "desktop" profile both checks "partition_for_tmp"
"no_unpackaged_sgid_files" will be executed. Why?
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. :)
> 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 ...
> 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. :)
>> scap-security-guide mailing list
> scap-security-guide mailing list