[Xccdf-dev] xccdf:rule-result element properties

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Xccdf-dev] xccdf:rule-result element properties

Simon Lukasik
Hello SCAP People,

This e-mail is concern with Table 25 from NISTIR-7275r4.pdf. The said
table requires that each rule-result contains:

   (1-n instances of check) XOR (1 instance of complex-check)


The xccdf:Rule bears the same requirement. Hence, it should be easy for
any tool to simply copy the check (or complex-check) elements from the
given Rule to rule-result. However, I am puzzled if such copy is of
value to anybody.

Here, let me remind you that the process of selecting xccdf:check for
assessment is not straight forward, but it is known as Check Processing
Algorithm.

I came to the conclusion that it would be beneficial for TestResult
consumer, if the rule-result contained only those check elements which
were actually evaluated. Not all of them.

However, I've stumbled at the cardinality requirement stated above. If
there is no check element applicable or the @system attribute is not
supported) I would suggest to not include any <check> within
rule-result. The specification, however, requires at least one <check>
to be present.


Would it be possible in future XCCDF specification to rather require
only those <check> elements which were executed? And hence allow for 0
checks if the rule was notselected/notchecked/notapplicable ?

Thanks!

--
Simon Lukasik
Security Technologies
Red Hat, Inc.
_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] xccdf:rule-result element properties

joval
Hi Simon,

I'd add that the table you cite conflicts with the schema itself, which specifies the minOccurs="0" attribute for the check/complex check choice.  I think this is a "documentation defect" in the specification.

Regards,
--David Solin

On 2/18/2014 7:53 AM, Simon Lukasik wrote:
Hello SCAP People,

This e-mail is concern with Table 25 from NISTIR-7275r4.pdf. The said 
table requires that each rule-result contains:

   (1-n instances of check) XOR (1 instance of complex-check)


The xccdf:Rule bears the same requirement. Hence, it should be easy for 
any tool to simply copy the check (or complex-check) elements from the 
given Rule to rule-result. However, I am puzzled if such copy is of 
value to anybody.

Here, let me remind you that the process of selecting xccdf:check for 
assessment is not straight forward, but it is known as Check Processing 
Algorithm.

I came to the conclusion that it would be beneficial for TestResult 
consumer, if the rule-result contained only those check elements which 
were actually evaluated. Not all of them.

However, I've stumbled at the cardinality requirement stated above. If 
there is no check element applicable or the @system attribute is not 
supported) I would suggest to not include any <check> within 
rule-result. The specification, however, requires at least one <check> 
to be present.


Would it be possible in future XCCDF specification to rather require 
only those <check> elements which were executed? And hence allow for 0 
checks if the rule was notselected/notchecked/notapplicable ?

Thanks!



--

jOVAL.org: SCAP Simplified.
Learn More | Features | Download


_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] xccdf:rule-result element properties

Simon Lukasik
On 02/18/2014 04:01 PM, David Solin wrote:
> Hi Simon,
>
> I'd add that the table you cite conflicts with the schema itself, which
> specifies the minOccurs="0" attribute for the check/complex check
> choice.  I think this is a "documentation defect" in the specification.
>

Thanks David, that is what I had been thinking before. However the
schematron validation file for result-data-stream requires the following:

     Every <xccdf:rule-result> must have a <xccdf:check>/
     <xccdf:check-content-ref> that has attributes @href and @name

The XCCDF 1.2 schema or XCCDF 1.2 schematron does not include such
requirement. Hence, we have this little inconsistency. It would be great
to have this consistent and cleared out.

Best regards,

--
Simon Lukasik
Security Technologies
Red Hat, Inc.
_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: [Xccdf-dev] xccdf:rule-result element properties

Simon Lukasik
On 02/19/2014 04:50 PM, Simon Lukasik wrote:

> On 02/18/2014 04:01 PM, David Solin wrote:
>> Hi Simon,
>>
>> I'd add that the table you cite conflicts with the schema itself, which
>> specifies the minOccurs="0" attribute for the check/complex check
>> choice.  I think this is a "documentation defect" in the specification.
>>
>
> Thanks David, that is what I had been thinking before. However the
> schematron validation file for result-data-stream requires the following:
>
>       Every <xccdf:rule-result> must have a <xccdf:check>/
>       <xccdf:check-content-ref> that has attributes @href and @name
>
> The XCCDF 1.2 schema or XCCDF 1.2 schematron does not include such
> requirement. Hence, we have this little inconsistency. It would be great
> to have this consistent and cleared out.
>

More info & another problem.

The said schematron requirement from result-data-stream-1.2.1.sch reads:

<sch:assert
id="scap-result-general-xccdf-rule-result-check-content-ref-exists"
test="if( xccdf:result ne 'notapplicable' ) then
exists(xccdf:check/xccdf:check-content-ref[exists(@href) and
exists(@name)]) else true()">260-1</sch:assert>

Such requirement will fail when you use xccdf:complex-check. I believe
that schematron should be amended at least to allow complex-checks.

--
Simon Lukasik
Security Technologies
Red Hat, Inc.
_______________________________________________
XCCDF-dev mailing list
[hidden email]
To unsubscribe, send an email message to [hidden email].