New element in VariableType of oval-variables-schema.xsd?

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

New element in VariableType of oval-variables-schema.xsd?

Panos Kampanakis (pkampana)
New element in VariableType of oval-variables-schema.xsd?

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something the user_friendly_description could say This is the filename of the file that contains x.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the comment in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the users benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

PGP.sig (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

joval
Hi Panos,

The purpose of the variables schema is to transmit external variable values to an OVAL interpreter, not to collect those values.  I assume that collecting those values is the job of some other tool, that need not be restricted by the schema, and which is potentially outside the scope of the OVAL standards.

Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one.  Or do you really think we need to expand the scope of the external variables document to include collection of the values?

Regards,
--David Solin

On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:
New element in VariableType of oval-variables-schema.xsd?

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something the user_friendly_description could say This is the filename of the file that contains x.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the comment in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the users benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write 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: New element in VariableType of oval-variables-schema.xsd?

Panos Kampanakis (pkampana)
New element in VariableType of oval-variables-schema.xsd?

Thanks David.

 

So, what is the tool that today collects external variables? I don’t know of any.

 

What I was thinking was that an evaluator that checks for an oval def with an external variable certainly takes the external variable as its input. Now, if that external variable needs to be adjusted for my system I need to go in the external variable file and edit the values that I need to edit. And it is more likely that the external variable file will be provided as a template with the def, I don’t expect the user that will use the evaluator tool to write the external variable file from scratch.

 

So, if my thinking is right and the external variable file goes with the oval def, then wouldn’t it make sense to have a field that a GUI could use in order to take the external variable template file for the oval def and present to the user the fields he needs to populate and what they are?

 

> Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one. 

Doesn’t the OVAL author write the oval code and the external variables he will use, that need to be adjusted on a per-system basis? Having the oval author provide one more format to define what the external variables needed are, I think, is more complicated that what I am proposing.

 

BTW, has a format/schema or something been considered before for the external variable collection? Or has it always been assumed that external variables are provided somehow?

 

Rgs,

Panos

 

 

 

From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Tuesday, August 07, 2012 12:29 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Panos Kampanakis (pkampana)
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

Hi Panos,

The purpose of the variables schema is to transmit external variable values to an OVAL interpreter, not to collect those values.  I assume that collecting those values is the job of some other tool, that need not be restricted by the schema, and which is potentially outside the scope of the OVAL standards.

Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one.  Or do you really think we need to expand the scope of the external variables document to include collection of the values?

Regards,
--David Solin

On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something the user_friendly_description could say “This is the filename of the file that contains x”.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the “comment” in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the user’s benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

PGP.sig (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

Luis Nunez
<base href="x-msg://1367/">Can we use OCIL to generate external variables for OVAL?  If can define the right questions to ask maybe OCIL could be the UI?

-ln

On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:

Thanks David.
 
So, what is the tool that today collects external variables? I don’t know of any.
 
What I was thinking was that an evaluator that checks for an oval def with an external variable certainly takes the external variable as its input. Now, if that external variable needs to be adjusted for my system I need to go in the external variable file and edit the values that I need to edit. And it is more likely that the external variable file will be provided as a template with the def, I don’t expect the user that will use the evaluator tool to write the external variable file from scratch.
 
So, if my thinking is right and the external variable file goes with the oval def, then wouldn’t it make sense to have a field that a GUI could use in order to take the external variable template file for the oval def and present to the user the fields he needs to populate and what they are?
 
> Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one. 
Doesn’t the OVAL author write the oval code and the external variables he will use, that need to be adjusted on a per-system basis? Having the oval author provide one more format to define what the external variables needed are, I think, is more complicated that what I am proposing.
 
BTW, has a format/schema or something been considered before for the external variable collection? Or has it always been assumed that external variables are provided somehow?
 
Rgs,
Panos
 
 
 
From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Tuesday, August 07, 2012 12:29 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Panos Kampanakis (pkampana)
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?
 

Hi Panos,

The purpose of the variables schema is to transmit external variable values to an OVAL interpreter, not to collect those values.  I assume that collecting those values is the job of some other tool, that need not be restricted by the schema, and which is potentially outside the scope of the OVAL standards.

Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one.  Or do you really think we need to expand the scope of the external variables document to include collection of the values?

Regards,
--David Solin

On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something theuser_friendly_description could say “This is the filename of the file that contains x”.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the“comment” in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the user’s benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

joval
I only have experience with two products that make use of the OVAL variables file: ovaldi and jOVAL.  Both take the external variables file as input for processing OVAL definitions.  What makes an external variable "external" is that its value is not defined in the OVAL definitions document.  The specification doesn't say anything about querying users for values.  That kind of function is, in my mind, external to OVAL.

Now, Luis makes a great point -- there is a standard in the SCAP specification (OCIL) that is designed to be used to ask people questions.  Furthermore, XCCDF has the capability to define both variable imports and exports.  It would be fairly easy to import an answer from an OCIL question result.

Currently, XPERT only supports imports from SCE scripts, but it can produce OVAL variables file format documents encapsulating exports from the XCCDF document to the OVAL system.  It also handles importing OCIL results files.  So, with just a bit of extra work to support OCIL imports, you could do exactly what Luis proposes.

Regards,
--David Solin

On 8/7/2012 8:44 AM, Luis Nunez wrote:
<base href="x-msg://1367/">Can we use OCIL to generate external variables for OVAL?  If can define the right questions to ask maybe OCIL could be the UI?

-ln

On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:

Thanks David.
 
So, what is the tool that today collects external variables? I don’t know of any.
 
What I was thinking was that an evaluator that checks for an oval def with an external variable certainly takes the external variable as its input. Now, if that external variable needs to be adjusted for my system I need to go in the external variable file and edit the values that I need to edit. And it is more likely that the external variable file will be provided as a template with the def, I don’t expect the user that will use the evaluator tool to write the external variable file from scratch.
 
So, if my thinking is right and the external variable file goes with the oval def, then wouldn’t it make sense to have a field that a GUI could use in order to take the external variable template file for the oval def and present to the user the fields he needs to populate and what they are?
 
> Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one. 
Doesn’t the OVAL author write the oval code and the external variables he will use, that need to be adjusted on a per-system basis? Having the oval author provide one more format to define what the external variables needed are, I think, is more complicated that what I am proposing.
 
BTW, has a format/schema or something been considered before for the external variable collection? Or has it always been assumed that external variables are provided somehow?
 
Rgs,
Panos
 
 
 
From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, August 07, 2012 12:29 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Panos Kampanakis (pkampana)
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?
 

Hi Panos,

The purpose of the variables schema is to transmit external variable values to an OVAL interpreter, not to collect those values.  I assume that collecting those values is the job of some other tool, that need not be restricted by the schema, and which is potentially outside the scope of the OVAL standards.

Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one.  Or do you really think we need to expand the scope of the external variables document to include collection of the values?

Regards,
--David Solin

On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something theuser_friendly_description could say “This is the filename of the file that contains x”.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the“comment” in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the user’s benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write 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: New element in VariableType of oval-variables-schema.xsd?

Panos Kampanakis (pkampana)
<base href="x-msg://1367/">

Luis’ idea is fine by me.

 

So, you are saying OCIL could be used with questionnaires to generate OCIL results and then jOval XPERT can be enhanced to generate the external variables from the OCI results?.

 

Is there a transition mechanism between OCIL output and OVAL external variable files or is it practically up to the implementer to perform the task?

 

Panos

 

 

From: David Solin [mailto:[hidden email]]
Sent: Tuesday, August 07, 2012 10:29 AM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

I only have experience with two products that make use of the OVAL variables file: ovaldi and jOVAL.  Both take the external variables file as input for processing OVAL definitions.  What makes an external variable "external" is that its value is not defined in the OVAL definitions document.  The specification doesn't say anything about querying users for values.  That kind of function is, in my mind, external to OVAL.

Now, Luis makes a great point -- there is a standard in the SCAP specification (OCIL) that is designed to be used to ask people questions.  Furthermore, XCCDF has the capability to define both variable imports and exports.  It would be fairly easy to import an answer from an OCIL question result.

Currently, XPERT only supports imports from SCE scripts, but it can produce OVAL variables file format documents encapsulating exports from the XCCDF document to the OVAL system.  It also handles importing OCIL results files.  So, with just a bit of extra work to support OCIL imports, you could do exactly what Luis proposes.

Regards,
--David Solin

On 8/7/2012 8:44 AM, Luis Nunez wrote:

Can we use OCIL to generate external variables for OVAL?  If can define the right questions to ask maybe OCIL could be the UI?

 

-ln

 

On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:



Thanks David.

 

So, what is the tool that today collects external variables? I don’t know of any.

 

What I was thinking was that an evaluator that checks for an oval def with an external variable certainly takes the external variable as its input. Now, if that external variable needs to be adjusted for my system I need to go in the external variable file and edit the values that I need to edit. And it is more likely that the external variable file will be provided as a template with the def, I don’t expect the user that will use the evaluator tool to write the external variable file from scratch.

 

So, if my thinking is right and the external variable file goes with the oval def, then wouldn’t it make sense to have a field that a GUI could use in order to take the external variable template file for the oval def and present to the user the fields he needs to populate and what they are?

 

> Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one. 

Doesn’t the OVAL author write the oval code and the external variables he will use, that need to be adjusted on a per-system basis? Having the oval author provide one more format to define what the external variables needed are, I think, is more complicated that what I am proposing.

 

BTW, has a format/schema or something been considered before for the external variable collection? Or has it always been assumed that external variables are provided somehow?

 

Rgs,

Panos

 

 

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, August 07, 2012 12:29 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Panos Kampanakis (pkampana)
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

Hi Panos,

The purpose of the variables schema is to transmit external variable values to an OVAL interpreter, not to collect those values.  I assume that collecting those values is the job of some other tool, that need not be restricted by the schema, and which is potentially outside the scope of the OVAL standards.

Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one.  Or do you really think we need to expand the scope of the external variables document to include collection of the values?

Regards,
--David Solin

On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something theuser_friendly_description could say “This is the filename of the file that contains x”.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the“comment” in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the user’s benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

PGP.sig (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

rhuffman
As an OVAL novice, I was thinking Pano's idea was already supported by OVAL using the comment element of a variable. However, the real problem is that the variables section does not need to be included in the OVAL document.

So, what if you simply allowed the inclusion of external_variable elements within an OVAL document without the value? Currently, the value is  required. If it was optional, then an OVAL author could include the external_variable and use the comment element to provide guidance to tools that could collect input from the user.

Using OCIL to collect values may be a decent idea, but that should be left up to vendors. Someone should be able to write a standalone OVAL tool without implementing OCIL. Just provide a mechanism for providing guidance about the meaning of an external variable within OVAL itself.




On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana) <[hidden email]> wrote:

Luis’ idea is fine by me.

 

So, you are saying OCIL could be used with questionnaires to generate OCIL results and then jOval XPERT can be enhanced to generate the external variables from the OCI results?.

 

Is there a transition mechanism between OCIL output and OVAL external variable files or is it practically up to the implementer to perform the task?

 

Panos

 

 

From: David Solin [mailto:[hidden email]]
Sent: Tuesday, August 07, 2012 10:29 AM
To: [hidden email]


Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

I only have experience with two products that make use of the OVAL variables file: ovaldi and jOVAL.  Both take the external variables file as input for processing OVAL definitions.  What makes an external variable "external" is that its value is not defined in the OVAL definitions document.  The specification doesn't say anything about querying users for values.  That kind of function is, in my mind, external to OVAL.

Now, Luis makes a great point -- there is a standard in the SCAP specification (OCIL) that is designed to be used to ask people questions.  Furthermore, XCCDF has the capability to define both variable imports and exports.  It would be fairly easy to import an answer from an OCIL question result.

Currently, XPERT only supports imports from SCE scripts, but it can produce OVAL variables file format documents encapsulating exports from the XCCDF document to the OVAL system.  It also handles importing OCIL results files.  So, with just a bit of extra work to support OCIL imports, you could do exactly what Luis proposes.

Regards,
--David Solin

On 8/7/2012 8:44 AM, Luis Nunez wrote:

Can we use OCIL to generate external variables for OVAL?  If can define the right questions to ask maybe OCIL could be the UI?

 

-ln

 

On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:



Thanks David.

 

So, what is the tool that today collects external variables? I don’t know of any.

 

What I was thinking was that an evaluator that checks for an oval def with an external variable certainly takes the external variable as its input. Now, if that external variable needs to be adjusted for my system I need to go in the external variable file and edit the values that I need to edit. And it is more likely that the external variable file will be provided as a template with the def, I don’t expect the user that will use the evaluator tool to write the external variable file from scratch.

 

So, if my thinking is right and the external variable file goes with the oval def, then wouldn’t it make sense to have a field that a GUI could use in order to take the external variable template file for the oval def and present to the user the fields he needs to populate and what they are?

 

> Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one. 

Doesn’t the OVAL author write the oval code and the external variables he will use, that need to be adjusted on a per-system basis? Having the oval author provide one more format to define what the external variables needed are, I think, is more complicated that what I am proposing.

 

BTW, has a format/schema or something been considered before for the external variable collection? Or has it always been assumed that external variables are provided somehow?

 

Rgs,

Panos

 

 

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, August 07, 2012 12:29 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Panos Kampanakis (pkampana)
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

Hi Panos,

The purpose of the variables schema is to transmit external variable values to an OVAL interpreter, not to collect those values.  I assume that collecting those values is the job of some other tool, that need not be restricted by the schema, and which is potentially outside the scope of the OVAL standards.

Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one.  Or do you really think we need to expand the scope of the external variables document to include collection of the values?

Regards,
--David Solin

On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something theuser_friendly_description could say “This is the filename of the file that contains x”.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the“comment” in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the user’s benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

Panos Kampanakis (pkampana)

Good point Robert.

 

In the rules we wrote, we were doing that. Kind of a sample external variable file that has the values that should be incorporated to be used in the oval.

 

That is why I was thinking a tool would benefit by somehow visualizing that template external variable file. It was a good point that OCIL can do it.

 

Still a sample external variable file that has sample variables with no or demo values to be used in the oval def is beneficial.

 

Panos

 

 

From: Robert Huffman [mailto:[hidden email]]
Sent: Monday, August 27, 2012 12:44 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

As an OVAL novice, I was thinking Pano's idea was already supported by OVAL using the comment element of a variable. However, the real problem is that the variables section does not need to be included in the OVAL document.

 

So, what if you simply allowed the inclusion of external_variable elements within an OVAL document without the value? Currently, the value is  required. If it was optional, then an OVAL author could include the external_variable and use the comment element to provide guidance to tools that could collect input from the user.

 

Using OCIL to collect values may be a decent idea, but that should be left up to vendors. Someone should be able to write a standalone OVAL tool without implementing OCIL. Just provide a mechanism for providing guidance about the meaning of an external variable within OVAL itself.

 

 

 

 

On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana) <[hidden email]> wrote:

Luis’ idea is fine by me.

 

So, you are saying OCIL could be used with questionnaires to generate OCIL results and then jOval XPERT can be enhanced to generate the external variables from the OCI results?.

 

Is there a transition mechanism between OCIL output and OVAL external variable files or is it practically up to the implementer to perform the task?

 

Panos

 

 

From: David Solin [mailto:[hidden email]]
Sent: Tuesday, August 07, 2012 10:29 AM
To: [hidden email]


Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

I only have experience with two products that make use of the OVAL variables file: ovaldi and jOVAL.  Both take the external variables file as input for processing OVAL definitions.  What makes an external variable "external" is that its value is not defined in the OVAL definitions document.  The specification doesn't say anything about querying users for values.  That kind of function is, in my mind, external to OVAL.

Now, Luis makes a great point -- there is a standard in the SCAP specification (OCIL) that is designed to be used to ask people questions.  Furthermore, XCCDF has the capability to define both variable imports and exports.  It would be fairly easy to import an answer from an OCIL question result.

Currently, XPERT only supports imports from SCE scripts, but it can produce OVAL variables file format documents encapsulating exports from the XCCDF document to the OVAL system.  It also handles importing OCIL results files.  So, with just a bit of extra work to support OCIL imports, you could do exactly what Luis proposes.

Regards,
--David Solin

On 8/7/2012 8:44 AM, Luis Nunez wrote:

Can we use OCIL to generate external variables for OVAL?  If can define the right questions to ask maybe OCIL could be the UI?

 

-ln

 

On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:

 

Thanks David.

 

So, what is the tool that today collects external variables? I don’t know of any.

 

What I was thinking was that an evaluator that checks for an oval def with an external variable certainly takes the external variable as its input. Now, if that external variable needs to be adjusted for my system I need to go in the external variable file and edit the values that I need to edit. And it is more likely that the external variable file will be provided as a template with the def, I don’t expect the user that will use the evaluator tool to write the external variable file from scratch.

 

So, if my thinking is right and the external variable file goes with the oval def, then wouldn’t it make sense to have a field that a GUI could use in order to take the external variable template file for the oval def and present to the user the fields he needs to populate and what they are?

 

> Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one. 

Doesn’t the OVAL author write the oval code and the external variables he will use, that need to be adjusted on a per-system basis? Having the oval author provide one more format to define what the external variables needed are, I think, is more complicated that what I am proposing.

 

BTW, has a format/schema or something been considered before for the external variable collection? Or has it always been assumed that external variables are provided somehow?

 

Rgs,

Panos

 

 

 

From: David Solin [[hidden email]On Behalf Of David Solin
Sent: Tuesday, August 07, 2012 12:29 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Panos Kampanakis (pkampana)
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

Hi Panos,

The purpose of the variables schema is to transmit external variable values to an OVAL interpreter, not to collect those values.  I assume that collecting those values is the job of some other tool, that need not be restricted by the schema, and which is potentially outside the scope of the OVAL standards.

Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one.  Or do you really think we need to expand the scope of the external variables document to include collection of the values?

Regards,
--David Solin

On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something theuser_friendly_description could say “This is the filename of the file that contains x”.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the“comment” in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the user’s benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

PGP.sig (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

joval
In reply to this post by rhuffman
The variables schema is independent of the definitions schemas.  It's simply a means of feeding external variable values to an interpreter.

Panos wanted to use this schema for some other purpose -- to work with a tool that would collect values.  Luis was just pointing out that SCAP actually has a way to do this exact thing, in an intended way.

XML is flexible.  If one wanted to decorate a variables file with other information, it could be defined in a different schema, with its own namespace, and simply added to the document.  An OVAL interpreter expecting a variables schema could safely ignore the extra data.  Alternatively, the tool could use its own format, and generate a schema-conforming variables document to feed into the OVAL interpreter -- which is exactly what the variables format is intended to do.

That's the issue I had with Panos's request.  I hope my reasoning makes sense!

Regards,
--David

On 8/27/2012 11:43 AM, Robert Huffman wrote:
As an OVAL novice, I was thinking Pano's idea was already supported by OVAL using the comment element of a variable. However, the real problem is that the variables section does not need to be included in the OVAL document.

So, what if you simply allowed the inclusion of external_variable elements within an OVAL document without the value? Currently, the value is  required. If it was optional, then an OVAL author could include the external_variable and use the comment element to provide guidance to tools that could collect input from the user.

Using OCIL to collect values may be a decent idea, but that should be left up to vendors. Someone should be able to write a standalone OVAL tool without implementing OCIL. Just provide a mechanism for providing guidance about the meaning of an external variable within OVAL itself.




On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana) <[hidden email]> wrote:

Luis’ idea is fine by me.

 

So, you are saying OCIL could be used with questionnaires to generate OCIL results and then jOval XPERT can be enhanced to generate the external variables from the OCI results?.

 

Is there a transition mechanism between OCIL output and OVAL external variable files or is it practically up to the implementer to perform the task?

 

Panos

 

 

From: David Solin [mailto:[hidden email]]
Sent: Tuesday, August 07, 2012 10:29 AM
To: [hidden email]


Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

I only have experience with two products that make use of the OVAL variables file: ovaldi and jOVAL.  Both take the external variables file as input for processing OVAL definitions.  What makes an external variable "external" is that its value is not defined in the OVAL definitions document.  The specification doesn't say anything about querying users for values.  That kind of function is, in my mind, external to OVAL.

Now, Luis makes a great point -- there is a standard in the SCAP specification (OCIL) that is designed to be used to ask people questions.  Furthermore, XCCDF has the capability to define both variable imports and exports.  It would be fairly easy to import an answer from an OCIL question result.

Currently, XPERT only supports imports from SCE scripts, but it can produce OVAL variables file format documents encapsulating exports from the XCCDF document to the OVAL system.  It also handles importing OCIL results files.  So, with just a bit of extra work to support OCIL imports, you could do exactly what Luis proposes.

Regards,
--David Solin

On 8/7/2012 8:44 AM, Luis Nunez wrote:

Can we use OCIL to generate external variables for OVAL?  If can define the right questions to ask maybe OCIL could be the UI?

 

-ln

 

On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:



Thanks David.

 

So, what is the tool that today collects external variables? I don’t know of any.

 

What I was thinking was that an evaluator that checks for an oval def with an external variable certainly takes the external variable as its input. Now, if that external variable needs to be adjusted for my system I need to go in the external variable file and edit the values that I need to edit. And it is more likely that the external variable file will be provided as a template with the def, I don’t expect the user that will use the evaluator tool to write the external variable file from scratch.

 

So, if my thinking is right and the external variable file goes with the oval def, then wouldn’t it make sense to have a field that a GUI could use in order to take the external variable template file for the oval def and present to the user the fields he needs to populate and what they are?

 

> Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one. 

Doesn’t the OVAL author write the oval code and the external variables he will use, that need to be adjusted on a per-system basis? Having the oval author provide one more format to define what the external variables needed are, I think, is more complicated that what I am proposing.

 

BTW, has a format/schema or something been considered before for the external variable collection? Or has it always been assumed that external variables are provided somehow?

 

Rgs,

Panos

 

 

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, August 07, 2012 12:29 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Panos Kampanakis (pkampana)
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

Hi Panos,

The purpose of the variables schema is to transmit external variable values to an OVAL interpreter, not to collect those values.  I assume that collecting those values is the job of some other tool, that need not be restricted by the schema, and which is potentially outside the scope of the OVAL standards.

Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one.  Or do you really think we need to expand the scope of the external variables document to include collection of the values?

Regards,
--David Solin

On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something theuser_friendly_description could say “This is the filename of the file that contains x”.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the“comment” in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the user’s benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write 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: New element in VariableType of oval-variables-schema.xsd?

Danny Haynes
Administrator

I was re-reading this thread and I think that there may be a generic OVAL-only solution for this.  Specifically, the oval-def:NotesType which has the following documentation (see Section 4.3.7 of the OVAL Language Specification):

 

  “The NotesType is a container for one or more notes, providing additional information, such as unresolved questions, reasons for specific implementation, or other documentation.”

 

The oval-def:NotesType construct is currently available to content authors for use in definitions, tests, objects, and states.  It is not currently supported in oval-def:external_variable, oval-def:constant_variable, oval-def:local_variable, or oval-var:variable.  I looked around and I couldn’t find a specific reason as to why the oval-def:NotesType construct was not included in the various variable constructs.  I think it was just something that we overlooked because there seemed to be consensus during the development of OVAL 5.0 that notes should be extended to tests, objects, states, etc. (see http://making-security-measurable.1364806.n2.nabble.com/OVAL-Metadata-tp22526.html).  If we added support for it, using Panos’ example, a variable in an OVAL Variable document might look like the following.

 

  <variable id="oval:sample:var:1" datatype="string" comment="This variable holds the filename that contains x.">

    <notes>

      <note>This is the filename of the file that contains x.</note>

      <note>You can identify this file by taking the following steps: …</note>

      …

    </notes>

    <value>file.txt</value>

  </variable>

 

A tool could then take the information contained in the notes and present it to the user.  Or, even better, a tool might look for the notes in the oval-def:external_variables, in the OVAL Definitions document, and could generate any number of formats (OVAL Variables, XCCDF, etc.) for reading in the oval-def:external_variable values.  Of course, all of this would be optional and it would be up to the content author to put the notes in a location where the tool is expecting them.

 

As for the schema, I think we could just pull the oval-def:NotesType up into the oval-common-schema.xsd.  From there, it could be used in both the oval-definitions-schema.xsd and the oval-variables-schema.xsd.

 

Does this seem like it would be a reasonable solution?

 

Thanks,

Danny

 

From: David Solin [mailto:[hidden email]]
Sent: Monday, August 27, 2012 4:12 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

The variables schema is independent of the definitions schemas.  It's simply a means of feeding external variable values to an interpreter.

Panos wanted to use this schema for some other purpose -- to work with a tool that would collect values.  Luis was just pointing out that SCAP actually has a way to do this exact thing, in an intended way.

XML is flexible.  If one wanted to decorate a variables file with other information, it could be defined in a different schema, with its own namespace, and simply added to the document.  An OVAL interpreter expecting a variables schema could safely ignore the extra data.  Alternatively, the tool could use its own format, and generate a schema-conforming variables document to feed into the OVAL interpreter -- which is exactly what the variables format is intended to do.

That's the issue I had with Panos's request.  I hope my reasoning makes sense!

Regards,
--David

On 8/27/2012 11:43 AM, Robert Huffman wrote:

As an OVAL novice, I was thinking Pano's idea was already supported by OVAL using the comment element of a variable. However, the real problem is that the variables section does not need to be included in the OVAL document.

 

So, what if you simply allowed the inclusion of external_variable elements within an OVAL document without the value? Currently, the value is  required. If it was optional, then an OVAL author could include the external_variable and use the comment element to provide guidance to tools that could collect input from the user.

 

Using OCIL to collect values may be a decent idea, but that should be left up to vendors. Someone should be able to write a standalone OVAL tool without implementing OCIL. Just provide a mechanism for providing guidance about the meaning of an external variable within OVAL itself.

 

 

 

 

On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana) <[hidden email]> wrote:

Luis’ idea is fine by me.

 

So, you are saying OCIL could be used with questionnaires to generate OCIL results and then jOval XPERT can be enhanced to generate the external variables from the OCI results?.

 

Is there a transition mechanism between OCIL output and OVAL external variable files or is it practically up to the implementer to perform the task?

 

Panos

 

 

From: David Solin [mailto:[hidden email]]
Sent: Tuesday, August 07, 2012 10:29 AM
To: [hidden email]


Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

I only have experience with two products that make use of the OVAL variables file: ovaldi and jOVAL.  Both take the external variables file as input for processing OVAL definitions.  What makes an external variable "external" is that its value is not defined in the OVAL definitions document.  The specification doesn't say anything about querying users for values.  That kind of function is, in my mind, external to OVAL.

Now, Luis makes a great point -- there is a standard in the SCAP specification (OCIL) that is designed to be used to ask people questions.  Furthermore, XCCDF has the capability to define both variable imports and exports.  It would be fairly easy to import an answer from an OCIL question result.

Currently, XPERT only supports imports from SCE scripts, but it can produce OVAL variables file format documents encapsulating exports from the XCCDF document to the OVAL system.  It also handles importing OCIL results files.  So, with just a bit of extra work to support OCIL imports, you could do exactly what Luis proposes.

Regards,
--David Solin

On 8/7/2012 8:44 AM, Luis Nunez wrote:

Can we use OCIL to generate external variables for OVAL?  If can define the right questions to ask maybe OCIL could be the UI?

 

-ln

 

On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:

 

Thanks David.

 

So, what is the tool that today collects external variables? I don’t know of any.

 

What I was thinking was that an evaluator that checks for an oval def with an external variable certainly takes the external variable as its input. Now, if that external variable needs to be adjusted for my system I need to go in the external variable file and edit the values that I need to edit. And it is more likely that the external variable file will be provided as a template with the def, I don’t expect the user that will use the evaluator tool to write the external variable file from scratch.

 

So, if my thinking is right and the external variable file goes with the oval def, then wouldn’t it make sense to have a field that a GUI could use in order to take the external variable template file for the oval def and present to the user the fields he needs to populate and what they are?

 

> Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one. 

Doesn’t the OVAL author write the oval code and the external variables he will use, that need to be adjusted on a per-system basis? Having the oval author provide one more format to define what the external variables needed are, I think, is more complicated that what I am proposing.

 

BTW, has a format/schema or something been considered before for the external variable collection? Or has it always been assumed that external variables are provided somehow?

 

Rgs,

Panos

 

 

 

From: David Solin [[hidden email]On Behalf Of David Solin
Sent: Tuesday, August 07, 2012 12:29 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Panos Kampanakis (pkampana)
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

Hi Panos,

The purpose of the variables schema is to transmit external variable values to an OVAL interpreter, not to collect those values.  I assume that collecting those values is the job of some other tool, that need not be restricted by the schema, and which is potentially outside the scope of the OVAL standards.

Given the above, couldn't you use a different format to feed such questions into a collection UI?  That tool would generate a variables file, but it certainly doesn't need to consume one.  Or do you really think we need to expand the scope of the external variables document to include collection of the values?

Regards,
--David Solin

On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

Hello everyone,

I wanted to submit a new element user_friendly_description in the VariableType of oval-variables-schema.xsd:

--------

<xsd:element name="user_friendly_description" type="xsd:string" minOccurs="0" maxOccurs="1">

                 <xsd:annotation>

                    <xsd:documentation>Note that the user_friendly_description is used by OVAL evaluation visual tools to provide a visual text to the user to ensure that he understands what the variable describes. Then he will be able to provide the external variable value that will be used by the tool to evaluate the definition.</xsd:documentation>

                 </xsd:annotation>

            </xsd:element>

--------

That element will be used by the OVAL evaluators that have a GUI to provide a visual text to the user. For example if the variable is used to give the failename that will be checked against something theuser_friendly_description could say “This is the filename of the file that contains x”.

What I envision is using an external variable file to be imported in an automated evaluation tool. That automated tool will show the field that needs its value populated in the external variables and it will show a text to the user based on the new element. So, the user can see what these variables are. After populating them in the GUI the tool will generate the external variable file to be run with OVAL. That way you have a visual way to tell the user how to populate the external variables and he doesn’t need to go update the xml directly and mess things up.

we can’t enforce that the author will write the explanation using the user_friendly_description. But we can enforce that the tool will show what the author wants when he wants it. We could have the tool to show the“comment” in the variable instead, but the comment is used in many places and authors could use it for many other reasons. So, the new element is practically for the tool. Authors will still leave it out if they want to, but if it is in there then the tool definitely knows what is it there for, for the user’s benefit and it will show it in the GUI.

What does the community think? Would it be beneficial to add it in the oval-variables-schema.xsd schema?

Rgs,

Panos

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

Gunnar Engelbach
I have to wonder, is such an open-ended ability really what Panos needs?
  In other words, does he really need the ability to adjust the value
for each possible test across the full range of what is legal for that
value?  Or will the expected usage tend to be more like a particular
state as defined by differing but static sets of values?  If the latter,
then using XCCDF as the front end with multiple profiles to define the
variable values would be considerably easier from a user standpoint.

The suggestion to use OCIL as a front end for this seems like a more
reasonable starting point.  OCIL was designed with the intent for human
interaction so I would expect it to be a more natural starting point for
getting response values from a human.  One important consideration, for
example, is that using explanatory notes doesn't provide for a
programmatic way to ensure that user input is valid for each variable,
which is something that OCIL does provide.  What OCIL lacks right now is
the ability to return the value of a question rather than the test
result of a question.


  --gun


On 9/12/2012 12:34 PM, Haynes, Dan wrote:

> I was re-reading this thread and I think that there may be a generic
> OVAL-only solution for this.  Specifically, the oval-def:NotesType which
> has the following documentation (see Section 4.3.7 of the OVAL Language
> Specification):
>
>    “The NotesType is a container for one or more notes, providing
> additional information, such as unresolved questions, reasons for
> specific implementation, or other documentation.”
>
> The oval-def:NotesType construct is currently available to content
> authors for use in definitions, tests, objects, and states.  It is not
> currently supported in oval-def:external_variable,
> oval-def:constant_variable, oval-def:local_variable, or
> oval-var:variable.  I looked around and I couldn’t find a specific
> reason as to why the oval-def:NotesType construct was not included in
> the various variable constructs.  I think it was just something that we
> overlooked because there seemed to be consensus during the development
> of OVAL 5.0 that notes should be extended to tests, objects, states,
> etc. (see
> http://making-security-measurable.1364806.n2.nabble.com/OVAL-Metadata-tp22526.html).
> If we added support for it, using Panos’ example, a variable in an OVAL
> Variable document might look like the following.
>
>    <variable id="oval:sample:var:1" datatype="string" comment="This
> variable holds the filename that contains x.">
>
>      <notes>
>
>        <note>This is the filename of the file that contains x.</note>
>
>        <note>You can identify this file by taking the following steps:
> …</note>
>
>        …
>
>      </notes>
>
>      <value>file.txt</value>
>
>    </variable>
>
> A tool could then take the information contained in the notes and
> present it to the user.  Or, even better, a tool might look for the
> notes in the oval-def:external_variables, in the OVAL Definitions
> document, and could generate any number of formats (OVAL Variables,
> XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
> course, all of this would be optional and it would be up to the content
> author to put the notes in a location where the tool is expecting them.
>
> As for the schema, I think we could just pull the oval-def:NotesType up
> into the oval-common-schema.xsd.  From there, it could be used in both
> the oval-definitions-schema.xsd and the oval-variables-schema.xsd.
>
> Does this seem like it would be a reasonable solution?
>
> Thanks,
>
> Danny
>
> *From:*David Solin [mailto:[hidden email]]
> *Sent:* Monday, August 27, 2012 4:12 PM
> *To:* oval-developer-list OVAL Developer List/Closed Public Discussion
> *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
> oval-variables-schema.xsd?
>
> The variables schema is independent of the definitions schemas.  It's
> simply a means of feeding external variable values to an interpreter.
>
> Panos wanted to use this schema for some other purpose -- to work with a
> tool that would collect values.  Luis was just pointing out that SCAP
> actually has a way to do this exact thing, in an intended way.
>
> XML is flexible.  If one wanted to decorate a variables file with other
> information, it could be defined in a different schema, with its own
> namespace, and simply added to the document.  An OVAL interpreter
> expecting a variables schema could safely ignore the extra data.
> Alternatively, the tool could use its own format, and generate a
> schema-conforming variables document to feed into the OVAL interpreter
> -- which is exactly what the variables format is intended to do.
>
> That's the issue I had with Panos's request.  I hope my reasoning makes
> sense!
>
> Regards,
> --David
>
> On 8/27/2012 11:43 AM, Robert Huffman wrote:
>
> As an OVAL novice, I was thinking Pano's idea was already supported by
> OVAL using the comment element of a variable. However, the real problem
> is that the variables section does not need to be included in the OVAL
> document.
>
> So, what if you simply allowed the inclusion of external_variable
> elements within an OVAL document without the value? Currently, the value
> is  required. If it was optional, then an OVAL author could include the
> external_variable and use the comment element to provide guidance to
> tools that could collect input from the user.
>
> Using OCIL to collect values may be a decent idea, but that should be
> left up to vendors. Someone should be able to write a standalone OVAL
> tool without implementing OCIL. Just provide a mechanism for providing
> guidance about the meaning of an external variable within OVAL itself.
>
> On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Luis’ idea is fine by me.
>
>     So, you are saying OCIL could be used with questionnaires to
>     generate OCIL results and then jOval XPERT can be enhanced to
>     generate the external variables from the OCI results?.
>
>     Is there a transition mechanism between OCIL output and OVAL
>     external variable files or is it practically up to the implementer
>     to perform the task?
>
>     Panos
>
>     *From:*David Solin [mailto:[hidden email] <mailto:[hidden email]>]
>     *Sent:* Tuesday, August 07, 2012 10:29 AM
>     *To:* [hidden email]
>     <mailto:[hidden email]>
>
>
>     *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
>     oval-variables-schema.xsd?
>
>     I only have experience with two products that make use of the OVAL
>     variables file: ovaldi and jOVAL.  Both take the external variables
>     file as input for processing OVAL definitions. What makes an
>     external variable "external" is that its value is not defined in the
>     OVAL definitions document.  The specification doesn't say anything
>     about querying users for values.  That kind of function is, in my
>     mind, external to OVAL.
>
>     Now, Luis makes a great point -- there is a standard in the SCAP
>     specification (OCIL) that is designed to be used to ask people
>     questions.  Furthermore, XCCDF has the capability to define both
>     variable imports and exports.  It would be fairly easy to import an
>     answer from an OCIL question result.
>
>     Currently, XPERT only supports imports from SCE scripts, but it can
>     produce OVAL variables file format documents encapsulating exports
>     from the XCCDF document to the OVAL system.  It also handles
>     importing OCIL results files.  So, with just a bit of extra work to
>     support OCIL imports, you could do exactly what Luis proposes.
>
>     Regards,
>     --David Solin
>
>     On 8/7/2012 8:44 AM, Luis Nunez wrote:
>
>         Can we use OCIL to generate external variables for OVAL?  If can
>         define the right questions to ask maybe OCIL could be the UI?
>
>         -ln
>
>         On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:
>
>         Thanks David.
>
>         So, what is the tool that today collects external variables? I
>         don’t know of any.
>
>         What I was thinking was that an evaluator that checks for an
>         oval def with an external variable certainly takes the external
>         variable as its input. Now, if that external variable needs to
>         be adjusted for my system I need to go in the external variable
>         file and edit the values that I need to edit. And it is more
>         likely that the external variable file will be provided as a
>         template with the def, I don’t expect the user that will use the
>         evaluator tool to write the external variable file from scratch.
>
>         So, if my thinking is right and the external variable file goes
>         with the oval def, then wouldn’t it make sense to have a field
>         that a GUI could use in order to take the external variable
>         template file for the oval def and present to the user the
>         fields he needs to populate and what they are?
>
>          > Given the above, couldn't you use a different format to feed
>         such questions into a collection UI?  That tool would generate a
>         variables file, but it certainly doesn't need to consume one.
>
>         Doesn’t the OVAL author write the oval code and the external
>         variables he will use, that need to be adjusted on a per-system
>         basis? Having the oval author provide one more format to define
>         what the external variables needed are, I think, is more
>         complicated that what I am proposing.
>
>         BTW, has a format/schema or something been considered before for
>         the external variable collection? Or has it always been assumed
>         that external variables are provided somehow?
>
>         Rgs,
>
>         Panos
>
>         *From:* David Solin [mailto:[hidden email]] *On
>         Behalf Of *David Solin
>         *Sent:* Tuesday, August 07, 2012 12:29 AM
>         *To:* OVAL Developer List (Closed Public Discussion)
>         *Cc:* Panos Kampanakis (pkampana)
>         *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType
>         of oval-variables-schema.xsd?
>
>         Hi Panos,
>
>         The purpose of the variables schema is to transmit external
>         variable values to an OVAL interpreter, not to collect those
>         values.  I assume that collecting those values is the job of
>         some other tool, that need not be restricted by the schema, and
>         which is potentially outside the scope of the OVAL standards.
>
>         Given the above, couldn't you use a different format to feed
>         such questions into a collection UI?  That tool would generate a
>         variables file, but it certainly doesn't need to consume one.
>         Or do you really think we need to expand the scope of the
>         external variables document to include collection of the values?
>
>         Regards,
>         --David Solin
>
>         On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:
>
>             Hello everyone,
>
>             I wanted to submit a new element user_friendly_description
>             in the VariableType of oval-variables-schema.xsd:
>
>             --------
>
>             <xsd:element name="user_friendly_description"
>             type="xsd:string" minOccurs="0" maxOccurs="1">
>
>                               <xsd:annotation>
>
>                                  <xsd:documentation>Note that the
>             user_friendly_description is used by OVAL evaluation visual
>             tools to provide a visual text to the user to ensure that he
>             understands what the variable describes. Then he will be
>             able to provide the external variable value that will be
>             used by the tool to evaluate the definition.</xsd:documentation>
>
>                               </xsd:annotation>
>
>                          </xsd:element>
>
>             --------
>
>             That element will be used by the OVAL evaluators that have a
>             GUI to provide a visual text to the user. For example if the
>             variable is used to give the failename that will be checked
>             against something theuser_friendly_description could say
>             “This is the filename of the file that contains x”.
>
>             What I envision is using an external variable file to be
>             imported in an automated evaluation tool. That automated
>             tool will show the field that needs its value populated in
>             the external variables and it will show a text to the user
>             based on the new element. So, the user can see what these
>             variables are. After populating them in the GUI the tool
>             will generate the external variable file to be run with
>             OVAL. That way you have a visual way to tell the user how to
>             populate the external variables and he doesn’t need to go
>             update the xml directly and mess things up.
>
>             we can’t enforce that the author will write the explanation
>             using the user_friendly_description. But we can enforce that
>             the tool will show what the author wants when he wants it.
>             We could have the tool to show the“comment” in the variable
>             instead, but the comment is used in many places and authors
>             could use it for many other reasons. So, the new element is
>             practically for the tool. Authors will still leave it out if
>             they want to, but if it is in there then the tool definitely
>             knows what is it there for, for the user’s benefit and it
>             will show it in the GUI.
>
>             What does the community think? Would it be beneficial to add
>             it in the oval-variables-schema.xsd schema?
>
>             Rgs,
>
>             Panos
>
>             To unsubscribe, send an email message to
>             [hidden email]
>             <mailto:[hidden email]> with SIGNOFF
>             OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>             difficulties, write to
>             [hidden email]
>             <mailto:[hidden email]>.
>
>         --
>
>         jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
>         /Scan any machine from any machine. For free!/
>         Learn More <http://www.joval.org> | Features
>         <http://www.joval.org/features/> | Download
>         <http://www.joval.org/download/>
>
>         To unsubscribe, send an email message to
>         [hidden email] <mailto:[hidden email]> with
>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>         have difficulties, write to
>         [hidden email]
>         <mailto:[hidden email]>.
>
>         To unsubscribe, send an email message to
>         [hidden email] <mailto:[hidden email]> with
>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>         have difficulties, write to
>         [hidden email]
>         <mailto:[hidden email]>.
>
>     --
>
>     jOVAL.org: OVAL implemented in Java.
>     /Scan any machine from any machine. For free!/
>     Learn More <http://www.joval.org> | Features
>     <http://www.joval.org/features/> | Download
>     <http://www.joval.org/download/>
>
>     To unsubscribe, send an email message to [hidden email]
>     <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST
>     in the BODY of the message. If you have difficulties, write to
>     [hidden email]
>     <mailto:[hidden email]>.
>
>     To unsubscribe, send an email message to [hidden email]
>     <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST
>     in the BODY of the message. If you have difficulties, write to
>     [hidden email]
>     <mailto:[hidden email]>.
>
> To unsubscribe, send an email message to [hidden email]
> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST in
> the BODY of the message. If you have difficulties, write to
> [hidden email]
> <mailto:[hidden email]>.
>
> --
>
> jOVAL.org: OVAL implemented in Java.
> /Scan any machine from any machine. For free!/
> Learn More <http://www.joval.org> | Features
> <http://www.joval.org/features/> | Download
> <http://www.joval.org/download/>
>
> To unsubscribe, send an email message to [hidden email]
> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST in
> the BODY of the message. If you have difficulties, write to
> [hidden email]
> <mailto:[hidden email]>.
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
> difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

joval
Hi Gunnar,

I think you should be able to get an answer /value/ from OCIL into XCCDF using a variable import.  In fact, IIRC, imports can take the form of generic XPATH queries -- so there would be no problem grabbing a value.

Regarding Danny's proposal, anyway, I have no objection at all.

Cheers,
--David

On 9/12/2012 11:52 AM, Gunnar Engelbach wrote:
I have to wonder, is such an open-ended ability really what Panos needs?  In other words, does he really need the ability to adjust the value for each possible test across the full range of what is legal for that value?  Or will the expected usage tend to be more like a particular state as defined by differing but static sets of values?  If the latter, then using XCCDF as the front end with multiple profiles to define the variable values would be considerably easier from a user standpoint.

The suggestion to use OCIL as a front end for this seems like a more reasonable starting point.  OCIL was designed with the intent for human interaction so I would expect it to be a more natural starting point for getting response values from a human.  One important consideration, for example, is that using explanatory notes doesn't provide for a programmatic way to ensure that user input is valid for each variable, which is something that OCIL does provide.  What OCIL lacks right now is the ability to return the value of a question rather than the test result of a question.


 --gun


On 9/12/2012 12:34 PM, Haynes, Dan wrote:
I was re-reading this thread and I think that there may be a generic
OVAL-only solution for this.  Specifically, the oval-def:NotesType which
has the following documentation (see Section 4.3.7 of the OVAL Language
Specification):

   “The NotesType is a container for one or more notes, providing
additional information, such as unresolved questions, reasons for
specific implementation, or other documentation.”

The oval-def:NotesType construct is currently available to content
authors for use in definitions, tests, objects, and states.  It is not
currently supported in oval-def:external_variable,
oval-def:constant_variable, oval-def:local_variable, or
oval-var:variable.  I looked around and I couldn’t find a specific
reason as to why the oval-def:NotesType construct was not included in
the various variable constructs.  I think it was just something that we
overlooked because there seemed to be consensus during the development
of OVAL 5.0 that notes should be extended to tests, objects, states,
etc. (see
http://making-security-measurable.1364806.n2.nabble.com/OVAL-Metadata-tp22526.html).
If we added support for it, using Panos’ example, a variable in an OVAL
Variable document might look like the following.

   <variable id="oval:sample:var:1" datatype="string" comment="This
variable holds the filename that contains x.">

     <notes>

       <note>This is the filename of the file that contains x.</note>

       <note>You can identify this file by taking the following steps:
…</note>

       …

     </notes>

     <value>file.txt</value>

   </variable>

A tool could then take the information contained in the notes and
present it to the user.  Or, even better, a tool might look for the
notes in the oval-def:external_variables, in the OVAL Definitions
document, and could generate any number of formats (OVAL Variables,
XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
course, all of this would be optional and it would be up to the content
author to put the notes in a location where the tool is expecting them.

As for the schema, I think we could just pull the oval-def:NotesType up
into the oval-common-schema.xsd.  From there, it could be used in both
the oval-definitions-schema.xsd and the oval-variables-schema.xsd.

Does this seem like it would be a reasonable solution?

Thanks,

Danny

*From:*David Solin [[hidden email]]
*Sent:* Monday, August 27, 2012 4:12 PM
*To:* oval-developer-list OVAL Developer List/Closed Public Discussion
*Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
oval-variables-schema.xsd?

The variables schema is independent of the definitions schemas.  It's
simply a means of feeding external variable values to an interpreter.

Panos wanted to use this schema for some other purpose -- to work with a
tool that would collect values.  Luis was just pointing out that SCAP
actually has a way to do this exact thing, in an intended way.

XML is flexible.  If one wanted to decorate a variables file with other
information, it could be defined in a different schema, with its own
namespace, and simply added to the document.  An OVAL interpreter
expecting a variables schema could safely ignore the extra data.
Alternatively, the tool could use its own format, and generate a
schema-conforming variables document to feed into the OVAL interpreter
-- which is exactly what the variables format is intended to do.

That's the issue I had with Panos's request.  I hope my reasoning makes
sense!

Regards,
--David

On 8/27/2012 11:43 AM, Robert Huffman wrote:

As an OVAL novice, I was thinking Pano's idea was already supported by
OVAL using the comment element of a variable. However, the real problem
is that the variables section does not need to be included in the OVAL
document.

So, what if you simply allowed the inclusion of external_variable
elements within an OVAL document without the value? Currently, the value
is  required. If it was optional, then an OVAL author could include the
external_variable and use the comment element to provide guidance to
tools that could collect input from the user.

Using OCIL to collect values may be a decent idea, but that should be
left up to vendors. Someone should be able to write a standalone OVAL
tool without implementing OCIL. Just provide a mechanism for providing
guidance about the meaning of an external variable within OVAL itself.

On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
<[hidden email] [hidden email]> wrote:

    Luis’ idea is fine by me.

    So, you are saying OCIL could be used with questionnaires to
    generate OCIL results and then jOval XPERT can be enhanced to
    generate the external variables from the OCI results?.

    Is there a transition mechanism between OCIL output and OVAL
    external variable files or is it practically up to the implementer
    to perform the task?

    Panos

    *From:*David Solin [[hidden email] [hidden email]]
    *Sent:* Tuesday, August 07, 2012 10:29 AM
    *To:* [hidden email]
    [hidden email]


    *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
    oval-variables-schema.xsd?

    I only have experience with two products that make use of the OVAL
    variables file: ovaldi and jOVAL.  Both take the external variables
    file as input for processing OVAL definitions. What makes an
    external variable "external" is that its value is not defined in the
    OVAL definitions document.  The specification doesn't say anything
    about querying users for values.  That kind of function is, in my
    mind, external to OVAL.

    Now, Luis makes a great point -- there is a standard in the SCAP
    specification (OCIL) that is designed to be used to ask people
    questions.  Furthermore, XCCDF has the capability to define both
    variable imports and exports.  It would be fairly easy to import an
    answer from an OCIL question result.

    Currently, XPERT only supports imports from SCE scripts, but it can
    produce OVAL variables file format documents encapsulating exports
    from the XCCDF document to the OVAL system.  It also handles
    importing OCIL results files.  So, with just a bit of extra work to
    support OCIL imports, you could do exactly what Luis proposes.

    Regards,
    --David Solin

    On 8/7/2012 8:44 AM, Luis Nunez wrote:

        Can we use OCIL to generate external variables for OVAL?  If can
        define the right questions to ask maybe OCIL could be the UI?

        -ln

        On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:

        Thanks David.

        So, what is the tool that today collects external variables? I
        don’t know of any.

        What I was thinking was that an evaluator that checks for an
        oval def with an external variable certainly takes the external
        variable as its input. Now, if that external variable needs to
        be adjusted for my system I need to go in the external variable
        file and edit the values that I need to edit. And it is more
        likely that the external variable file will be provided as a
        template with the def, I don’t expect the user that will use the
        evaluator tool to write the external variable file from scratch.

        So, if my thinking is right and the external variable file goes
        with the oval def, then wouldn’t it make sense to have a field
        that a GUI could use in order to take the external variable
        template file for the oval def and present to the user the
        fields he needs to populate and what they are?

         > Given the above, couldn't you use a different format to feed
        such questions into a collection UI?  That tool would generate a
        variables file, but it certainly doesn't need to consume one.

        Doesn’t the OVAL author write the oval code and the external
        variables he will use, that need to be adjusted on a per-system
        basis? Having the oval author provide one more format to define
        what the external variables needed are, I think, is more
        complicated that what I am proposing.

        BTW, has a format/schema or something been considered before for
        the external variable collection? Or has it always been assumed
        that external variables are provided somehow?

        Rgs,

        Panos

        *From:* David Solin [[hidden email]] *On
        Behalf Of *David Solin
        *Sent:* Tuesday, August 07, 2012 12:29 AM
        *To:* OVAL Developer List (Closed Public Discussion)
        *Cc:* Panos Kampanakis (pkampana)
        *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType
        of oval-variables-schema.xsd?

        Hi Panos,

        The purpose of the variables schema is to transmit external
        variable values to an OVAL interpreter, not to collect those
        values.  I assume that collecting those values is the job of
        some other tool, that need not be restricted by the schema, and
        which is potentially outside the scope of the OVAL standards.

        Given the above, couldn't you use a different format to feed
        such questions into a collection UI?  That tool would generate a
        variables file, but it certainly doesn't need to consume one.
        Or do you really think we need to expand the scope of the
        external variables document to include collection of the values?

        Regards,
        --David Solin

        On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

            Hello everyone,

            I wanted to submit a new element user_friendly_description
            in the VariableType of oval-variables-schema.xsd:

            --------

            <xsd:element name="user_friendly_description"
            type="xsd:string" minOccurs="0" maxOccurs="1">

                              <xsd:annotation>

                                 <xsd:documentation>Note that the
            user_friendly_description is used by OVAL evaluation visual
            tools to provide a visual text to the user to ensure that he
            understands what the variable describes. Then he will be
            able to provide the external variable value that will be
            used by the tool to evaluate the definition.</xsd:documentation>

                              </xsd:annotation>

                         </xsd:element>

            --------

            That element will be used by the OVAL evaluators that have a
            GUI to provide a visual text to the user. For example if the
            variable is used to give the failename that will be checked
            against something theuser_friendly_description could say
            “This is the filename of the file that contains x”.

            What I envision is using an external variable file to be
            imported in an automated evaluation tool. That automated
            tool will show the field that needs its value populated in
            the external variables and it will show a text to the user
            based on the new element. So, the user can see what these
            variables are. After populating them in the GUI the tool
            will generate the external variable file to be run with
            OVAL. That way you have a visual way to tell the user how to
            populate the external variables and he doesn’t need to go
            update the xml directly and mess things up.

            we can’t enforce that the author will write the explanation
            using the user_friendly_description. But we can enforce that
            the tool will show what the author wants when he wants it.
            We could have the tool to show the“comment” in the variable
            instead, but the comment is used in many places and authors
            could use it for many other reasons. So, the new element is
            practically for the tool. Authors will still leave it out if
            they want to, but if it is in there then the tool definitely
            knows what is it there for, for the user’s benefit and it
            will show it in the GUI.

            What does the community think? Would it be beneficial to add
            it in the oval-variables-schema.xsd schema?

            Rgs,

            Panos

            To unsubscribe, send an email message to
            [hidden email]
            [hidden email] with SIGNOFF
            OVAL-DEVELOPER-LIST in the BODY of the message. If you have
            difficulties, write to
            [hidden email]
            [hidden email].

        --

        jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
        /Scan any machine from any machine. For free!/
        Learn More <http://www.joval.org> | Features
        <http://www.joval.org/features/> | Download
        <http://www.joval.org/download/>

        To unsubscribe, send an email message to
        [hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
        [hidden email]
        [hidden email].

        To unsubscribe, send an email message to
        [hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
        [hidden email]
        [hidden email].

    --

    jOVAL.org: OVAL implemented in Java.
    /Scan any machine from any machine. For free!/
    Learn More <http://www.joval.org> | Features
    <http://www.joval.org/features/> | Download
    <http://www.joval.org/download/>

    To unsubscribe, send an email message to [hidden email]
    [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
    [hidden email]
    [hidden email].

    To unsubscribe, send an email message to [hidden email]
    [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
    [hidden email]
    [hidden email].

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].


--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write 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: New element in VariableType of oval-variables-schema.xsd?

Gunnar Engelbach
On 9/12/2012 2:15 PM, David Solin wrote:
> Hi Gunnar,
>
> I think you should be able to get an answer /value/ from OCIL into XCCDF
> using a variable import.  In fact, IIRC, imports can take the form of
> generic XPATH queries -- so there would be no problem grabbing a value.


Not really that simple.

First, because processing the <question_results> section of an OCIL
report using XPATH is outside of any of the standards.  In other words,
there isn't a mechanism within any of the standards to get a user-input
value from OCIL to XCCDF or OVAL.

Second, the user response won't necessarily be recorded as a raw value,
but might in fact be a reference to one of the possible values
enumerated by the question.


Try to bolt extended functionality onto OVAL doesn't make sense to me
and just makes it needlessly more complicated.  Instead it makes more
sense to take advantage of OCIL as a complimentary standard whose
designed purpose is human interaction.




>
> Regarding Danny's proposal, anyway, I have no objection at all.
>
> Cheers,
> --David
>
> On 9/12/2012 11:52 AM, Gunnar Engelbach wrote:
>> I have to wonder, is such an open-ended ability really what Panos
>> needs?  In other words, does he really need the ability to adjust the
>> value for each possible test across the full range of what is legal
>> for that value?  Or will the expected usage tend to be more like a
>> particular state as defined by differing but static sets of values?
>> If the latter, then using XCCDF as the front end with multiple
>> profiles to define the variable values would be considerably easier
>> from a user standpoint.
>>
>> The suggestion to use OCIL as a front end for this seems like a more
>> reasonable starting point.  OCIL was designed with the intent for
>> human interaction so I would expect it to be a more natural starting
>> point for getting response values from a human.  One important
>> consideration, for example, is that using explanatory notes doesn't
>> provide for a programmatic way to ensure that user input is valid for
>> each variable, which is something that OCIL does provide.  What OCIL
>> lacks right now is the ability to return the value of a question
>> rather than the test result of a question.
>>
>>
>>  --gun
>>
>>
>> On 9/12/2012 12:34 PM, Haynes, Dan wrote:
>>> I was re-reading this thread and I think that there may be a generic
>>> OVAL-only solution for this.  Specifically, the oval-def:NotesType which
>>> has the following documentation (see Section 4.3.7 of the OVAL Language
>>> Specification):
>>>
>>>    “The NotesType is a container for one or more notes, providing
>>> additional information, such as unresolved questions, reasons for
>>> specific implementation, or other documentation.”
>>>
>>> The oval-def:NotesType construct is currently available to content
>>> authors for use in definitions, tests, objects, and states.  It is not
>>> currently supported in oval-def:external_variable,
>>> oval-def:constant_variable, oval-def:local_variable, or
>>> oval-var:variable.  I looked around and I couldn’t find a specific
>>> reason as to why the oval-def:NotesType construct was not included in
>>> the various variable constructs.  I think it was just something that we
>>> overlooked because there seemed to be consensus during the development
>>> of OVAL 5.0 that notes should be extended to tests, objects, states,
>>> etc. (see
>>> http://making-security-measurable.1364806.n2.nabble.com/OVAL-Metadata-tp22526.html).
>>>
>>> If we added support for it, using Panos’ example, a variable in an OVAL
>>> Variable document might look like the following.
>>>
>>>    <variable id="oval:sample:var:1" datatype="string" comment="This
>>> variable holds the filename that contains x.">
>>>
>>>      <notes>
>>>
>>>        <note>This is the filename of the file that contains x.</note>
>>>
>>>        <note>You can identify this file by taking the following steps:
>>> …</note>
>>>
>>>        …
>>>
>>>      </notes>
>>>
>>>      <value>file.txt</value>
>>>
>>>    </variable>
>>>
>>> A tool could then take the information contained in the notes and
>>> present it to the user.  Or, even better, a tool might look for the
>>> notes in the oval-def:external_variables, in the OVAL Definitions
>>> document, and could generate any number of formats (OVAL Variables,
>>> XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
>>> course, all of this would be optional and it would be up to the content
>>> author to put the notes in a location where the tool is expecting them.
>>>
>>> As for the schema, I think we could just pull the oval-def:NotesType up
>>> into the oval-common-schema.xsd.  From there, it could be used in both
>>> the oval-definitions-schema.xsd and the oval-variables-schema.xsd.
>>>
>>> Does this seem like it would be a reasonable solution?
>>>
>>> Thanks,
>>>
>>> Danny
>>>
>>> *From:*David Solin [mailto:[hidden email]]
>>> *Sent:* Monday, August 27, 2012 4:12 PM
>>> *To:* oval-developer-list OVAL Developer List/Closed Public Discussion
>>> *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
>>> oval-variables-schema.xsd?
>>>
>>> The variables schema is independent of the definitions schemas. It's
>>> simply a means of feeding external variable values to an interpreter.
>>>
>>> Panos wanted to use this schema for some other purpose -- to work with a
>>> tool that would collect values.  Luis was just pointing out that SCAP
>>> actually has a way to do this exact thing, in an intended way.
>>>
>>> XML is flexible.  If one wanted to decorate a variables file with other
>>> information, it could be defined in a different schema, with its own
>>> namespace, and simply added to the document.  An OVAL interpreter
>>> expecting a variables schema could safely ignore the extra data.
>>> Alternatively, the tool could use its own format, and generate a
>>> schema-conforming variables document to feed into the OVAL interpreter
>>> -- which is exactly what the variables format is intended to do.
>>>
>>> That's the issue I had with Panos's request.  I hope my reasoning makes
>>> sense!
>>>
>>> Regards,
>>> --David
>>>
>>> On 8/27/2012 11:43 AM, Robert Huffman wrote:
>>>
>>> As an OVAL novice, I was thinking Pano's idea was already supported by
>>> OVAL using the comment element of a variable. However, the real problem
>>> is that the variables section does not need to be included in the OVAL
>>> document.
>>>
>>> So, what if you simply allowed the inclusion of external_variable
>>> elements within an OVAL document without the value? Currently, the value
>>> is  required. If it was optional, then an OVAL author could include the
>>> external_variable and use the comment element to provide guidance to
>>> tools that could collect input from the user.
>>>
>>> Using OCIL to collect values may be a decent idea, but that should be
>>> left up to vendors. Someone should be able to write a standalone OVAL
>>> tool without implementing OCIL. Just provide a mechanism for providing
>>> guidance about the meaning of an external variable within OVAL itself.
>>>
>>> On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>     Luis’ idea is fine by me.
>>>
>>>     So, you are saying OCIL could be used with questionnaires to
>>>     generate OCIL results and then jOval XPERT can be enhanced to
>>>     generate the external variables from the OCI results?.
>>>
>>>     Is there a transition mechanism between OCIL output and OVAL
>>>     external variable files or is it practically up to the implementer
>>>     to perform the task?
>>>
>>>     Panos
>>>
>>>     *From:*David Solin [mailto:[hidden email] <mailto:[hidden email]>]
>>>     *Sent:* Tuesday, August 07, 2012 10:29 AM
>>>     *To:* [hidden email]
>>> <mailto:[hidden email]>
>>>
>>>
>>>     *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
>>>     oval-variables-schema.xsd?
>>>
>>>     I only have experience with two products that make use of the OVAL
>>>     variables file: ovaldi and jOVAL.  Both take the external variables
>>>     file as input for processing OVAL definitions. What makes an
>>>     external variable "external" is that its value is not defined in the
>>>     OVAL definitions document.  The specification doesn't say anything
>>>     about querying users for values.  That kind of function is, in my
>>>     mind, external to OVAL.
>>>
>>>     Now, Luis makes a great point -- there is a standard in the SCAP
>>>     specification (OCIL) that is designed to be used to ask people
>>>     questions.  Furthermore, XCCDF has the capability to define both
>>>     variable imports and exports.  It would be fairly easy to import an
>>>     answer from an OCIL question result.
>>>
>>>     Currently, XPERT only supports imports from SCE scripts, but it can
>>>     produce OVAL variables file format documents encapsulating exports
>>>     from the XCCDF document to the OVAL system.  It also handles
>>>     importing OCIL results files.  So, with just a bit of extra work to
>>>     support OCIL imports, you could do exactly what Luis proposes.
>>>
>>>     Regards,
>>>     --David Solin
>>>
>>>     On 8/7/2012 8:44 AM, Luis Nunez wrote:
>>>
>>>         Can we use OCIL to generate external variables for OVAL?  If can
>>>         define the right questions to ask maybe OCIL could be the UI?
>>>
>>>         -ln
>>>
>>>         On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:
>>>
>>>         Thanks David.
>>>
>>>         So, what is the tool that today collects external variables? I
>>>         don’t know of any.
>>>
>>>         What I was thinking was that an evaluator that checks for an
>>>         oval def with an external variable certainly takes the external
>>>         variable as its input. Now, if that external variable needs to
>>>         be adjusted for my system I need to go in the external variable
>>>         file and edit the values that I need to edit. And it is more
>>>         likely that the external variable file will be provided as a
>>>         template with the def, I don’t expect the user that will use the
>>>         evaluator tool to write the external variable file from scratch.
>>>
>>>         So, if my thinking is right and the external variable file goes
>>>         with the oval def, then wouldn’t it make sense to have a field
>>>         that a GUI could use in order to take the external variable
>>>         template file for the oval def and present to the user the
>>>         fields he needs to populate and what they are?
>>>
>>>          > Given the above, couldn't you use a different format to feed
>>>         such questions into a collection UI?  That tool would generate a
>>>         variables file, but it certainly doesn't need to consume one.
>>>
>>>         Doesn’t the OVAL author write the oval code and the external
>>>         variables he will use, that need to be adjusted on a per-system
>>>         basis? Having the oval author provide one more format to define
>>>         what the external variables needed are, I think, is more
>>>         complicated that what I am proposing.
>>>
>>>         BTW, has a format/schema or something been considered before for
>>>         the external variable collection? Or has it always been assumed
>>>         that external variables are provided somehow?
>>>
>>>         Rgs,
>>>
>>>         Panos
>>>
>>>         *From:* David Solin [mailto:[hidden email]] *On
>>>         Behalf Of *David Solin
>>>         *Sent:* Tuesday, August 07, 2012 12:29 AM
>>>         *To:* OVAL Developer List (Closed Public Discussion)
>>>         *Cc:* Panos Kampanakis (pkampana)
>>>         *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType
>>>         of oval-variables-schema.xsd?
>>>
>>>         Hi Panos,
>>>
>>>         The purpose of the variables schema is to transmit external
>>>         variable values to an OVAL interpreter, not to collect those
>>>         values.  I assume that collecting those values is the job of
>>>         some other tool, that need not be restricted by the schema, and
>>>         which is potentially outside the scope of the OVAL standards.
>>>
>>>         Given the above, couldn't you use a different format to feed
>>>         such questions into a collection UI?  That tool would generate a
>>>         variables file, but it certainly doesn't need to consume one.
>>>         Or do you really think we need to expand the scope of the
>>>         external variables document to include collection of the values?
>>>
>>>         Regards,
>>>         --David Solin
>>>
>>>         On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:
>>>
>>>             Hello everyone,
>>>
>>>             I wanted to submit a new element user_friendly_description
>>>             in the VariableType of oval-variables-schema.xsd:
>>>
>>>             --------
>>>
>>>             <xsd:element name="user_friendly_description"
>>>             type="xsd:string" minOccurs="0" maxOccurs="1">
>>>
>>>                               <xsd:annotation>
>>>
>>>                                  <xsd:documentation>Note that the
>>>             user_friendly_description is used by OVAL evaluation visual
>>>             tools to provide a visual text to the user to ensure that he
>>>             understands what the variable describes. Then he will be
>>>             able to provide the external variable value that will be
>>>             used by the tool to evaluate the
>>> definition.</xsd:documentation>
>>>
>>>                               </xsd:annotation>
>>>
>>>                          </xsd:element>
>>>
>>>             --------
>>>
>>>             That element will be used by the OVAL evaluators that have a
>>>             GUI to provide a visual text to the user. For example if the
>>>             variable is used to give the failename that will be checked
>>>             against something theuser_friendly_description could say
>>>             “This is the filename of the file that contains x”.
>>>
>>>             What I envision is using an external variable file to be
>>>             imported in an automated evaluation tool. That automated
>>>             tool will show the field that needs its value populated in
>>>             the external variables and it will show a text to the user
>>>             based on the new element. So, the user can see what these
>>>             variables are. After populating them in the GUI the tool
>>>             will generate the external variable file to be run with
>>>             OVAL. That way you have a visual way to tell the user how to
>>>             populate the external variables and he doesn’t need to go
>>>             update the xml directly and mess things up.
>>>
>>>             we can’t enforce that the author will write the explanation
>>>             using the user_friendly_description. But we can enforce that
>>>             the tool will show what the author wants when he wants it.
>>>             We could have the tool to show the“comment” in the variable
>>>             instead, but the comment is used in many places and authors
>>>             could use it for many other reasons. So, the new element is
>>>             practically for the tool. Authors will still leave it out if
>>>             they want to, but if it is in there then the tool definitely
>>>             knows what is it there for, for the user’s benefit and it
>>>             will show it in the GUI.
>>>
>>>             What does the community think? Would it be beneficial to add
>>>             it in the oval-variables-schema.xsd schema?
>>>
>>>             Rgs,
>>>
>>>             Panos
>>>
>>>             To unsubscribe, send an email message to
>>> [hidden email]
>>> <mailto:[hidden email]> with SIGNOFF
>>>             OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>>             difficulties, write to
>>> [hidden email]
>>> <mailto:[hidden email]>.
>>>
>>>         --
>>>
>>>         jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
>>>         /Scan any machine from any machine. For free!/
>>>         Learn More <http://www.joval.org> | Features
>>> <http://www.joval.org/features/> | Download
>>> <http://www.joval.org/download/>
>>>
>>>         To unsubscribe, send an email message to
>>> [hidden email] <mailto:[hidden email]> with
>>>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>         have difficulties, write to
>>> [hidden email]
>>> <mailto:[hidden email]>.
>>>
>>>         To unsubscribe, send an email message to
>>> [hidden email] <mailto:[hidden email]> with
>>>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>         have difficulties, write to
>>> [hidden email]
>>> <mailto:[hidden email]>.
>>>
>>>     --
>>>
>>>     jOVAL.org: OVAL implemented in Java.
>>>     /Scan any machine from any machine. For free!/
>>>     Learn More <http://www.joval.org> | Features
>>> <http://www.joval.org/features/> | Download
>>> <http://www.joval.org/download/>
>>>
>>>     To unsubscribe, send an email message to [hidden email]
>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST
>>>     in the BODY of the message. If you have difficulties, write to
>>> [hidden email]
>>> <mailto:[hidden email]>.
>>>
>>>     To unsubscribe, send an email message to [hidden email]
>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST
>>>     in the BODY of the message. If you have difficulties, write to
>>> [hidden email]
>>> <mailto:[hidden email]>.
>>>
>>> To unsubscribe, send an email message to [hidden email]
>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST in
>>> the BODY of the message. If you have difficulties, write to
>>> [hidden email]
>>> <mailto:[hidden email]>.
>>>
>>> --
>>>
>>> jOVAL.org: OVAL implemented in Java.
>>> /Scan any machine from any machine. For free!/
>>> Learn More <http://www.joval.org> | Features
>>> <http://www.joval.org/features/> | Download
>>> <http://www.joval.org/download/>
>>>
>>> To unsubscribe, send an email message to [hidden email]
>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST in
>>> the BODY of the message. If you have difficulties, write to
>>> [hidden email]
>>> <mailto:[hidden email]>.
>>>
>>> To unsubscribe, send an email message to [hidden email] with
>>> SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>> difficulties, write to [hidden email].
>>
>> To unsubscribe, send an email message to [hidden email] with
>> SIGNOFF OVAL-DEVELOPER-LIST
>> in the BODY of the message.  If you have difficulties, write to
>> [hidden email].
>
>
> --
>
> jOVAL.org: OVAL implemented in Java.
> /Scan any machine from any machine. For free!/
> Learn More <http://www.joval.org> | Features
> <http://www.joval.org/features/> | Download
> <http://www.joval.org/download/>
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

joval
It is that simple.  OCIL results actually spell out the answer value under the xpath:
/ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer

The value of the entity is the actual answer value, including (if applicable) a resolved variable value.

Now, assuming you have control

On 9/12/2012 1:37 PM, Gunnar Engelbach wrote:
On 9/12/2012 2:15 PM, David Solin wrote:
Hi Gunnar,

I think you should be able to get an answer /value/ from OCIL into XCCDF
using a variable import.  In fact, IIRC, imports can take the form of
generic XPATH queries -- so there would be no problem grabbing a value.


Not really that simple.

First, because processing the <question_results> section of an OCIL report using XPATH is outside of any of the standards.  In other words, there isn't a mechanism within any of the standards to get a user-input value from OCIL to XCCDF or OVAL.

Sure there is.

http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf

Section 6.4.4.4. <xccdf:check> check-import element is described:

"Identifies a value to be retrieved from the checking system during testing of a target system. This element MUST be empty. After the associated check results have been collected, the result structure returned by the checking engine is processed to collect the named information. This information is then recorded in the <xccdf:check-import> element in the corresponding <xccdf:rule-result>. This could be a single value or structured XML. In the latter case, the @import-xpath attribute can be used to traverse the structured XML and identify specific information of interest to record in the result."

If the question is a string_question, then the XPATH expression:
/ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer

... will be populated with the user's actual response.

Map the import to a value, and the value to an export and... Voila.  A value is passed as output from one check system and into another.


Second, the user response won't necessarily be recorded as a raw value, but might in fact be a reference to one of the possible values enumerated by the question.


One can manipulate that data, of course, but aren't we are assuming that this hypothetical OCIL was authored intentionally to collect variable values?


Try to bolt extended functionality onto OVAL doesn't make sense to me and just makes it needlessly more complicated.  Instead it makes more sense to take advantage of OCIL as a complimentary standard whose designed purpose is human interaction.


SCAP is the wrong place to avoid needless complexity! ;)

I agree that a purpose-built tool could be less cumbersome, but that's almost invariably the case with purpose-built tools, for obvious reasons.

The one thing that's truly unspecified is whether it's legal to chain import and export relationships.  This would have potentially very complicated implications on the order in which checks must be executed.  The existing XCCDF interpreters I've worked with that support OCIL (those are, jOVAL XPERT and the reference XCCDF interpreter -- xccdfexec) both evaluate OCIL first, then OVAL.





Regarding Danny's proposal, anyway, I have no objection at all.

Cheers,
--David

On 9/12/2012 11:52 AM, Gunnar Engelbach wrote:
I have to wonder, is such an open-ended ability really what Panos
needs?  In other words, does he really need the ability to adjust the
value for each possible test across the full range of what is legal
for that value?  Or will the expected usage tend to be more like a
particular state as defined by differing but static sets of values?
If the latter, then using XCCDF as the front end with multiple
profiles to define the variable values would be considerably easier
from a user standpoint.

The suggestion to use OCIL as a front end for this seems like a more
reasonable starting point.  OCIL was designed with the intent for
human interaction so I would expect it to be a more natural starting
point for getting response values from a human.  One important
consideration, for example, is that using explanatory notes doesn't
provide for a programmatic way to ensure that user input is valid for
each variable, which is something that OCIL does provide.  What OCIL
lacks right now is the ability to return the value of a question
rather than the test result of a question.


 --gun


On 9/12/2012 12:34 PM, Haynes, Dan wrote:
I was re-reading this thread and I think that there may be a generic
OVAL-only solution for this.  Specifically, the oval-def:NotesType which
has the following documentation (see Section 4.3.7 of the OVAL Language
Specification):

   “The NotesType is a container for one or more notes, providing
additional information, such as unresolved questions, reasons for
specific implementation, or other documentation.”

The oval-def:NotesType construct is currently available to content
authors for use in definitions, tests, objects, and states.  It is not
currently supported in oval-def:external_variable,
oval-def:constant_variable, oval-def:local_variable, or
oval-var:variable.  I looked around and I couldn’t find a specific
reason as to why the oval-def:NotesType construct was not included in
the various variable constructs.  I think it was just something that we
overlooked because there seemed to be consensus during the development
of OVAL 5.0 that notes should be extended to tests, objects, states,
etc. (see
http://making-security-measurable.1364806.n2.nabble.com/OVAL-Metadata-tp22526.html).

If we added support for it, using Panos’ example, a variable in an OVAL
Variable document might look like the following.

   <variable id="oval:sample:var:1" datatype="string" comment="This
variable holds the filename that contains x.">

     <notes>

       <note>This is the filename of the file that contains x.</note>

       <note>You can identify this file by taking the following steps:
…</note>

       …

     </notes>

     <value>file.txt</value>

   </variable>

A tool could then take the information contained in the notes and
present it to the user.  Or, even better, a tool might look for the
notes in the oval-def:external_variables, in the OVAL Definitions
document, and could generate any number of formats (OVAL Variables,
XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
course, all of this would be optional and it would be up to the content
author to put the notes in a location where the tool is expecting them.

As for the schema, I think we could just pull the oval-def:NotesType up
into the oval-common-schema.xsd.  From there, it could be used in both
the oval-definitions-schema.xsd and the oval-variables-schema.xsd.

Does this seem like it would be a reasonable solution?

Thanks,

Danny

*From:*David Solin [[hidden email]]
*Sent:* Monday, August 27, 2012 4:12 PM
*To:* oval-developer-list OVAL Developer List/Closed Public Discussion
*Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
oval-variables-schema.xsd?

The variables schema is independent of the definitions schemas. It's
simply a means of feeding external variable values to an interpreter.

Panos wanted to use this schema for some other purpose -- to work with a
tool that would collect values.  Luis was just pointing out that SCAP
actually has a way to do this exact thing, in an intended way.

XML is flexible.  If one wanted to decorate a variables file with other
information, it could be defined in a different schema, with its own
namespace, and simply added to the document.  An OVAL interpreter
expecting a variables schema could safely ignore the extra data.
Alternatively, the tool could use its own format, and generate a
schema-conforming variables document to feed into the OVAL interpreter
-- which is exactly what the variables format is intended to do.

That's the issue I had with Panos's request.  I hope my reasoning makes
sense!

Regards,
--David

On 8/27/2012 11:43 AM, Robert Huffman wrote:

As an OVAL novice, I was thinking Pano's idea was already supported by
OVAL using the comment element of a variable. However, the real problem
is that the variables section does not need to be included in the OVAL
document.

So, what if you simply allowed the inclusion of external_variable
elements within an OVAL document without the value? Currently, the value
is  required. If it was optional, then an OVAL author could include the
external_variable and use the comment element to provide guidance to
tools that could collect input from the user.

Using OCIL to collect values may be a decent idea, but that should be
left up to vendors. Someone should be able to write a standalone OVAL
tool without implementing OCIL. Just provide a mechanism for providing
guidance about the meaning of an external variable within OVAL itself.

On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
<[hidden email] [hidden email]> wrote:

    Luis’ idea is fine by me.

    So, you are saying OCIL could be used with questionnaires to
    generate OCIL results and then jOval XPERT can be enhanced to
    generate the external variables from the OCI results?.

    Is there a transition mechanism between OCIL output and OVAL
    external variable files or is it practically up to the implementer
    to perform the task?

    Panos

    *From:*David Solin [[hidden email] [hidden email]]
    *Sent:* Tuesday, August 07, 2012 10:29 AM
    *To:* [hidden email]
[hidden email]


    *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
    oval-variables-schema.xsd?

    I only have experience with two products that make use of the OVAL
    variables file: ovaldi and jOVAL.  Both take the external variables
    file as input for processing OVAL definitions. What makes an
    external variable "external" is that its value is not defined in the
    OVAL definitions document.  The specification doesn't say anything
    about querying users for values.  That kind of function is, in my
    mind, external to OVAL.

    Now, Luis makes a great point -- there is a standard in the SCAP
    specification (OCIL) that is designed to be used to ask people
    questions.  Furthermore, XCCDF has the capability to define both
    variable imports and exports.  It would be fairly easy to import an
    answer from an OCIL question result.

    Currently, XPERT only supports imports from SCE scripts, but it can
    produce OVAL variables file format documents encapsulating exports
    from the XCCDF document to the OVAL system.  It also handles
    importing OCIL results files.  So, with just a bit of extra work to
    support OCIL imports, you could do exactly what Luis proposes.

    Regards,
    --David Solin

    On 8/7/2012 8:44 AM, Luis Nunez wrote:

        Can we use OCIL to generate external variables for OVAL?  If can
        define the right questions to ask maybe OCIL could be the UI?

        -ln

        On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:

        Thanks David.

        So, what is the tool that today collects external variables? I
        don’t know of any.

        What I was thinking was that an evaluator that checks for an
        oval def with an external variable certainly takes the external
        variable as its input. Now, if that external variable needs to
        be adjusted for my system I need to go in the external variable
        file and edit the values that I need to edit. And it is more
        likely that the external variable file will be provided as a
        template with the def, I don’t expect the user that will use the
        evaluator tool to write the external variable file from scratch.

        So, if my thinking is right and the external variable file goes
        with the oval def, then wouldn’t it make sense to have a field
        that a GUI could use in order to take the external variable
        template file for the oval def and present to the user the
        fields he needs to populate and what they are?

         > Given the above, couldn't you use a different format to feed
        such questions into a collection UI?  That tool would generate a
        variables file, but it certainly doesn't need to consume one.

        Doesn’t the OVAL author write the oval code and the external
        variables he will use, that need to be adjusted on a per-system
        basis? Having the oval author provide one more format to define
        what the external variables needed are, I think, is more
        complicated that what I am proposing.

        BTW, has a format/schema or something been considered before for
        the external variable collection? Or has it always been assumed
        that external variables are provided somehow?

        Rgs,

        Panos

        *From:* David Solin [[hidden email]] *On
        Behalf Of *David Solin
        *Sent:* Tuesday, August 07, 2012 12:29 AM
        *To:* OVAL Developer List (Closed Public Discussion)
        *Cc:* Panos Kampanakis (pkampana)
        *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType
        of oval-variables-schema.xsd?

        Hi Panos,

        The purpose of the variables schema is to transmit external
        variable values to an OVAL interpreter, not to collect those
        values.  I assume that collecting those values is the job of
        some other tool, that need not be restricted by the schema, and
        which is potentially outside the scope of the OVAL standards.

        Given the above, couldn't you use a different format to feed
        such questions into a collection UI?  That tool would generate a
        variables file, but it certainly doesn't need to consume one.
        Or do you really think we need to expand the scope of the
        external variables document to include collection of the values?

        Regards,
        --David Solin

        On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

            Hello everyone,

            I wanted to submit a new element user_friendly_description
            in the VariableType of oval-variables-schema.xsd:

            --------

            <xsd:element name="user_friendly_description"
            type="xsd:string" minOccurs="0" maxOccurs="1">

                              <xsd:annotation>

                                 <xsd:documentation>Note that the
            user_friendly_description is used by OVAL evaluation visual
            tools to provide a visual text to the user to ensure that he
            understands what the variable describes. Then he will be
            able to provide the external variable value that will be
            used by the tool to evaluate the
definition.</xsd:documentation>

                              </xsd:annotation>

                         </xsd:element>

            --------

            That element will be used by the OVAL evaluators that have a
            GUI to provide a visual text to the user. For example if the
            variable is used to give the failename that will be checked
            against something theuser_friendly_description could say
            “This is the filename of the file that contains x”.

            What I envision is using an external variable file to be
            imported in an automated evaluation tool. That automated
            tool will show the field that needs its value populated in
            the external variables and it will show a text to the user
            based on the new element. So, the user can see what these
            variables are. After populating them in the GUI the tool
            will generate the external variable file to be run with
            OVAL. That way you have a visual way to tell the user how to
            populate the external variables and he doesn’t need to go
            update the xml directly and mess things up.

            we can’t enforce that the author will write the explanation
            using the user_friendly_description. But we can enforce that
            the tool will show what the author wants when he wants it.
            We could have the tool to show the“comment” in the variable
            instead, but the comment is used in many places and authors
            could use it for many other reasons. So, the new element is
            practically for the tool. Authors will still leave it out if
            they want to, but if it is in there then the tool definitely
            knows what is it there for, for the user’s benefit and it
            will show it in the GUI.

            What does the community think? Would it be beneficial to add
            it in the oval-variables-schema.xsd schema?

            Rgs,

            Panos

            To unsubscribe, send an email message to
[hidden email]
[hidden email] with SIGNOFF
            OVAL-DEVELOPER-LIST in the BODY of the message. If you have
            difficulties, write to
[hidden email]
[hidden email].

        --

        jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
        /Scan any machine from any machine. For free!/
        Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

        To unsubscribe, send an email message to
[hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
[hidden email]
[hidden email].

        To unsubscribe, send an email message to
[hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
[hidden email]
[hidden email].

    --

    jOVAL.org: OVAL implemented in Java.
    /Scan any machine from any machine. For free!/
    Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

    To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

    To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].


--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>


To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].


--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write 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: New element in VariableType of oval-variables-schema.xsd?

Gunnar Engelbach
That's all possible if what Panos is requesting represents the very rare
and closed-loop case.  But since Danny is talking about extending the
schema it sounds as if he's trying to offer a more broadly usable solution.

To that end, I think that changes necessary to enable using the user as
a data source should be done in the standard meant to do user
interaction:  OCIL.  Most of side affects of processing user input has
already been thought out there.  Additionally, since it is not yet
widely used, schema changes will not have as much of an impact.

On the other hand, if the view is that OVAL should be capable of
covering more use cases as a standalone, then Danny's suggestion is the
simplest way to get there (and could have some utility outside of this
specific usage) -- with the caveat that it doesn't allow for type
checking, response validation, etc, without some further changes.



On 9/12/2012 3:06 PM, David Solin wrote:

> It is that simple.  OCIL results actually spell out the answer value
> under the xpath:
> /ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer
>
> The value of the entity is the actual answer value, including (if
> applicable) a resolved variable value.
>
> Now, assuming you have control
>
> On 9/12/2012 1:37 PM, Gunnar Engelbach wrote:
>> On 9/12/2012 2:15 PM, David Solin wrote:
>>> Hi Gunnar,
>>>
>>> I think you should be able to get an answer /value/ from OCIL into XCCDF
>>> using a variable import.  In fact, IIRC, imports can take the form of
>>> generic XPATH queries -- so there would be no problem grabbing a value.
>>
>>
>> Not really that simple.
>>
>> First, because processing the <question_results> section of an OCIL
>> report using XPATH is outside of any of the standards.  In other
>> words, there isn't a mechanism within any of the standards to get a
>> user-input value from OCIL to XCCDF or OVAL.
>
> Sure there is.
>
> http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf
>
> Section 6.4.4.4. <xccdf:check> check-import element is described:
>
> "Identifies a value to be retrieved from the checking system during
> testing of a target system. This element MUST be empty. After the
> associated check results have been collected, the result structure
> returned by the checking engine is processed to collect the named
> information. This information is then recorded in the
> <xccdf:check-import> element in the corresponding <xccdf:rule-result>.
> This could be a single value or structured XML. In the latter case, the
> @import-xpath attribute can be used to traverse the structured XML and
> identify specific information of interest to record in the result."
>
> If the question is a string_question, then the XPATH expression:
> /ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer
>
> ... will be populated with the user's actual response.
>
> Map the import to a value, and the value to an export and... Voila. A
> value is passed as output from one check system and into another.
>
>>
>> Second, the user response won't necessarily be recorded as a raw
>> value, but might in fact be a reference to one of the possible values
>> enumerated by the question.
>>
>
> One can manipulate that data, of course, but aren't we are assuming that
> this hypothetical OCIL was authored intentionally to collect variable
> values?
>
>>
>> Try to bolt extended functionality onto OVAL doesn't make sense to me
>> and just makes it needlessly more complicated.  Instead it makes more
>> sense to take advantage of OCIL as a complimentary standard whose
>> designed purpose is human interaction.
>>
>
> SCAP is the wrong place to avoid needless complexity! ;)
>
> I agree that a purpose-built tool could be less cumbersome, but that's
> almost invariably the case with purpose-built tools, for obvious reasons.
>
> The one thing that's truly unspecified is whether it's legal to chain
> import and export relationships.  This would have potentially very
> complicated implications on the order in which checks must be executed.
> The existing XCCDF interpreters I've worked with that support OCIL
> (those are, jOVAL XPERT and the reference XCCDF interpreter --
> xccdfexec) both evaluate OCIL first, then OVAL.
>
>>
>>
>>
>>>
>>> Regarding Danny's proposal, anyway, I have no objection at all.
>>>
>>> Cheers,
>>> --David
>>>
>>> On 9/12/2012 11:52 AM, Gunnar Engelbach wrote:
>>>> I have to wonder, is such an open-ended ability really what Panos
>>>> needs?  In other words, does he really need the ability to adjust the
>>>> value for each possible test across the full range of what is legal
>>>> for that value?  Or will the expected usage tend to be more like a
>>>> particular state as defined by differing but static sets of values?
>>>> If the latter, then using XCCDF as the front end with multiple
>>>> profiles to define the variable values would be considerably easier
>>>> from a user standpoint.
>>>>
>>>> The suggestion to use OCIL as a front end for this seems like a more
>>>> reasonable starting point.  OCIL was designed with the intent for
>>>> human interaction so I would expect it to be a more natural starting
>>>> point for getting response values from a human.  One important
>>>> consideration, for example, is that using explanatory notes doesn't
>>>> provide for a programmatic way to ensure that user input is valid for
>>>> each variable, which is something that OCIL does provide. What OCIL
>>>> lacks right now is the ability to return the value of a question
>>>> rather than the test result of a question.
>>>>
>>>>
>>>>  --gun
>>>>
>>>>
>>>> On 9/12/2012 12:34 PM, Haynes, Dan wrote:
>>>>> I was re-reading this thread and I think that there may be a generic
>>>>> OVAL-only solution for this.  Specifically, the oval-def:NotesType
>>>>> which
>>>>> has the following documentation (see Section 4.3.7 of the OVAL
>>>>> Language
>>>>> Specification):
>>>>>
>>>>>    “The NotesType is a container for one or more notes, providing
>>>>> additional information, such as unresolved questions, reasons for
>>>>> specific implementation, or other documentation.”
>>>>>
>>>>> The oval-def:NotesType construct is currently available to content
>>>>> authors for use in definitions, tests, objects, and states. It is not
>>>>> currently supported in oval-def:external_variable,
>>>>> oval-def:constant_variable, oval-def:local_variable, or
>>>>> oval-var:variable.  I looked around and I couldn’t find a specific
>>>>> reason as to why the oval-def:NotesType construct was not included in
>>>>> the various variable constructs.  I think it was just something
>>>>> that we
>>>>> overlooked because there seemed to be consensus during the development
>>>>> of OVAL 5.0 that notes should be extended to tests, objects, states,
>>>>> etc. (see
>>>>> http://making-security-measurable.1364806.n2.nabble.com/OVAL-Metadata-tp22526.html).
>>>>>
>>>>>
>>>>> If we added support for it, using Panos’ example, a variable in an
>>>>> OVAL
>>>>> Variable document might look like the following.
>>>>>
>>>>>    <variable id="oval:sample:var:1" datatype="string" comment="This
>>>>> variable holds the filename that contains x.">
>>>>>
>>>>>      <notes>
>>>>>
>>>>>        <note>This is the filename of the file that contains x.</note>
>>>>>
>>>>>        <note>You can identify this file by taking the following steps:
>>>>> …</note>
>>>>>
>>>>>        …
>>>>>
>>>>>      </notes>
>>>>>
>>>>>      <value>file.txt</value>
>>>>>
>>>>>    </variable>
>>>>>
>>>>> A tool could then take the information contained in the notes and
>>>>> present it to the user.  Or, even better, a tool might look for the
>>>>> notes in the oval-def:external_variables, in the OVAL Definitions
>>>>> document, and could generate any number of formats (OVAL Variables,
>>>>> XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
>>>>> course, all of this would be optional and it would be up to the
>>>>> content
>>>>> author to put the notes in a location where the tool is expecting
>>>>> them.
>>>>>
>>>>> As for the schema, I think we could just pull the
>>>>> oval-def:NotesType up
>>>>> into the oval-common-schema.xsd.  From there, it could be used in both
>>>>> the oval-definitions-schema.xsd and the oval-variables-schema.xsd.
>>>>>
>>>>> Does this seem like it would be a reasonable solution?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Danny
>>>>>
>>>>> *From:*David Solin [mailto:[hidden email]]
>>>>> *Sent:* Monday, August 27, 2012 4:12 PM
>>>>> *To:* oval-developer-list OVAL Developer List/Closed Public Discussion
>>>>> *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
>>>>> oval-variables-schema.xsd?
>>>>>
>>>>> The variables schema is independent of the definitions schemas. It's
>>>>> simply a means of feeding external variable values to an interpreter.
>>>>>
>>>>> Panos wanted to use this schema for some other purpose -- to work
>>>>> with a
>>>>> tool that would collect values.  Luis was just pointing out that SCAP
>>>>> actually has a way to do this exact thing, in an intended way.
>>>>>
>>>>> XML is flexible.  If one wanted to decorate a variables file with
>>>>> other
>>>>> information, it could be defined in a different schema, with its own
>>>>> namespace, and simply added to the document.  An OVAL interpreter
>>>>> expecting a variables schema could safely ignore the extra data.
>>>>> Alternatively, the tool could use its own format, and generate a
>>>>> schema-conforming variables document to feed into the OVAL interpreter
>>>>> -- which is exactly what the variables format is intended to do.
>>>>>
>>>>> That's the issue I had with Panos's request.  I hope my reasoning
>>>>> makes
>>>>> sense!
>>>>>
>>>>> Regards,
>>>>> --David
>>>>>
>>>>> On 8/27/2012 11:43 AM, Robert Huffman wrote:
>>>>>
>>>>> As an OVAL novice, I was thinking Pano's idea was already supported by
>>>>> OVAL using the comment element of a variable. However, the real
>>>>> problem
>>>>> is that the variables section does not need to be included in the OVAL
>>>>> document.
>>>>>
>>>>> So, what if you simply allowed the inclusion of external_variable
>>>>> elements within an OVAL document without the value? Currently, the
>>>>> value
>>>>> is  required. If it was optional, then an OVAL author could include
>>>>> the
>>>>> external_variable and use the comment element to provide guidance to
>>>>> tools that could collect input from the user.
>>>>>
>>>>> Using OCIL to collect values may be a decent idea, but that should be
>>>>> left up to vendors. Someone should be able to write a standalone OVAL
>>>>> tool without implementing OCIL. Just provide a mechanism for providing
>>>>> guidance about the meaning of an external variable within OVAL itself.
>>>>>
>>>>> On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
>>>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>
>>>>>     Luis’ idea is fine by me.
>>>>>
>>>>>     So, you are saying OCIL could be used with questionnaires to
>>>>>     generate OCIL results and then jOval XPERT can be enhanced to
>>>>>     generate the external variables from the OCI results?.
>>>>>
>>>>>     Is there a transition mechanism between OCIL output and OVAL
>>>>>     external variable files or is it practically up to the implementer
>>>>>     to perform the task?
>>>>>
>>>>>     Panos
>>>>>
>>>>>     *From:*David Solin [mailto:[hidden email]
>>>>> <mailto:[hidden email]>]
>>>>>     *Sent:* Tuesday, August 07, 2012 10:29 AM
>>>>>     *To:* [hidden email]
>>>>> <mailto:[hidden email]>
>>>>>
>>>>>
>>>>>     *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
>>>>> VariableType of
>>>>>     oval-variables-schema.xsd?
>>>>>
>>>>>     I only have experience with two products that make use of the OVAL
>>>>>     variables file: ovaldi and jOVAL.  Both take the external
>>>>> variables
>>>>>     file as input for processing OVAL definitions. What makes an
>>>>>     external variable "external" is that its value is not defined
>>>>> in the
>>>>>     OVAL definitions document.  The specification doesn't say anything
>>>>>     about querying users for values.  That kind of function is, in my
>>>>>     mind, external to OVAL.
>>>>>
>>>>>     Now, Luis makes a great point -- there is a standard in the SCAP
>>>>>     specification (OCIL) that is designed to be used to ask people
>>>>>     questions.  Furthermore, XCCDF has the capability to define both
>>>>>     variable imports and exports.  It would be fairly easy to
>>>>> import an
>>>>>     answer from an OCIL question result.
>>>>>
>>>>>     Currently, XPERT only supports imports from SCE scripts, but it
>>>>> can
>>>>>     produce OVAL variables file format documents encapsulating exports
>>>>>     from the XCCDF document to the OVAL system.  It also handles
>>>>>     importing OCIL results files.  So, with just a bit of extra
>>>>> work to
>>>>>     support OCIL imports, you could do exactly what Luis proposes.
>>>>>
>>>>>     Regards,
>>>>>     --David Solin
>>>>>
>>>>>     On 8/7/2012 8:44 AM, Luis Nunez wrote:
>>>>>
>>>>>         Can we use OCIL to generate external variables for OVAL?
>>>>> If can
>>>>>         define the right questions to ask maybe OCIL could be the UI?
>>>>>
>>>>>         -ln
>>>>>
>>>>>         On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:
>>>>>
>>>>>         Thanks David.
>>>>>
>>>>>         So, what is the tool that today collects external variables? I
>>>>>         don’t know of any.
>>>>>
>>>>>         What I was thinking was that an evaluator that checks for an
>>>>>         oval def with an external variable certainly takes the
>>>>> external
>>>>>         variable as its input. Now, if that external variable needs to
>>>>>         be adjusted for my system I need to go in the external
>>>>> variable
>>>>>         file and edit the values that I need to edit. And it is more
>>>>>         likely that the external variable file will be provided as a
>>>>>         template with the def, I don’t expect the user that will
>>>>> use the
>>>>>         evaluator tool to write the external variable file from
>>>>> scratch.
>>>>>
>>>>>         So, if my thinking is right and the external variable file
>>>>> goes
>>>>>         with the oval def, then wouldn’t it make sense to have a field
>>>>>         that a GUI could use in order to take the external variable
>>>>>         template file for the oval def and present to the user the
>>>>>         fields he needs to populate and what they are?
>>>>>
>>>>>          > Given the above, couldn't you use a different format to
>>>>> feed
>>>>>         such questions into a collection UI?  That tool would
>>>>> generate a
>>>>>         variables file, but it certainly doesn't need to consume one.
>>>>>
>>>>>         Doesn’t the OVAL author write the oval code and the external
>>>>>         variables he will use, that need to be adjusted on a
>>>>> per-system
>>>>>         basis? Having the oval author provide one more format to
>>>>> define
>>>>>         what the external variables needed are, I think, is more
>>>>>         complicated that what I am proposing.
>>>>>
>>>>>         BTW, has a format/schema or something been considered
>>>>> before for
>>>>>         the external variable collection? Or has it always been
>>>>> assumed
>>>>>         that external variables are provided somehow?
>>>>>
>>>>>         Rgs,
>>>>>
>>>>>         Panos
>>>>>
>>>>>         *From:* David Solin [mailto:[hidden email]] *On
>>>>>         Behalf Of *David Solin
>>>>>         *Sent:* Tuesday, August 07, 2012 12:29 AM
>>>>>         *To:* OVAL Developer List (Closed Public Discussion)
>>>>>         *Cc:* Panos Kampanakis (pkampana)
>>>>>         *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
>>>>> VariableType
>>>>>         of oval-variables-schema.xsd?
>>>>>
>>>>>         Hi Panos,
>>>>>
>>>>>         The purpose of the variables schema is to transmit external
>>>>>         variable values to an OVAL interpreter, not to collect those
>>>>>         values.  I assume that collecting those values is the job of
>>>>>         some other tool, that need not be restricted by the schema,
>>>>> and
>>>>>         which is potentially outside the scope of the OVAL standards.
>>>>>
>>>>>         Given the above, couldn't you use a different format to feed
>>>>>         such questions into a collection UI?  That tool would
>>>>> generate a
>>>>>         variables file, but it certainly doesn't need to consume one.
>>>>>         Or do you really think we need to expand the scope of the
>>>>>         external variables document to include collection of the
>>>>> values?
>>>>>
>>>>>         Regards,
>>>>>         --David Solin
>>>>>
>>>>>         On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:
>>>>>
>>>>>             Hello everyone,
>>>>>
>>>>>             I wanted to submit a new element user_friendly_description
>>>>>             in the VariableType of oval-variables-schema.xsd:
>>>>>
>>>>>             --------
>>>>>
>>>>>             <xsd:element name="user_friendly_description"
>>>>>             type="xsd:string" minOccurs="0" maxOccurs="1">
>>>>>
>>>>>                               <xsd:annotation>
>>>>>
>>>>> <xsd:documentation>Note that the
>>>>>             user_friendly_description is used by OVAL evaluation
>>>>> visual
>>>>>             tools to provide a visual text to the user to ensure
>>>>> that he
>>>>>             understands what the variable describes. Then he will be
>>>>>             able to provide the external variable value that will be
>>>>>             used by the tool to evaluate the
>>>>> definition.</xsd:documentation>
>>>>>
>>>>>                               </xsd:annotation>
>>>>>
>>>>>                          </xsd:element>
>>>>>
>>>>>             --------
>>>>>
>>>>>             That element will be used by the OVAL evaluators that
>>>>> have a
>>>>>             GUI to provide a visual text to the user. For example
>>>>> if the
>>>>>             variable is used to give the failename that will be
>>>>> checked
>>>>>             against something theuser_friendly_description could say
>>>>>             “This is the filename of the file that contains x”.
>>>>>
>>>>>             What I envision is using an external variable file to be
>>>>>             imported in an automated evaluation tool. That automated
>>>>>             tool will show the field that needs its value populated in
>>>>>             the external variables and it will show a text to the user
>>>>>             based on the new element. So, the user can see what these
>>>>>             variables are. After populating them in the GUI the tool
>>>>>             will generate the external variable file to be run with
>>>>>             OVAL. That way you have a visual way to tell the user
>>>>> how to
>>>>>             populate the external variables and he doesn’t need to go
>>>>>             update the xml directly and mess things up.
>>>>>
>>>>>             we can’t enforce that the author will write the
>>>>> explanation
>>>>>             using the user_friendly_description. But we can enforce
>>>>> that
>>>>>             the tool will show what the author wants when he wants it.
>>>>>             We could have the tool to show the“comment” in the
>>>>> variable
>>>>>             instead, but the comment is used in many places and
>>>>> authors
>>>>>             could use it for many other reasons. So, the new
>>>>> element is
>>>>>             practically for the tool. Authors will still leave it
>>>>> out if
>>>>>             they want to, but if it is in there then the tool
>>>>> definitely
>>>>>             knows what is it there for, for the user’s benefit and it
>>>>>             will show it in the GUI.
>>>>>
>>>>>             What does the community think? Would it be beneficial
>>>>> to add
>>>>>             it in the oval-variables-schema.xsd schema?
>>>>>
>>>>>             Rgs,
>>>>>
>>>>>             Panos
>>>>>
>>>>>             To unsubscribe, send an email message to
>>>>> [hidden email]
>>>>> <mailto:[hidden email]> with SIGNOFF
>>>>>             OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>>> have
>>>>>             difficulties, write to
>>>>> [hidden email]
>>>>> <mailto:[hidden email]>.
>>>>>
>>>>>         --
>>>>>
>>>>>         jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
>>>>>         /Scan any machine from any machine. For free!/
>>>>>         Learn More <http://www.joval.org> | Features
>>>>> <http://www.joval.org/features/> | Download
>>>>> <http://www.joval.org/download/>
>>>>>
>>>>>         To unsubscribe, send an email message to
>>>>> [hidden email] <mailto:[hidden email]> with
>>>>>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>>>         have difficulties, write to
>>>>> [hidden email]
>>>>> <mailto:[hidden email]>.
>>>>>
>>>>>         To unsubscribe, send an email message to
>>>>> [hidden email] <mailto:[hidden email]> with
>>>>>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>>>         have difficulties, write to
>>>>> [hidden email]
>>>>> <mailto:[hidden email]>.
>>>>>
>>>>>     --
>>>>>
>>>>>     jOVAL.org: OVAL implemented in Java.
>>>>>     /Scan any machine from any machine. For free!/
>>>>>     Learn More <http://www.joval.org> | Features
>>>>> <http://www.joval.org/features/> | Download
>>>>> <http://www.joval.org/download/>
>>>>>
>>>>>     To unsubscribe, send an email message to [hidden email]
>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST
>>>>>     in the BODY of the message. If you have difficulties, write to
>>>>> [hidden email]
>>>>> <mailto:[hidden email]>.
>>>>>
>>>>>     To unsubscribe, send an email message to [hidden email]
>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST
>>>>>     in the BODY of the message. If you have difficulties, write to
>>>>> [hidden email]
>>>>> <mailto:[hidden email]>.
>>>>>
>>>>> To unsubscribe, send an email message to [hidden email]
>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST in
>>>>> the BODY of the message. If you have difficulties, write to
>>>>> [hidden email]
>>>>> <mailto:[hidden email]>.
>>>>>
>>>>> --
>>>>>
>>>>> jOVAL.org: OVAL implemented in Java.
>>>>> /Scan any machine from any machine. For free!/
>>>>> Learn More <http://www.joval.org> | Features
>>>>> <http://www.joval.org/features/> | Download
>>>>> <http://www.joval.org/download/>
>>>>>
>>>>> To unsubscribe, send an email message to [hidden email]
>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-LIST in
>>>>> the BODY of the message. If you have difficulties, write to
>>>>> [hidden email]
>>>>> <mailto:[hidden email]>.
>>>>>
>>>>> To unsubscribe, send an email message to [hidden email] with
>>>>> SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>>>> difficulties, write to [hidden email].
>>>>
>>>> To unsubscribe, send an email message to [hidden email] with
>>>> SIGNOFF OVAL-DEVELOPER-LIST
>>>> in the BODY of the message.  If you have difficulties, write to
>>>> [hidden email].
>>>
>>>
>>> --
>>>
>>> jOVAL.org: OVAL implemented in Java.
>>> /Scan any machine from any machine. For free!/
>>> Learn More <http://www.joval.org> | Features
>>> <http://www.joval.org/features/> | Download
>>> <http://www.joval.org/download/>
>>>
>>
>> To unsubscribe, send an email message to [hidden email] with
>> SIGNOFF OVAL-DEVELOPER-LIST
>> in the BODY of the message.  If you have difficulties, write to
>> [hidden email].
>
>
> --
>
> jOVAL.org: OVAL implemented in Java.
> /Scan any machine from any machine. For free!/
> Learn More <http://www.joval.org> | Features
> <http://www.joval.org/features/> | Download
> <http://www.joval.org/download/>
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

joval
My take on Danny's suggestion was that we could add support for annotations for the external variable definitions, which one could then leverage however one saw fit -- with Panos's use-case being one such possibility.

In general, then, I think we actually agree: OCIL is SCAP's way of interrogating people, and we should endeavor to leverage it for that purpose!

On 9/12/2012 3:46 PM, Gunnar Engelbach wrote:
That's all possible if what Panos is requesting represents the very rare and closed-loop case.  But since Danny is talking about extending the schema it sounds as if he's trying to offer a more broadly usable solution.

To that end, I think that changes necessary to enable using the user as a data source should be done in the standard meant to do user interaction:  OCIL.  Most of side affects of processing user input has already been thought out there.  Additionally, since it is not yet widely used, schema changes will not have as much of an impact.

On the other hand, if the view is that OVAL should be capable of covering more use cases as a standalone, then Danny's suggestion is the simplest way to get there (and could have some utility outside of this specific usage) -- with the caveat that it doesn't allow for type checking, response validation, etc, without some further changes.



On 9/12/2012 3:06 PM, David Solin wrote:
It is that simple.  OCIL results actually spell out the answer value
under the xpath:
/ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer

The value of the entity is the actual answer value, including (if
applicable) a resolved variable value.

Now, assuming you have control

On 9/12/2012 1:37 PM, Gunnar Engelbach wrote:
On 9/12/2012 2:15 PM, David Solin wrote:
Hi Gunnar,

I think you should be able to get an answer /value/ from OCIL into XCCDF
using a variable import.  In fact, IIRC, imports can take the form of
generic XPATH queries -- so there would be no problem grabbing a value.


Not really that simple.

First, because processing the <question_results> section of an OCIL
report using XPATH is outside of any of the standards.  In other
words, there isn't a mechanism within any of the standards to get a
user-input value from OCIL to XCCDF or OVAL.

Sure there is.

http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf

Section 6.4.4.4. <xccdf:check> check-import element is described:

"Identifies a value to be retrieved from the checking system during
testing of a target system. This element MUST be empty. After the
associated check results have been collected, the result structure
returned by the checking engine is processed to collect the named
information. This information is then recorded in the
<xccdf:check-import> element in the corresponding <xccdf:rule-result>.
This could be a single value or structured XML. In the latter case, the
@import-xpath attribute can be used to traverse the structured XML and
identify specific information of interest to record in the result."

If the question is a string_question, then the XPATH expression:
/ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer

... will be populated with the user's actual response.

Map the import to a value, and the value to an export and... Voila. A
value is passed as output from one check system and into another.


Second, the user response won't necessarily be recorded as a raw
value, but might in fact be a reference to one of the possible values
enumerated by the question.


One can manipulate that data, of course, but aren't we are assuming that
this hypothetical OCIL was authored intentionally to collect variable
values?


Try to bolt extended functionality onto OVAL doesn't make sense to me
and just makes it needlessly more complicated.  Instead it makes more
sense to take advantage of OCIL as a complimentary standard whose
designed purpose is human interaction.


SCAP is the wrong place to avoid needless complexity! ;)

I agree that a purpose-built tool could be less cumbersome, but that's
almost invariably the case with purpose-built tools, for obvious reasons.

The one thing that's truly unspecified is whether it's legal to chain
import and export relationships.  This would have potentially very
complicated implications on the order in which checks must be executed.
The existing XCCDF interpreters I've worked with that support OCIL
(those are, jOVAL XPERT and the reference XCCDF interpreter --
xccdfexec) both evaluate OCIL first, then OVAL.





Regarding Danny's proposal, anyway, I have no objection at all.

Cheers,
--David

On 9/12/2012 11:52 AM, Gunnar Engelbach wrote:
I have to wonder, is such an open-ended ability really what Panos
needs?  In other words, does he really need the ability to adjust the
value for each possible test across the full range of what is legal
for that value?  Or will the expected usage tend to be more like a
particular state as defined by differing but static sets of values?
If the latter, then using XCCDF as the front end with multiple
profiles to define the variable values would be considerably easier
from a user standpoint.

The suggestion to use OCIL as a front end for this seems like a more
reasonable starting point.  OCIL was designed with the intent for
human interaction so I would expect it to be a more natural starting
point for getting response values from a human.  One important
consideration, for example, is that using explanatory notes doesn't
provide for a programmatic way to ensure that user input is valid for
each variable, which is something that OCIL does provide. What OCIL
lacks right now is the ability to return the value of a question
rather than the test result of a question.


 --gun


On 9/12/2012 12:34 PM, Haynes, Dan wrote:
I was re-reading this thread and I think that there may be a generic
OVAL-only solution for this.  Specifically, the oval-def:NotesType
which
has the following documentation (see Section 4.3.7 of the OVAL
Language
Specification):

   “The NotesType is a container for one or more notes, providing
additional information, such as unresolved questions, reasons for
specific implementation, or other documentation.”

The oval-def:NotesType construct is currently available to content
authors for use in definitions, tests, objects, and states. It is not
currently supported in oval-def:external_variable,
oval-def:constant_variable, oval-def:local_variable, or
oval-var:variable.  I looked around and I couldn’t find a specific
reason as to why the oval-def:NotesType construct was not included in
the various variable constructs.  I think it was just something
that we
overlooked because there seemed to be consensus during the development
of OVAL 5.0 that notes should be extended to tests, objects, states,
etc. (see
http://making-security-measurable.1364806.n2.nabble.com/OVAL-Metadata-tp22526.html).


If we added support for it, using Panos’ example, a variable in an
OVAL
Variable document might look like the following.

   <variable id="oval:sample:var:1" datatype="string" comment="This
variable holds the filename that contains x.">

     <notes>

       <note>This is the filename of the file that contains x.</note>

       <note>You can identify this file by taking the following steps:
…</note>

       …

     </notes>

     <value>file.txt</value>

   </variable>

A tool could then take the information contained in the notes and
present it to the user.  Or, even better, a tool might look for the
notes in the oval-def:external_variables, in the OVAL Definitions
document, and could generate any number of formats (OVAL Variables,
XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
course, all of this would be optional and it would be up to the
content
author to put the notes in a location where the tool is expecting
them.

As for the schema, I think we could just pull the
oval-def:NotesType up
into the oval-common-schema.xsd.  From there, it could be used in both
the oval-definitions-schema.xsd and the oval-variables-schema.xsd.

Does this seem like it would be a reasonable solution?

Thanks,

Danny

*From:*David Solin [[hidden email]]
*Sent:* Monday, August 27, 2012 4:12 PM
*To:* oval-developer-list OVAL Developer List/Closed Public Discussion
*Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
oval-variables-schema.xsd?

The variables schema is independent of the definitions schemas. It's
simply a means of feeding external variable values to an interpreter.

Panos wanted to use this schema for some other purpose -- to work
with a
tool that would collect values.  Luis was just pointing out that SCAP
actually has a way to do this exact thing, in an intended way.

XML is flexible.  If one wanted to decorate a variables file with
other
information, it could be defined in a different schema, with its own
namespace, and simply added to the document.  An OVAL interpreter
expecting a variables schema could safely ignore the extra data.
Alternatively, the tool could use its own format, and generate a
schema-conforming variables document to feed into the OVAL interpreter
-- which is exactly what the variables format is intended to do.

That's the issue I had with Panos's request.  I hope my reasoning
makes
sense!

Regards,
--David

On 8/27/2012 11:43 AM, Robert Huffman wrote:

As an OVAL novice, I was thinking Pano's idea was already supported by
OVAL using the comment element of a variable. However, the real
problem
is that the variables section does not need to be included in the OVAL
document.

So, what if you simply allowed the inclusion of external_variable
elements within an OVAL document without the value? Currently, the
value
is  required. If it was optional, then an OVAL author could include
the
external_variable and use the comment element to provide guidance to
tools that could collect input from the user.

Using OCIL to collect values may be a decent idea, but that should be
left up to vendors. Someone should be able to write a standalone OVAL
tool without implementing OCIL. Just provide a mechanism for providing
guidance about the meaning of an external variable within OVAL itself.

On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
<[hidden email] [hidden email]> wrote:

    Luis’ idea is fine by me.

    So, you are saying OCIL could be used with questionnaires to
    generate OCIL results and then jOval XPERT can be enhanced to
    generate the external variables from the OCI results?.

    Is there a transition mechanism between OCIL output and OVAL
    external variable files or is it practically up to the implementer
    to perform the task?

    Panos

    *From:*David Solin [[hidden email]
[hidden email]]
    *Sent:* Tuesday, August 07, 2012 10:29 AM
    *To:* [hidden email]
[hidden email]


    *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
VariableType of
    oval-variables-schema.xsd?

    I only have experience with two products that make use of the OVAL
    variables file: ovaldi and jOVAL.  Both take the external
variables
    file as input for processing OVAL definitions. What makes an
    external variable "external" is that its value is not defined
in the
    OVAL definitions document.  The specification doesn't say anything
    about querying users for values.  That kind of function is, in my
    mind, external to OVAL.

    Now, Luis makes a great point -- there is a standard in the SCAP
    specification (OCIL) that is designed to be used to ask people
    questions.  Furthermore, XCCDF has the capability to define both
    variable imports and exports.  It would be fairly easy to
import an
    answer from an OCIL question result.

    Currently, XPERT only supports imports from SCE scripts, but it
can
    produce OVAL variables file format documents encapsulating exports
    from the XCCDF document to the OVAL system.  It also handles
    importing OCIL results files.  So, with just a bit of extra
work to
    support OCIL imports, you could do exactly what Luis proposes.

    Regards,
    --David Solin

    On 8/7/2012 8:44 AM, Luis Nunez wrote:

        Can we use OCIL to generate external variables for OVAL?
If can
        define the right questions to ask maybe OCIL could be the UI?

        -ln

        On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:

        Thanks David.

        So, what is the tool that today collects external variables? I
        don’t know of any.

        What I was thinking was that an evaluator that checks for an
        oval def with an external variable certainly takes the
external
        variable as its input. Now, if that external variable needs to
        be adjusted for my system I need to go in the external
variable
        file and edit the values that I need to edit. And it is more
        likely that the external variable file will be provided as a
        template with the def, I don’t expect the user that will
use the
        evaluator tool to write the external variable file from
scratch.

        So, if my thinking is right and the external variable file
goes
        with the oval def, then wouldn’t it make sense to have a field
        that a GUI could use in order to take the external variable
        template file for the oval def and present to the user the
        fields he needs to populate and what they are?

         > Given the above, couldn't you use a different format to
feed
        such questions into a collection UI?  That tool would
generate a
        variables file, but it certainly doesn't need to consume one.

        Doesn’t the OVAL author write the oval code and the external
        variables he will use, that need to be adjusted on a
per-system
        basis? Having the oval author provide one more format to
define
        what the external variables needed are, I think, is more
        complicated that what I am proposing.

        BTW, has a format/schema or something been considered
before for
        the external variable collection? Or has it always been
assumed
        that external variables are provided somehow?

        Rgs,

        Panos

        *From:* David Solin [[hidden email]] *On
        Behalf Of *David Solin
        *Sent:* Tuesday, August 07, 2012 12:29 AM
        *To:* OVAL Developer List (Closed Public Discussion)
        *Cc:* Panos Kampanakis (pkampana)
        *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
VariableType
        of oval-variables-schema.xsd?

        Hi Panos,

        The purpose of the variables schema is to transmit external
        variable values to an OVAL interpreter, not to collect those
        values.  I assume that collecting those values is the job of
        some other tool, that need not be restricted by the schema,
and
        which is potentially outside the scope of the OVAL standards.

        Given the above, couldn't you use a different format to feed
        such questions into a collection UI?  That tool would
generate a
        variables file, but it certainly doesn't need to consume one.
        Or do you really think we need to expand the scope of the
        external variables document to include collection of the
values?

        Regards,
        --David Solin

        On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

            Hello everyone,

            I wanted to submit a new element user_friendly_description
            in the VariableType of oval-variables-schema.xsd:

            --------

            <xsd:element name="user_friendly_description"
            type="xsd:string" minOccurs="0" maxOccurs="1">

                              <xsd:annotation>

<xsd:documentation>Note that the
            user_friendly_description is used by OVAL evaluation
visual
            tools to provide a visual text to the user to ensure
that he
            understands what the variable describes. Then he will be
            able to provide the external variable value that will be
            used by the tool to evaluate the
definition.</xsd:documentation>

                              </xsd:annotation>

                         </xsd:element>

            --------

            That element will be used by the OVAL evaluators that
have a
            GUI to provide a visual text to the user. For example
if the
            variable is used to give the failename that will be
checked
            against something theuser_friendly_description could say
            “This is the filename of the file that contains x”.

            What I envision is using an external variable file to be
            imported in an automated evaluation tool. That automated
            tool will show the field that needs its value populated in
            the external variables and it will show a text to the user
            based on the new element. So, the user can see what these
            variables are. After populating them in the GUI the tool
            will generate the external variable file to be run with
            OVAL. That way you have a visual way to tell the user
how to
            populate the external variables and he doesn’t need to go
            update the xml directly and mess things up.

            we can’t enforce that the author will write the
explanation
            using the user_friendly_description. But we can enforce
that
            the tool will show what the author wants when he wants it.
            We could have the tool to show the“comment” in the
variable
            instead, but the comment is used in many places and
authors
            could use it for many other reasons. So, the new
element is
            practically for the tool. Authors will still leave it
out if
            they want to, but if it is in there then the tool
definitely
            knows what is it there for, for the user’s benefit and it
            will show it in the GUI.

            What does the community think? Would it be beneficial
to add
            it in the oval-variables-schema.xsd schema?

            Rgs,

            Panos

            To unsubscribe, send an email message to
[hidden email]
[hidden email] with SIGNOFF
            OVAL-DEVELOPER-LIST in the BODY of the message. If you
have
            difficulties, write to
[hidden email]
[hidden email].

        --

        jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
        /Scan any machine from any machine. For free!/
        Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

        To unsubscribe, send an email message to
[hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
[hidden email]
[hidden email].

        To unsubscribe, send an email message to
[hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
[hidden email]
[hidden email].

    --

    jOVAL.org: OVAL implemented in Java.
    /Scan any machine from any machine. For free!/
    Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

    To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

    To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].


--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>


To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].


--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>


To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].


--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write 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: New element in VariableType of oval-variables-schema.xsd?

Ruben Oliva
In reply to this post by Panos Kampanakis (pkampana)
 
 David:
 
I am kind of tracking new uses of OCIL.
In noticing how you suggest this new use one question comes to mind.
 
In my thinking, the use of OCIL with XCCDF is one in which perhaps sequential processes can be supported.
OCIL in association with OVAL is perhaps one for non-sequential processes.
 
But these are two are not necessarily mutually exclusive.
 
Does this sound correct?
 
 
David Oliva
 
On 09/13/12, David Solin<[hidden email]> wrote:
 
My take on Danny's suggestion was that we could add support for annotations for the external variable definitions, which one could then leverage however one saw fit -- with Panos's use-case being one such possibility.

In general, then, I think we actually agree: OCIL is SCAP's way of interrogating people, and we should endeavor to leverage it for that purpose!

On 9/12/2012 3:46 PM, Gunnar Engelbach wrote:
That's all possible if what Panos is requesting represents the very rare and closed-loop case.  But since Danny is talking about extending the schema it sounds as if he's trying to offer a more broadly usable solution.

To that end, I think that changes necessary to enable using the user as a data source should be done in the standard meant to do user interaction:  OCIL.  Most of side affects of processing user input has already been thought out there.  Additionally, since it is not yet widely used, schema changes will not have as much of an impact.

On the other hand, if the view is that OVAL should be capable of covering more use cases as a standalone, then Danny's suggestion is the simplest way to get there (and could have some utility outside of this specific usage) -- with the caveat that it doesn't allow for type checking, response validation, etc, without some further changes.



On 9/12/2012 3:06 PM, David Solin wrote:
It is that simple.  OCIL results actually spell out the answer value
under the xpath:
/ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer

The value of the entity is the actual answer value, including (if
applicable) a resolved variable value.

Now, assuming you have control

On 9/12/2012 1:37 PM, Gunnar Engelbach wrote:
On 9/12/2012 2:15 PM, David Solin wrote:
Hi Gunnar,

I think you should be able to get an answer /value/ from OCIL into XCCDF
using a variable import.  In fact, IIRC, imports can take the form of
generic XPATH queries -- so there would be no problem grabbing a value.


Not really that simple.

First, because processing the <question_results> section of an OCIL
report using XPATH is outside of any of the standards.  In other
words, there isn't a mechanism within any of the standards to get a
user-input value from OCIL to XCCDF or OVAL.

Sure there is.

http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf

Section 6.4.4.4. <xccdf:check> check-import element is described:

"Identifies a value to be retrieved from the checking system during
testing of a target system. This element MUST be empty. After the
associated check results have been collected, the result structure
returned by the checking engine is processed to collect the named
information. This information is then recorded in the
<xccdf:check-import> element in the corresponding <xccdf:rule-result>.
This could be a single value or structured XML. In the latter case, the
@import-xpath attribute can be used to traverse the structured XML and
identify specific information of interest to record in the result."

If the question is a string_question, then the XPATH expression:
/ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer

... will be populated with the user's actual response.

Map the import to a value, and the value to an export and... Voila. A
value is passed as output from one check system and into another.


Second, the user response won't necessarily be recorded as a raw
value, but might in fact be a reference to one of the possible values
enumerated by the question.


One can manipulate that data, of course, but aren't we are assuming that
this hypothetical OCIL was authored intentionally to collect variable
values?


Try to bolt extended functionality onto OVAL doesn't make sense to me
and just makes it needlessly more complicated.  Instead it makes more
sense to take advantage of OCIL as a complimentary standard whose
designed purpose is human interaction.


SCAP is the wrong place to avoid needless complexity! ;)

I agree that a purpose-built tool could be less cumbersome, but that's
almost invariably the case with purpose-built tools, for obvious reasons.

The one thing that's truly unspecified is whether it's legal to chain
import and export relationships.  This would have potentially very
complicated implications on the order in which checks must be executed.
The existing XCCDF interpreters I've worked with that support OCIL
(those are, jOVAL XPERT and the reference XCCDF interpreter --
xccdfexec) both evaluate OCIL first, then OVAL.





Regarding Danny's proposal, anyway, I have no objection at all.

Cheers,
--David

On 9/12/2012 11:52 AM, Gunnar Engelbach wrote:
I have to wonder, is such an open-ended ability really what Panos
needs?  In other words, does he really need the ability to adjust the
value for each possible test across the full range of what is legal
for that value?  Or will the expected usage tend to be more like a
particular state as defined by differing but static sets of values?
If the latter, then using XCCDF as the front end with multiple
profiles to define the variable values would be considerably easier
from a user standpoint.

The suggestion to use OCIL as a front end for this seems like a more
reasonable starting point.  OCIL was designed with the intent for
human interaction so I would expect it to be a more natural starting
point for getting response values from a human.  One important
consideration, for example, is that using explanatory notes doesn't
provide for a programmatic way to ensure that user input is valid for
each variable, which is something that OCIL does provide. What OCIL
lacks right now is the ability to return the value of a question
rather than the test result of a question.


 --gun


On 9/12/2012 12:34 PM, Haynes, Dan wrote:
I was re-reading this thread and I think that there may be a generic
OVAL-only solution for this.  Specifically, the oval-def:NotesType
which
has the following documentation (see Section 4.3.7 of the OVAL
Language
Specification):

   “The NotesType is a container for one or more notes, providing
additional information, such as unresolved questions, reasons for
specific implementation, or other documentation.”

The oval-def:NotesType construct is currently available to content
authors for use in definitions, tests, objects, and states. It is not
currently supported in oval-def:external_variable,
oval-def:constant_variable, oval-def:local_variable, or
oval-var:variable.  I looked around and I couldn’t find a specific
reason as to why the oval-def:NotesType construct was not included in
the various variable constructs.  I think it was just something
that we
overlooked because there seemed to be consensus during the development
of OVAL 5.0 that notes should be extended to tests, objects, states,
etc. (see
http://making-security-measurable.1364806.n2.nabble.com/OVAL-Metadata-tp22526.html).


If we added support for it, using Panos’ example, a variable in an
OVAL
Variable document might look like the following.

   <variable id="oval:sample:var:1" datatype="string" comment="This
variable holds the filename that contains x.">

     <notes>

       <note>This is the filename of the file that contains x.</note>

       <note>You can identify this file by taking the following steps:
…</note>

       …

     </notes>

     <value>file.txt</value>

   </variable>

A tool could then take the information contained in the notes and
present it to the user.  Or, even better, a tool might look for the
notes in the oval-def:external_variables, in the OVAL Definitions
document, and could generate any number of formats (OVAL Variables,
XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
course, all of this would be optional and it would be up to the
content
author to put the notes in a location where the tool is expecting
them.

As for the schema, I think we could just pull the
oval-def:NotesType up
into the oval-common-schema.xsd.  From there, it could be used in both
the oval-definitions-schema.xsd and the oval-variables-schema.xsd.

Does this seem like it would be a reasonable solution?

Thanks,

Danny

*From:*David Solin [[hidden email]]
*Sent:* Monday, August 27, 2012 4:12 PM
*To:* oval-developer-list OVAL Developer List/Closed Public Discussion
*Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
oval-variables-schema.xsd?

The variables schema is independent of the definitions schemas. It's
simply a means of feeding external variable values to an interpreter.

Panos wanted to use this schema for some other purpose -- to work
with a
tool that would collect values.  Luis was just pointing out that SCAP
actually has a way to do this exact thing, in an intended way.

XML is flexible.  If one wanted to decorate a variables file with
other
information, it could be defined in a different schema, with its own
namespace, and simply added to the document.  An OVAL interpreter
expecting a variables schema could safely ignore the extra data.
Alternatively, the tool could use its own format, and generate a
schema-conforming variables document to feed into the OVAL interpreter
-- which is exactly what the variables format is intended to do.

That's the issue I had with Panos's request.  I hope my reasoning
makes
sense!

Regards,
--David

On 8/27/2012 11:43 AM, Robert Huffman wrote:

As an OVAL novice, I was thinking Pano's idea was already supported by
OVAL using the comment element of a variable. However, the real
problem
is that the variables section does not need to be included in the OVAL
document.

So, what if you simply allowed the inclusion of external_variable
elements within an OVAL document without the value? Currently, the
value
is  required. If it was optional, then an OVAL author could include
the
external_variable and use the comment element to provide guidance to
tools that could collect input from the user.

Using OCIL to collect values may be a decent idea, but that should be
left up to vendors. Someone should be able to write a standalone OVAL
tool without implementing OCIL. Just provide a mechanism for providing
guidance about the meaning of an external variable within OVAL itself.

On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
<[hidden email] [hidden email]> wrote:

    Luis’ idea is fine by me.

    So, you are saying OCIL could be used with questionnaires to
    generate OCIL results and then jOval XPERT can be enhanced to
    generate the external variables from the OCI results?.

    Is there a transition mechanism between OCIL output and OVAL
    external variable files or is it practically up to the implementer
    to perform the task?

    Panos

    *From:*David Solin [[hidden email]
[hidden email]]
    *Sent:* Tuesday, August 07, 2012 10:29 AM
    *To:* [hidden email]
[hidden email]


    *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
VariableType of
    oval-variables-schema.xsd?

    I only have experience with two products that make use of the OVAL
    variables file: ovaldi and jOVAL.  Both take the external
variables
    file as input for processing OVAL definitions. What makes an
    external variable "external" is that its value is not defined
in the
    OVAL definitions document.  The specification doesn't say anything
    about querying users for values.  That kind of function is, in my
    mind, external to OVAL.

    Now, Luis makes a great point -- there is a standard in the SCAP
    specification (OCIL) that is designed to be used to ask people
    questions.  Furthermore, XCCDF has the capability to define both
    variable imports and exports.  It would be fairly easy to
import an
    answer from an OCIL question result.

    Currently, XPERT only supports imports from SCE scripts, but it
can
    produce OVAL variables file format documents encapsulating exports
    from the XCCDF document to the OVAL system.  It also handles
    importing OCIL results files.  So, with just a bit of extra
work to
    support OCIL imports, you could do exactly what Luis proposes.

    Regards,
    --David Solin

    On 8/7/2012 8:44 AM, Luis Nunez wrote:

        Can we use OCIL to generate external variables for OVAL?
If can
        define the right questions to ask maybe OCIL could be the UI?

        -ln

        On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:

        Thanks David.

        So, what is the tool that today collects external variables? I
        don’t know of any.

        What I was thinking was that an evaluator that checks for an
        oval def with an external variable certainly takes the
external
        variable as its input. Now, if that external variable needs to
        be adjusted for my system I need to go in the external
variable
        file and edit the values that I need to edit. And it is more
        likely that the external variable file will be provided as a
        template with the def, I don’t expect the user that will
use the
        evaluator tool to write the external variable file from
scratch.

        So, if my thinking is right and the external variable file
goes
        with the oval def, then wouldn’t it make sense to have a field
        that a GUI could use in order to take the external variable
        template file for the oval def and present to the user the
        fields he needs to populate and what they are?

         > Given the above, couldn't you use a different format to
feed
        such questions into a collection UI?  That tool would
generate a
        variables file, but it certainly doesn't need to consume one.

        Doesn’t the OVAL author write the oval code and the external
        variables he will use, that need to be adjusted on a
per-system
        basis? Having the oval author provide one more format to
define
        what the external variables needed are, I think, is more
        complicated that what I am proposing.

        BTW, has a format/schema or something been considered
before for
        the external variable collection? Or has it always been
assumed
        that external variables are provided somehow?

        Rgs,

        Panos

        *From:* David Solin [[hidden email]] *On
        Behalf Of *David Solin
        *Sent:* Tuesday, August 07, 2012 12:29 AM
        *To:* OVAL Developer List (Closed Public Discussion)
        *Cc:* Panos Kampanakis (pkampana)
        *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
VariableType
        of oval-variables-schema.xsd?

        Hi Panos,

        The purpose of the variables schema is to transmit external
        variable values to an OVAL interpreter, not to collect those
        values.  I assume that collecting those values is the job of
        some other tool, that need not be restricted by the schema,
and
        which is potentially outside the scope of the OVAL standards.

        Given the above, couldn't you use a different format to feed
        such questions into a collection UI?  That tool would
generate a
        variables file, but it certainly doesn't need to consume one.
        Or do you really think we need to expand the scope of the
        external variables document to include collection of the
values?

        Regards,
        --David Solin

        On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

            Hello everyone,

            I wanted to submit a new element user_friendly_description
            in the VariableType of oval-variables-schema.xsd:

            --------

            <xsd:element name="user_friendly_description"
            type="xsd:string" minOccurs="0" maxOccurs="1">

                              <xsd:annotation>

<xsd:documentation>Note that the
            user_friendly_description is used by OVAL evaluation
visual
            tools to provide a visual text to the user to ensure
that he
            understands what the variable describes. Then he will be
            able to provide the external variable value that will be
            used by the tool to evaluate the
definition.</xsd:documentation>

                              </xsd:annotation>

                         </xsd:element>

            --------

            That element will be used by the OVAL evaluators that
have a
            GUI to provide a visual text to the user. For example
if the
            variable is used to give the failename that will be
checked
            against something theuser_friendly_description could say
            “This is the filename of the file that contains x”.

            What I envision is using an external variable file to be
            imported in an automated evaluation tool. That automated
            tool will show the field that needs its value populated in
            the external variables and it will show a text to the user
            based on the new element. So, the user can see what these
            variables are. After populating them in the GUI the tool
            will generate the external variable file to be run with
            OVAL. That way you have a visual way to tell the user
how to
            populate the external variables and he doesn’t need to go
            update the xml directly and mess things up.

            we can’t enforce that the author will write the
explanation
            using the user_friendly_description. But we can enforce
that
            the tool will show what the author wants when he wants it.
            We could have the tool to show the“comment” in the
variable
            instead, but the comment is used in many places and
authors
            could use it for many other reasons. So, the new
element is
            practically for the tool. Authors will still leave it
out if
            they want to, but if it is in there then the tool
definitely
            knows what is it there for, for the user’s benefit and it
            will show it in the GUI.

            What does the community think? Would it be beneficial
to add
            it in the oval-variables-schema.xsd schema?

            Rgs,

            Panos

            To unsubscribe, send an email message to
[hidden email]
[hidden email] with SIGNOFF
            OVAL-DEVELOPER-LIST in the BODY of the message. If you
have
            difficulties, write to
[hidden email]
[hidden email].

        --

        jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
        /Scan any machine from any machine. For free!/
        Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

        To unsubscribe, send an email message to
[hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
[hidden email]
[hidden email].

        To unsubscribe, send an email message to
[hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
[hidden email]
[hidden email].

    --

    jOVAL.org: OVAL implemented in Java.
    /Scan any machine from any machine. For free!/
    Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

    To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

    To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].


--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>


To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].


--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>


To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].


--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

Danny Haynes
Administrator
In reply to this post by Gunnar Engelbach
Hi Gunnar,

>That's all possible if what Panos is requesting represents the very rare
>and closed-loop case.  But since Danny is talking about extending the
>schema it sounds as if he's trying to offer a more broadly usable solution.

The way I interpreted Panos' request (let me know if I am way off ;)) was that he just needed a place to put additional information that would help the user know what to put there, but, he didn't really like the idea of using comments because they might be leveraged for something else (maybe notes from the person who created the content?).  Yes, this would be a more broad solution that could be used to satisfy Panos' use case or possibly someone else's.

>To that end, I think that changes necessary to enable using the user as
>a data source should be done in the standard meant to do user
>interaction:  OCIL.  Most of side affects of processing user input has
>already been thought out there.  Additionally, since it is not yet
>widely used, schema changes will not have as much of an impact.

I agree that this is a valid use case for OCIL.

>On the other hand, if the view is that OVAL should be capable of
>covering more use cases as a standalone, then Danny's suggestion is the
>simplest way to get there (and could have some utility outside of this
>specific usage) -- with the caveat that it doesn't allow for type
>checking, response validation, etc, without some further changes.

I saw this solution as a way to address Panos' needs without adding something use-case specific to OVAL that may not be needed by everyone.  With this solution, a content author can decide how they want to use the NotesType (if at all).  For what it's worth, I think if I realized that the NotesType construct was available on all the major constructs except for variables, even before this use case, I would probably suggest that we add it to variables to make these language constructs more consistent and give content authors more flexibility.

Regarding type checking, response validation, etc., this is more something to think about, but, if a tool was looking at the external_variables to figure out what to display to a user (using notes), a tool might also be able to leverage the other information in the external_variable (datatype attribute, possible_value and possible_restriction constructs) to do some type checking and input validation.

Thanks,

Danny

>On 9/12/2012 3:06 PM, David Solin wrote:
>> It is that simple.  OCIL results actually spell out the answer value
>> under the xpath:
>>
>/ocil/results/question_results/question_result[@question_ref="ocil:identifier
>"]/answer
>>
>> The value of the entity is the actual answer value, including (if
>> applicable) a resolved variable value.
>>
>> Now, assuming you have control
>>
>> On 9/12/2012 1:37 PM, Gunnar Engelbach wrote:
>>> On 9/12/2012 2:15 PM, David Solin wrote:
>>>> Hi Gunnar,
>>>>
>>>> I think you should be able to get an answer /value/ from OCIL into XCCDF
>>>> using a variable import.  In fact, IIRC, imports can take the form of
>>>> generic XPATH queries -- so there would be no problem grabbing a value.
>>>
>>>
>>> Not really that simple.
>>>
>>> First, because processing the <question_results> section of an OCIL
>>> report using XPATH is outside of any of the standards.  In other
>>> words, there isn't a mechanism within any of the standards to get a
>>> user-input value from OCIL to XCCDF or OVAL.
>>
>> Sure there is.
>>
>> http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf
>>
>> Section 6.4.4.4. <xccdf:check> check-import element is described:
>>
>> "Identifies a value to be retrieved from the checking system during
>> testing of a target system. This element MUST be empty. After the
>> associated check results have been collected, the result structure
>> returned by the checking engine is processed to collect the named
>> information. This information is then recorded in the
>> <xccdf:check-import> element in the corresponding <xccdf:rule-result>.
>> This could be a single value or structured XML. In the latter case, the
>> @import-xpath attribute can be used to traverse the structured XML and
>> identify specific information of interest to record in the result."
>>
>> If the question is a string_question, then the XPATH expression:
>>
>/ocil/results/question_results/question_result[@question_ref="ocil:identifier
>"]/answer
>>
>> ... will be populated with the user's actual response.
>>
>> Map the import to a value, and the value to an export and... Voila. A
>> value is passed as output from one check system and into another.
>>
>>>
>>> Second, the user response won't necessarily be recorded as a raw
>>> value, but might in fact be a reference to one of the possible values
>>> enumerated by the question.
>>>
>>
>> One can manipulate that data, of course, but aren't we are assuming that
>> this hypothetical OCIL was authored intentionally to collect variable
>> values?
>>
>>>
>>> Try to bolt extended functionality onto OVAL doesn't make sense to me
>>> and just makes it needlessly more complicated.  Instead it makes more
>>> sense to take advantage of OCIL as a complimentary standard whose
>>> designed purpose is human interaction.
>>>
>>
>> SCAP is the wrong place to avoid needless complexity! ;)
>>
>> I agree that a purpose-built tool could be less cumbersome, but that's
>> almost invariably the case with purpose-built tools, for obvious reasons.
>>
>> The one thing that's truly unspecified is whether it's legal to chain
>> import and export relationships.  This would have potentially very
>> complicated implications on the order in which checks must be executed.
>> The existing XCCDF interpreters I've worked with that support OCIL
>> (those are, jOVAL XPERT and the reference XCCDF interpreter --
>> xccdfexec) both evaluate OCIL first, then OVAL.
>>
>>>
>>>
>>>
>>>>
>>>> Regarding Danny's proposal, anyway, I have no objection at all.
>>>>
>>>> Cheers,
>>>> --David
>>>>
>>>> On 9/12/2012 11:52 AM, Gunnar Engelbach wrote:
>>>>> I have to wonder, is such an open-ended ability really what Panos
>>>>> needs?  In other words, does he really need the ability to adjust the
>>>>> value for each possible test across the full range of what is legal
>>>>> for that value?  Or will the expected usage tend to be more like a
>>>>> particular state as defined by differing but static sets of values?
>>>>> If the latter, then using XCCDF as the front end with multiple
>>>>> profiles to define the variable values would be considerably easier
>>>>> from a user standpoint.
>>>>>
>>>>> The suggestion to use OCIL as a front end for this seems like a more
>>>>> reasonable starting point.  OCIL was designed with the intent for
>>>>> human interaction so I would expect it to be a more natural starting
>>>>> point for getting response values from a human.  One important
>>>>> consideration, for example, is that using explanatory notes doesn't
>>>>> provide for a programmatic way to ensure that user input is valid for
>>>>> each variable, which is something that OCIL does provide. What OCIL
>>>>> lacks right now is the ability to return the value of a question
>>>>> rather than the test result of a question.
>>>>>
>>>>>
>>>>>  --gun
>>>>>
>>>>>
>>>>> On 9/12/2012 12:34 PM, Haynes, Dan wrote:
>>>>>> I was re-reading this thread and I think that there may be a generic
>>>>>> OVAL-only solution for this.  Specifically, the oval-def:NotesType
>>>>>> which
>>>>>> has the following documentation (see Section 4.3.7 of the OVAL
>>>>>> Language
>>>>>> Specification):
>>>>>>
>>>>>>    "The NotesType is a container for one or more notes, providing
>>>>>> additional information, such as unresolved questions, reasons for
>>>>>> specific implementation, or other documentation."
>>>>>>
>>>>>> The oval-def:NotesType construct is currently available to content
>>>>>> authors for use in definitions, tests, objects, and states. It is not
>>>>>> currently supported in oval-def:external_variable,
>>>>>> oval-def:constant_variable, oval-def:local_variable, or
>>>>>> oval-var:variable.  I looked around and I couldn't find a specific
>>>>>> reason as to why the oval-def:NotesType construct was not included in
>>>>>> the various variable constructs.  I think it was just something
>>>>>> that we
>>>>>> overlooked because there seemed to be consensus during the
>development
>>>>>> of OVAL 5.0 that notes should be extended to tests, objects, states,
>>>>>> etc. (see
>>>>>> http://making-security-measurable.1364806.n2.nabble.com/OVAL-
>Metadata-tp22526.html).
>>>>>>
>>>>>>
>>>>>> If we added support for it, using Panos' example, a variable in an
>>>>>> OVAL
>>>>>> Variable document might look like the following.
>>>>>>
>>>>>>    <variable id="oval:sample:var:1" datatype="string" comment="This
>>>>>> variable holds the filename that contains x.">
>>>>>>
>>>>>>      <notes>
>>>>>>
>>>>>>        <note>This is the filename of the file that contains x.</note>
>>>>>>
>>>>>>        <note>You can identify this file by taking the following steps:
>>>>>> ...</note>
>>>>>>
>>>>>>        ...
>>>>>>
>>>>>>      </notes>
>>>>>>
>>>>>>      <value>file.txt</value>
>>>>>>
>>>>>>    </variable>
>>>>>>
>>>>>> A tool could then take the information contained in the notes and
>>>>>> present it to the user.  Or, even better, a tool might look for the
>>>>>> notes in the oval-def:external_variables, in the OVAL Definitions
>>>>>> document, and could generate any number of formats (OVAL Variables,
>>>>>> XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
>>>>>> course, all of this would be optional and it would be up to the
>>>>>> content
>>>>>> author to put the notes in a location where the tool is expecting
>>>>>> them.
>>>>>>
>>>>>> As for the schema, I think we could just pull the
>>>>>> oval-def:NotesType up
>>>>>> into the oval-common-schema.xsd.  From there, it could be used in
>both
>>>>>> the oval-definitions-schema.xsd and the oval-variables-schema.xsd.
>>>>>>
>>>>>> Does this seem like it would be a reasonable solution?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Danny
>>>>>>
>>>>>> *From:*David Solin [mailto:[hidden email]]
>>>>>> *Sent:* Monday, August 27, 2012 4:12 PM
>>>>>> *To:* oval-developer-list OVAL Developer List/Closed Public Discussion
>>>>>> *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
>>>>>> oval-variables-schema.xsd?
>>>>>>
>>>>>> The variables schema is independent of the definitions schemas. It's
>>>>>> simply a means of feeding external variable values to an interpreter.
>>>>>>
>>>>>> Panos wanted to use this schema for some other purpose -- to work
>>>>>> with a
>>>>>> tool that would collect values.  Luis was just pointing out that SCAP
>>>>>> actually has a way to do this exact thing, in an intended way.
>>>>>>
>>>>>> XML is flexible.  If one wanted to decorate a variables file with
>>>>>> other
>>>>>> information, it could be defined in a different schema, with its own
>>>>>> namespace, and simply added to the document.  An OVAL interpreter
>>>>>> expecting a variables schema could safely ignore the extra data.
>>>>>> Alternatively, the tool could use its own format, and generate a
>>>>>> schema-conforming variables document to feed into the OVAL
>interpreter
>>>>>> -- which is exactly what the variables format is intended to do.
>>>>>>
>>>>>> That's the issue I had with Panos's request.  I hope my reasoning
>>>>>> makes
>>>>>> sense!
>>>>>>
>>>>>> Regards,
>>>>>> --David
>>>>>>
>>>>>> On 8/27/2012 11:43 AM, Robert Huffman wrote:
>>>>>>
>>>>>> As an OVAL novice, I was thinking Pano's idea was already supported by
>>>>>> OVAL using the comment element of a variable. However, the real
>>>>>> problem
>>>>>> is that the variables section does not need to be included in the OVAL
>>>>>> document.
>>>>>>
>>>>>> So, what if you simply allowed the inclusion of external_variable
>>>>>> elements within an OVAL document without the value? Currently, the
>>>>>> value
>>>>>> is  required. If it was optional, then an OVAL author could include
>>>>>> the
>>>>>> external_variable and use the comment element to provide guidance
>to
>>>>>> tools that could collect input from the user.
>>>>>>
>>>>>> Using OCIL to collect values may be a decent idea, but that should be
>>>>>> left up to vendors. Someone should be able to write a standalone
>OVAL
>>>>>> tool without implementing OCIL. Just provide a mechanism for
>providing
>>>>>> guidance about the meaning of an external variable within OVAL itself.
>>>>>>
>>>>>> On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
>>>>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>>
>>>>>>     Luis' idea is fine by me.
>>>>>>
>>>>>>     So, you are saying OCIL could be used with questionnaires to
>>>>>>     generate OCIL results and then jOval XPERT can be enhanced to
>>>>>>     generate the external variables from the OCI results?.
>>>>>>
>>>>>>     Is there a transition mechanism between OCIL output and OVAL
>>>>>>     external variable files or is it practically up to the implementer
>>>>>>     to perform the task?
>>>>>>
>>>>>>     Panos
>>>>>>
>>>>>>     *From:*David Solin [mailto:[hidden email]
>>>>>> <mailto:[hidden email]>]
>>>>>>     *Sent:* Tuesday, August 07, 2012 10:29 AM
>>>>>>     *To:* [hidden email]
>>>>>> <mailto:[hidden email]>
>>>>>>
>>>>>>
>>>>>>     *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
>>>>>> VariableType of
>>>>>>     oval-variables-schema.xsd?
>>>>>>
>>>>>>     I only have experience with two products that make use of the OVAL
>>>>>>     variables file: ovaldi and jOVAL.  Both take the external
>>>>>> variables
>>>>>>     file as input for processing OVAL definitions. What makes an
>>>>>>     external variable "external" is that its value is not defined
>>>>>> in the
>>>>>>     OVAL definitions document.  The specification doesn't say anything
>>>>>>     about querying users for values.  That kind of function is, in my
>>>>>>     mind, external to OVAL.
>>>>>>
>>>>>>     Now, Luis makes a great point -- there is a standard in the SCAP
>>>>>>     specification (OCIL) that is designed to be used to ask people
>>>>>>     questions.  Furthermore, XCCDF has the capability to define both
>>>>>>     variable imports and exports.  It would be fairly easy to
>>>>>> import an
>>>>>>     answer from an OCIL question result.
>>>>>>
>>>>>>     Currently, XPERT only supports imports from SCE scripts, but it
>>>>>> can
>>>>>>     produce OVAL variables file format documents encapsulating exports
>>>>>>     from the XCCDF document to the OVAL system.  It also handles
>>>>>>     importing OCIL results files.  So, with just a bit of extra
>>>>>> work to
>>>>>>     support OCIL imports, you could do exactly what Luis proposes.
>>>>>>
>>>>>>     Regards,
>>>>>>     --David Solin
>>>>>>
>>>>>>     On 8/7/2012 8:44 AM, Luis Nunez wrote:
>>>>>>
>>>>>>         Can we use OCIL to generate external variables for OVAL?
>>>>>> If can
>>>>>>         define the right questions to ask maybe OCIL could be the UI?
>>>>>>
>>>>>>         -ln
>>>>>>
>>>>>>         On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:
>>>>>>
>>>>>>         Thanks David.
>>>>>>
>>>>>>         So, what is the tool that today collects external variables? I
>>>>>>         don't know of any.
>>>>>>
>>>>>>         What I was thinking was that an evaluator that checks for an
>>>>>>         oval def with an external variable certainly takes the
>>>>>> external
>>>>>>         variable as its input. Now, if that external variable needs to
>>>>>>         be adjusted for my system I need to go in the external
>>>>>> variable
>>>>>>         file and edit the values that I need to edit. And it is more
>>>>>>         likely that the external variable file will be provided as a
>>>>>>         template with the def, I don't expect the user that will
>>>>>> use the
>>>>>>         evaluator tool to write the external variable file from
>>>>>> scratch.
>>>>>>
>>>>>>         So, if my thinking is right and the external variable file
>>>>>> goes
>>>>>>         with the oval def, then wouldn't it make sense to have a field
>>>>>>         that a GUI could use in order to take the external variable
>>>>>>         template file for the oval def and present to the user the
>>>>>>         fields he needs to populate and what they are?
>>>>>>
>>>>>>          > Given the above, couldn't you use a different format to
>>>>>> feed
>>>>>>         such questions into a collection UI?  That tool would
>>>>>> generate a
>>>>>>         variables file, but it certainly doesn't need to consume one.
>>>>>>
>>>>>>         Doesn't the OVAL author write the oval code and the external
>>>>>>         variables he will use, that need to be adjusted on a
>>>>>> per-system
>>>>>>         basis? Having the oval author provide one more format to
>>>>>> define
>>>>>>         what the external variables needed are, I think, is more
>>>>>>         complicated that what I am proposing.
>>>>>>
>>>>>>         BTW, has a format/schema or something been considered
>>>>>> before for
>>>>>>         the external variable collection? Or has it always been
>>>>>> assumed
>>>>>>         that external variables are provided somehow?
>>>>>>
>>>>>>         Rgs,
>>>>>>
>>>>>>         Panos
>>>>>>
>>>>>>         *From:* David Solin [mailto:[hidden email]] *On
>>>>>>         Behalf Of *David Solin
>>>>>>         *Sent:* Tuesday, August 07, 2012 12:29 AM
>>>>>>         *To:* OVAL Developer List (Closed Public Discussion)
>>>>>>         *Cc:* Panos Kampanakis (pkampana)
>>>>>>         *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
>>>>>> VariableType
>>>>>>         of oval-variables-schema.xsd?
>>>>>>
>>>>>>         Hi Panos,
>>>>>>
>>>>>>         The purpose of the variables schema is to transmit external
>>>>>>         variable values to an OVAL interpreter, not to collect those
>>>>>>         values.  I assume that collecting those values is the job of
>>>>>>         some other tool, that need not be restricted by the schema,
>>>>>> and
>>>>>>         which is potentially outside the scope of the OVAL standards.
>>>>>>
>>>>>>         Given the above, couldn't you use a different format to feed
>>>>>>         such questions into a collection UI?  That tool would
>>>>>> generate a
>>>>>>         variables file, but it certainly doesn't need to consume one.
>>>>>>         Or do you really think we need to expand the scope of the
>>>>>>         external variables document to include collection of the
>>>>>> values?
>>>>>>
>>>>>>         Regards,
>>>>>>         --David Solin
>>>>>>
>>>>>>         On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:
>>>>>>
>>>>>>             Hello everyone,
>>>>>>
>>>>>>             I wanted to submit a new element user_friendly_description
>>>>>>             in the VariableType of oval-variables-schema.xsd:
>>>>>>
>>>>>>             --------
>>>>>>
>>>>>>             <xsd:element name="user_friendly_description"
>>>>>>             type="xsd:string" minOccurs="0" maxOccurs="1">
>>>>>>
>>>>>>                               <xsd:annotation>
>>>>>>
>>>>>> <xsd:documentation>Note that the
>>>>>>             user_friendly_description is used by OVAL evaluation
>>>>>> visual
>>>>>>             tools to provide a visual text to the user to ensure
>>>>>> that he
>>>>>>             understands what the variable describes. Then he will be
>>>>>>             able to provide the external variable value that will be
>>>>>>             used by the tool to evaluate the
>>>>>> definition.</xsd:documentation>
>>>>>>
>>>>>>                               </xsd:annotation>
>>>>>>
>>>>>>                          </xsd:element>
>>>>>>
>>>>>>             --------
>>>>>>
>>>>>>             That element will be used by the OVAL evaluators that
>>>>>> have a
>>>>>>             GUI to provide a visual text to the user. For example
>>>>>> if the
>>>>>>             variable is used to give the failename that will be
>>>>>> checked
>>>>>>             against something theuser_friendly_description could say
>>>>>>             "This is the filename of the file that contains x".
>>>>>>
>>>>>>             What I envision is using an external variable file to be
>>>>>>             imported in an automated evaluation tool. That automated
>>>>>>             tool will show the field that needs its value populated in
>>>>>>             the external variables and it will show a text to the user
>>>>>>             based on the new element. So, the user can see what these
>>>>>>             variables are. After populating them in the GUI the tool
>>>>>>             will generate the external variable file to be run with
>>>>>>             OVAL. That way you have a visual way to tell the user
>>>>>> how to
>>>>>>             populate the external variables and he doesn't need to go
>>>>>>             update the xml directly and mess things up.
>>>>>>
>>>>>>             we can't enforce that the author will write the
>>>>>> explanation
>>>>>>             using the user_friendly_description. But we can enforce
>>>>>> that
>>>>>>             the tool will show what the author wants when he wants it.
>>>>>>             We could have the tool to show the"comment" in the
>>>>>> variable
>>>>>>             instead, but the comment is used in many places and
>>>>>> authors
>>>>>>             could use it for many other reasons. So, the new
>>>>>> element is
>>>>>>             practically for the tool. Authors will still leave it
>>>>>> out if
>>>>>>             they want to, but if it is in there then the tool
>>>>>> definitely
>>>>>>             knows what is it there for, for the user's benefit and it
>>>>>>             will show it in the GUI.
>>>>>>
>>>>>>             What does the community think? Would it be beneficial
>>>>>> to add
>>>>>>             it in the oval-variables-schema.xsd schema?
>>>>>>
>>>>>>             Rgs,
>>>>>>
>>>>>>             Panos
>>>>>>
>>>>>>             To unsubscribe, send an email message to
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]> with SIGNOFF
>>>>>>             OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>>>> have
>>>>>>             difficulties, write to
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]>.
>>>>>>
>>>>>>         --
>>>>>>
>>>>>>         jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
>>>>>>         /Scan any machine from any machine. For free!/
>>>>>>         Learn More <http://www.joval.org> | Features
>>>>>> <http://www.joval.org/features/> | Download
>>>>>> <http://www.joval.org/download/>
>>>>>>
>>>>>>         To unsubscribe, send an email message to
>>>>>> [hidden email] <mailto:[hidden email]> with
>>>>>>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>>>>         have difficulties, write to
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]>.
>>>>>>
>>>>>>         To unsubscribe, send an email message to
>>>>>> [hidden email] <mailto:[hidden email]> with
>>>>>>         SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>>>>         have difficulties, write to
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]>.
>>>>>>
>>>>>>     --
>>>>>>
>>>>>>     jOVAL.org: OVAL implemented in Java.
>>>>>>     /Scan any machine from any machine. For free!/
>>>>>>     Learn More <http://www.joval.org> | Features
>>>>>> <http://www.joval.org/features/> | Download
>>>>>> <http://www.joval.org/download/>
>>>>>>
>>>>>>     To unsubscribe, send an email message to
>[hidden email]
>>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-
>LIST
>>>>>>     in the BODY of the message. If you have difficulties, write to
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]>.
>>>>>>
>>>>>>     To unsubscribe, send an email message to
>[hidden email]
>>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-
>LIST
>>>>>>     in the BODY of the message. If you have difficulties, write to
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]>.
>>>>>>
>>>>>> To unsubscribe, send an email message to [hidden email]
>>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-
>LIST in
>>>>>> the BODY of the message. If you have difficulties, write to
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]>.
>>>>>>
>>>>>> --
>>>>>>
>>>>>> jOVAL.org: OVAL implemented in Java.
>>>>>> /Scan any machine from any machine. For free!/
>>>>>> Learn More <http://www.joval.org> | Features
>>>>>> <http://www.joval.org/features/> | Download
>>>>>> <http://www.joval.org/download/>
>>>>>>
>>>>>> To unsubscribe, send an email message to [hidden email]
>>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-
>LIST in
>>>>>> the BODY of the message. If you have difficulties, write to
>>>>>> [hidden email]
>>>>>> <mailto:[hidden email]>.
>>>>>>
>>>>>> To unsubscribe, send an email message to [hidden email]
>with
>>>>>> SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>>>>> difficulties, write to [hidden email].
>>>>>
>>>>> To unsubscribe, send an email message to [hidden email]
>with
>>>>> SIGNOFF OVAL-DEVELOPER-LIST
>>>>> in the BODY of the message.  If you have difficulties, write to
>>>>> [hidden email].
>>>>
>>>>
>>>> --
>>>>
>>>> jOVAL.org: OVAL implemented in Java.
>>>> /Scan any machine from any machine. For free!/
>>>> Learn More <http://www.joval.org> | Features
>>>> <http://www.joval.org/features/> | Download
>>>> <http://www.joval.org/download/>
>>>>
>>>
>>> To unsubscribe, send an email message to [hidden email]
>with
>>> SIGNOFF OVAL-DEVELOPER-LIST
>>> in the BODY of the message.  If you have difficulties, write to
>>> [hidden email].
>>
>>
>> --
>>
>> jOVAL.org: OVAL implemented in Java.
>> /Scan any machine from any machine. For free!/
>> Learn More <http://www.joval.org> | Features
>> <http://www.joval.org/features/> | Download
>> <http://www.joval.org/download/>
>>
>
>To unsubscribe, send an email message to [hidden email] with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to OVAL-
>[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

Danny Haynes
Administrator
In reply to this post by joval

David, it looks like you were able to capture my thoughts in much fewer words ;).

 

Thanks,


Danny

 

From: David Solin [mailto:[hidden email]]
Sent: Thursday, September 13, 2012 10:07 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] New element in VariableType of oval-variables-schema.xsd?

 

My take on Danny's suggestion was that we could add support for annotations for the external variable definitions, which one could then leverage however one saw fit -- with Panos's use-case being one such possibility.

In general, then, I think we actually agree: OCIL is SCAP's way of interrogating people, and we should endeavor to leverage it for that purpose!

On 9/12/2012 3:46 PM, Gunnar Engelbach wrote:

That's all possible if what Panos is requesting represents the very rare and closed-loop case.  But since Danny is talking about extending the schema it sounds as if he's trying to offer a more broadly usable solution.

To that end, I think that changes necessary to enable using the user as a data source should be done in the standard meant to do user interaction:  OCIL.  Most of side affects of processing user input has already been thought out there.  Additionally, since it is not yet widely used, schema changes will not have as much of an impact.

On the other hand, if the view is that OVAL should be capable of covering more use cases as a standalone, then Danny's suggestion is the simplest way to get there (and could have some utility outside of this specific usage) -- with the caveat that it doesn't allow for type checking, response validation, etc, without some further changes.



On 9/12/2012 3:06 PM, David Solin wrote:

It is that simple.  OCIL results actually spell out the answer value
under the xpath:
/ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer

The value of the entity is the actual answer value, including (if
applicable) a resolved variable value.

Now, assuming you have control

On 9/12/2012 1:37 PM, Gunnar Engelbach wrote:

On 9/12/2012 2:15 PM, David Solin wrote:

Hi Gunnar,

I think you should be able to get an answer /value/ from OCIL into XCCDF
using a variable import.  In fact, IIRC, imports can take the form of
generic XPATH queries -- so there would be no problem grabbing a value.



Not really that simple.

First, because processing the <question_results> section of an OCIL
report using XPATH is outside of any of the standards.  In other
words, there isn't a mechanism within any of the standards to get a
user-input value from OCIL to XCCDF or OVAL.


Sure there is.

http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf

Section 6.4.4.4. <xccdf:check> check-import element is described:

"Identifies a value to be retrieved from the checking system during
testing of a target system. This element MUST be empty. After the
associated check results have been collected, the result structure
returned by the checking engine is processed to collect the named
information. This information is then recorded in the
<xccdf:check-import> element in the corresponding <xccdf:rule-result>.
This could be a single value or structured XML. In the latter case, the
@import-xpath attribute can be used to traverse the structured XML and
identify specific information of interest to record in the result."

If the question is a string_question, then the XPATH expression:
/ocil/results/question_results/question_result[@question_ref="ocil:identifier"]/answer

... will be populated with the user's actual response.

Map the import to a value, and the value to an export and... Voila. A
value is passed as output from one check system and into another.



Second, the user response won't necessarily be recorded as a raw
value, but might in fact be a reference to one of the possible values
enumerated by the question.


One can manipulate that data, of course, but aren't we are assuming that
this hypothetical OCIL was authored intentionally to collect variable
values?



Try to bolt extended functionality onto OVAL doesn't make sense to me
and just makes it needlessly more complicated.  Instead it makes more
sense to take advantage of OCIL as a complimentary standard whose
designed purpose is human interaction.


SCAP is the wrong place to avoid needless complexity! ;)

I agree that a purpose-built tool could be less cumbersome, but that's
almost invariably the case with purpose-built tools, for obvious reasons.

The one thing that's truly unspecified is whether it's legal to chain
import and export relationships.  This would have potentially very
complicated implications on the order in which checks must be executed.
The existing XCCDF interpreters I've worked with that support OCIL
(those are, jOVAL XPERT and the reference XCCDF interpreter --
xccdfexec) both evaluate OCIL first, then OVAL.







Regarding Danny's proposal, anyway, I have no objection at all.

Cheers,
--David

On 9/12/2012 11:52 AM, Gunnar Engelbach wrote:

I have to wonder, is such an open-ended ability really what Panos
needs?  In other words, does he really need the ability to adjust the
value for each possible test across the full range of what is legal
for that value?  Or will the expected usage tend to be more like a
particular state as defined by differing but static sets of values?
If the latter, then using XCCDF as the front end with multiple
profiles to define the variable values would be considerably easier
from a user standpoint.

The suggestion to use OCIL as a front end for this seems like a more
reasonable starting point.  OCIL was designed with the intent for
human interaction so I would expect it to be a more natural starting
point for getting response values from a human.  One important
consideration, for example, is that using explanatory notes doesn't
provide for a programmatic way to ensure that user input is valid for
each variable, which is something that OCIL does provide. What OCIL
lacks right now is the ability to return the value of a question
rather than the test result of a question.


 --gun


On 9/12/2012 12:34 PM, Haynes, Dan wrote:

I was re-reading this thread and I think that there may be a generic
OVAL-only solution for this.  Specifically, the oval-def:NotesType
which
has the following documentation (see Section 4.3.7 of the OVAL
Language
Specification):

   “The NotesType is a container for one or more notes, providing
additional information, such as unresolved questions, reasons for
specific implementation, or other documentation.”

The oval-def:NotesType construct is currently available to content
authors for use in definitions, tests, objects, and states. It is not
currently supported in oval-def:external_variable,
oval-def:constant_variable, oval-def:local_variable, or
oval-var:variable.  I looked around and I couldn’t find a specific
reason as to why the oval-def:NotesType construct was not included in
the various variable constructs.  I think it was just something
that we
overlooked because there seemed to be consensus during the development
of OVAL 5.0 that notes should be extended to tests, objects, states,
etc. (see
http://making-security-measurable.1364806.n2.nabble.com/OVAL-Metadata-tp22526.html).


If we added support for it, using Panos’ example, a variable in an
OVAL
Variable document might look like the following.

   <variable id="oval:sample:var:1" datatype="string" comment="This
variable holds the filename that contains x.">

     <notes>

       <note>This is the filename of the file that contains x.</note>

       <note>You can identify this file by taking the following steps:
…</note>

       …

     </notes>

     <value>file.txt</value>

   </variable>

A tool could then take the information contained in the notes and
present it to the user.  Or, even better, a tool might look for the
notes in the oval-def:external_variables, in the OVAL Definitions
document, and could generate any number of formats (OVAL Variables,
XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
course, all of this would be optional and it would be up to the
content
author to put the notes in a location where the tool is expecting
them.

As for the schema, I think we could just pull the
oval-def:NotesType up
into the oval-common-schema.xsd.  From there, it could be used in both
the oval-definitions-schema.xsd and the oval-variables-schema.xsd.

Does this seem like it would be a reasonable solution?

Thanks,

Danny

*From:*David Solin [[hidden email]]
*Sent:* Monday, August 27, 2012 4:12 PM
*To:* oval-developer-list OVAL Developer List/Closed Public Discussion
*Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
oval-variables-schema.xsd?

The variables schema is independent of the definitions schemas. It's
simply a means of feeding external variable values to an interpreter.

Panos wanted to use this schema for some other purpose -- to work
with a
tool that would collect values.  Luis was just pointing out that SCAP
actually has a way to do this exact thing, in an intended way.

XML is flexible.  If one wanted to decorate a variables file with
other
information, it could be defined in a different schema, with its own
namespace, and simply added to the document.  An OVAL interpreter
expecting a variables schema could safely ignore the extra data.
Alternatively, the tool could use its own format, and generate a
schema-conforming variables document to feed into the OVAL interpreter
-- which is exactly what the variables format is intended to do.

That's the issue I had with Panos's request.  I hope my reasoning
makes
sense!

Regards,
--David

On 8/27/2012 11:43 AM, Robert Huffman wrote:

As an OVAL novice, I was thinking Pano's idea was already supported by
OVAL using the comment element of a variable. However, the real
problem
is that the variables section does not need to be included in the OVAL
document.

So, what if you simply allowed the inclusion of external_variable
elements within an OVAL document without the value? Currently, the
value
is  required. If it was optional, then an OVAL author could include
the
external_variable and use the comment element to provide guidance to
tools that could collect input from the user.

Using OCIL to collect values may be a decent idea, but that should be
left up to vendors. Someone should be able to write a standalone OVAL
tool without implementing OCIL. Just provide a mechanism for providing
guidance about the meaning of an external variable within OVAL itself.

On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
<[hidden email] [hidden email]> wrote:

    Luis’ idea is fine by me.

    So, you are saying OCIL could be used with questionnaires to
    generate OCIL results and then jOval XPERT can be enhanced to
    generate the external variables from the OCI results?.

    Is there a transition mechanism between OCIL output and OVAL
    external variable files or is it practically up to the implementer
    to perform the task?

    Panos

    *From:*David Solin [[hidden email]
[hidden email]]
    *Sent:* Tuesday, August 07, 2012 10:29 AM
    *To:* [hidden email]
[hidden email]


    *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
VariableType of
    oval-variables-schema.xsd?

    I only have experience with two products that make use of the OVAL
    variables file: ovaldi and jOVAL.  Both take the external
variables
    file as input for processing OVAL definitions. What makes an
    external variable "external" is that its value is not defined
in the
    OVAL definitions document.  The specification doesn't say anything
    about querying users for values.  That kind of function is, in my
    mind, external to OVAL.

    Now, Luis makes a great point -- there is a standard in the SCAP
    specification (OCIL) that is designed to be used to ask people
    questions.  Furthermore, XCCDF has the capability to define both
    variable imports and exports.  It would be fairly easy to
import an
    answer from an OCIL question result.

    Currently, XPERT only supports imports from SCE scripts, but it
can
    produce OVAL variables file format documents encapsulating exports
    from the XCCDF document to the OVAL system.  It also handles
    importing OCIL results files.  So, with just a bit of extra
work to
    support OCIL imports, you could do exactly what Luis proposes.

    Regards,
    --David Solin

    On 8/7/2012 8:44 AM, Luis Nunez wrote:

        Can we use OCIL to generate external variables for OVAL?
If can
        define the right questions to ask maybe OCIL could be the UI?

        -ln

        On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:

        Thanks David.

        So, what is the tool that today collects external variables? I
        don’t know of any.

        What I was thinking was that an evaluator that checks for an
        oval def with an external variable certainly takes the
external
        variable as its input. Now, if that external variable needs to
        be adjusted for my system I need to go in the external
variable
        file and edit the values that I need to edit. And it is more
        likely that the external variable file will be provided as a
        template with the def, I don’t expect the user that will
use the
        evaluator tool to write the external variable file from
scratch.

        So, if my thinking is right and the external variable file
goes
        with the oval def, then wouldn’t it make sense to have a field
        that a GUI could use in order to take the external variable
        template file for the oval def and present to the user the
        fields he needs to populate and what they are?

         > Given the above, couldn't you use a different format to
feed
        such questions into a collection UI?  That tool would
generate a
        variables file, but it certainly doesn't need to consume one.

        Doesn’t the OVAL author write the oval code and the external
        variables he will use, that need to be adjusted on a
per-system
        basis? Having the oval author provide one more format to
define
        what the external variables needed are, I think, is more
        complicated that what I am proposing.

        BTW, has a format/schema or something been considered
before for
        the external variable collection? Or has it always been
assumed
        that external variables are provided somehow?

        Rgs,

        Panos

        *From:* David Solin [[hidden email]] *On
        Behalf Of *David Solin
        *Sent:* Tuesday, August 07, 2012 12:29 AM
        *To:* OVAL Developer List (Closed Public Discussion)
        *Cc:* Panos Kampanakis (pkampana)
        *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
VariableType
        of oval-variables-schema.xsd?

        Hi Panos,

        The purpose of the variables schema is to transmit external
        variable values to an OVAL interpreter, not to collect those
        values.  I assume that collecting those values is the job of
        some other tool, that need not be restricted by the schema,
and
        which is potentially outside the scope of the OVAL standards.

        Given the above, couldn't you use a different format to feed
        such questions into a collection UI?  That tool would
generate a
        variables file, but it certainly doesn't need to consume one.
        Or do you really think we need to expand the scope of the
        external variables document to include collection of the
values?

        Regards,
        --David Solin

        On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:

            Hello everyone,

            I wanted to submit a new element user_friendly_description
            in the VariableType of oval-variables-schema.xsd:

            --------

            <xsd:element name="user_friendly_description"
            type="xsd:string" minOccurs="0" maxOccurs="1">

                              <xsd:annotation>

<xsd:documentation>Note that the
            user_friendly_description is used by OVAL evaluation
visual
            tools to provide a visual text to the user to ensure
that he
            understands what the variable describes. Then he will be
            able to provide the external variable value that will be
            used by the tool to evaluate the
definition.</xsd:documentation>

                              </xsd:annotation>

                         </xsd:element>

            --------

            That element will be used by the OVAL evaluators that
have a
            GUI to provide a visual text to the user. For example
if the
            variable is used to give the failename that will be
checked
            against something theuser_friendly_description could say
            “This is the filename of the file that contains x”.

            What I envision is using an external variable file to be
            imported in an automated evaluation tool. That automated
            tool will show the field that needs its value populated in
            the external variables and it will show a text to the user
            based on the new element. So, the user can see what these
            variables are. After populating them in the GUI the tool
            will generate the external variable file to be run with
            OVAL. That way you have a visual way to tell the user
how to
            populate the external variables and he doesn’t need to go
            update the xml directly and mess things up.

            we can’t enforce that the author will write the
explanation
            using the user_friendly_description. But we can enforce
that
            the tool will show what the author wants when he wants it.
            We could have the tool to show the“comment” in the
variable
            instead, but the comment is used in many places and
authors
            could use it for many other reasons. So, the new
element is
            practically for the tool. Authors will still leave it
out if
            they want to, but if it is in there then the tool
definitely
            knows what is it there for, for the user’s benefit and it
            will show it in the GUI.

            What does the community think? Would it be beneficial
to add
            it in the oval-variables-schema.xsd schema?

            Rgs,

            Panos

            To unsubscribe, send an email message to
[hidden email]
[hidden email] with SIGNOFF
            OVAL-DEVELOPER-LIST in the BODY of the message. If you
have
            difficulties, write to
[hidden email]
[hidden email].

        --

        jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
        /Scan any machine from any machine. For free!/
        Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

        To unsubscribe, send an email message to
[hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
[hidden email]
[hidden email].

        To unsubscribe, send an email message to
[hidden email] [hidden email] with
        SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
        have difficulties, write to
[hidden email]
[hidden email].

    --

    jOVAL.org: OVAL implemented in Java.
    /Scan any machine from any machine. For free!/
    Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

    To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

    To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST
    in the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>

To unsubscribe, send an email message to [hidden email]
[hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in
the BODY of the message. If you have difficulties, write to
[hidden email]
[hidden email].

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
difficulties, write to [hidden email].


To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].



--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>


To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
[hidden email].



--

jOVAL.org: OVAL implemented in Java.
/Scan any machine from any machine. For free!/
Learn More <http://www.joval.org> | Features
<http://www.joval.org/features/> | Download
<http://www.joval.org/download/>


To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].

 

--

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

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: New element in VariableType of oval-variables-schema.xsd?

Gunnar Engelbach
In reply to this post by Danny Haynes
To be clear, I think your suggestion has merit on its own outside of
Panos-related usage it might be put to.  I can only speak for our
implementations, but it won't cause any difficulties to have that change
whether or not it ever is used and it's also more consistent so I think
it's actually an overall simplification of OVAL, so I'm not seeing any
reason to warrant not doing it.

And certainly, you can embed information in the <notes> section to
indicate things like legal values and data types, but if you don't
formalize this then it's a vendor free-for-all when it comes to
implementation -- the same dilemma, BTW, we had to address while
building the HSR Toolkit.  By putting it into a notes element that
specification would have to happen via external documentation and
wouldn't be subject to schema validation.  Or you can add new elements
to put that kind of ability into the schema.  Either way you'll end up
replicating a significant part of of OCIL.  And that could be entirely
valid if the view is that OVAL needs to have that kind of capability
without relying on OCIL.


So that we can stop dragging Panos name into this, how about we refer to
this as "The ability to resolve OVAL external variable values using user
input" or some such.  Does that seem to capture it?


And in case Panos is still listening:

Do you need something that is formalized in the spec that can be broadly
implemented by vendors, or is more of an immediate one-off need?

If the latter and you have complete control over the OVAL benchmark then
David's suggestion is a workable solution and probably the simplest.
And in that case I wouldn't bother using OCIL but just create an XML
file with a known filename and format that you can reference from your
OVAL.

Alternatively, if you write a simple front-end that prompts the user for
the values and writes the result as an XCCDF document that references
your OVAL document and uses the <check-export> element to provide those
values to the OVAL.  Then you could run the result in any SCAP-compliant
interpreter.  This solution removes the data file name and XPATH from
the OVAL so the same OVAL file could be used more broadly.


--gun


On 9/13/2012 1:17 PM, Haynes, Dan wrote:

> Hi Gunnar,
>
>> That's all possible if what Panos is requesting represents the very rare
>> and closed-loop case.  But since Danny is talking about extending the
>> schema it sounds as if he's trying to offer a more broadly usable solution.
>
> The way I interpreted Panos' request (let me know if I am way off ;)) was that he just needed a place to put additional information that would help the user know what to put there, but, he didn't really like the idea of using comments because they might be leveraged for something else (maybe notes from the person who created the content?).  Yes, this would be a more broad solution that could be used to satisfy Panos' use case or possibly someone else's.
>
>> To that end, I think that changes necessary to enable using the user as
>> a data source should be done in the standard meant to do user
>> interaction:  OCIL.  Most of side affects of processing user input has
>> already been thought out there.  Additionally, since it is not yet
>> widely used, schema changes will not have as much of an impact.
>
> I agree that this is a valid use case for OCIL.
>
>> On the other hand, if the view is that OVAL should be capable of
>> covering more use cases as a standalone, then Danny's suggestion is the
>> simplest way to get there (and could have some utility outside of this
>> specific usage) -- with the caveat that it doesn't allow for type
>> checking, response validation, etc, without some further changes.
>
> I saw this solution as a way to address Panos' needs without adding something use-case specific to OVAL that may not be needed by everyone.  With this solution, a content author can decide how they want to use the NotesType (if at all).  For what it's worth, I think if I realized that the NotesType construct was available on all the major constructs except for variables, even before this use case, I would probably suggest that we add it to variables to make these language constructs more consistent and give content authors more flexibility.
>
> Regarding type checking, response validation, etc., this is more something to think about, but, if a tool was looking at the external_variables to figure out what to display to a user (using notes), a tool might also be able to leverage the other information in the external_variable (datatype attribute, possible_value and possible_restriction constructs) to do some type checking and input validation.
>
> Thanks,
>
> Danny
>
>> On 9/12/2012 3:06 PM, David Solin wrote:
>>> It is that simple.  OCIL results actually spell out the answer value
>>> under the xpath:
>>>
>> /ocil/results/question_results/question_result[@question_ref="ocil:identifier
>> "]/answer
>>>
>>> The value of the entity is the actual answer value, including (if
>>> applicable) a resolved variable value.
>>>
>>> Now, assuming you have control
>>>
>>> On 9/12/2012 1:37 PM, Gunnar Engelbach wrote:
>>>> On 9/12/2012 2:15 PM, David Solin wrote:
>>>>> Hi Gunnar,
>>>>>
>>>>> I think you should be able to get an answer /value/ from OCIL into XCCDF
>>>>> using a variable import.  In fact, IIRC, imports can take the form of
>>>>> generic XPATH queries -- so there would be no problem grabbing a value.
>>>>
>>>>
>>>> Not really that simple.
>>>>
>>>> First, because processing the <question_results> section of an OCIL
>>>> report using XPATH is outside of any of the standards.  In other
>>>> words, there isn't a mechanism within any of the standards to get a
>>>> user-input value from OCIL to XCCDF or OVAL.
>>>
>>> Sure there is.
>>>
>>> http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf
>>>
>>> Section 6.4.4.4. <xccdf:check> check-import element is described:
>>>
>>> "Identifies a value to be retrieved from the checking system during
>>> testing of a target system. This element MUST be empty. After the
>>> associated check results have been collected, the result structure
>>> returned by the checking engine is processed to collect the named
>>> information. This information is then recorded in the
>>> <xccdf:check-import> element in the corresponding <xccdf:rule-result>.
>>> This could be a single value or structured XML. In the latter case, the
>>> @import-xpath attribute can be used to traverse the structured XML and
>>> identify specific information of interest to record in the result."
>>>
>>> If the question is a string_question, then the XPATH expression:
>>>
>> /ocil/results/question_results/question_result[@question_ref="ocil:identifier
>> "]/answer
>>>
>>> ... will be populated with the user's actual response.
>>>
>>> Map the import to a value, and the value to an export and... Voila. A
>>> value is passed as output from one check system and into another.
>>>
>>>>
>>>> Second, the user response won't necessarily be recorded as a raw
>>>> value, but might in fact be a reference to one of the possible values
>>>> enumerated by the question.
>>>>
>>>
>>> One can manipulate that data, of course, but aren't we are assuming that
>>> this hypothetical OCIL was authored intentionally to collect variable
>>> values?
>>>
>>>>
>>>> Try to bolt extended functionality onto OVAL doesn't make sense to me
>>>> and just makes it needlessly more complicated.  Instead it makes more
>>>> sense to take advantage of OCIL as a complimentary standard whose
>>>> designed purpose is human interaction.
>>>>
>>>
>>> SCAP is the wrong place to avoid needless complexity! ;)
>>>
>>> I agree that a purpose-built tool could be less cumbersome, but that's
>>> almost invariably the case with purpose-built tools, for obvious reasons.
>>>
>>> The one thing that's truly unspecified is whether it's legal to chain
>>> import and export relationships.  This would have potentially very
>>> complicated implications on the order in which checks must be executed.
>>> The existing XCCDF interpreters I've worked with that support OCIL
>>> (those are, jOVAL XPERT and the reference XCCDF interpreter --
>>> xccdfexec) both evaluate OCIL first, then OVAL.
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Regarding Danny's proposal, anyway, I have no objection at all.
>>>>>
>>>>> Cheers,
>>>>> --David
>>>>>
>>>>> On 9/12/2012 11:52 AM, Gunnar Engelbach wrote:
>>>>>> I have to wonder, is such an open-ended ability really what Panos
>>>>>> needs?  In other words, does he really need the ability to adjust the
>>>>>> value for each possible test across the full range of what is legal
>>>>>> for that value?  Or will the expected usage tend to be more like a
>>>>>> particular state as defined by differing but static sets of values?
>>>>>> If the latter, then using XCCDF as the front end with multiple
>>>>>> profiles to define the variable values would be considerably easier
>>>>>> from a user standpoint.
>>>>>>
>>>>>> The suggestion to use OCIL as a front end for this seems like a more
>>>>>> reasonable starting point.  OCIL was designed with the intent for
>>>>>> human interaction so I would expect it to be a more natural starting
>>>>>> point for getting response values from a human.  One important
>>>>>> consideration, for example, is that using explanatory notes doesn't
>>>>>> provide for a programmatic way to ensure that user input is valid for
>>>>>> each variable, which is something that OCIL does provide. What OCIL
>>>>>> lacks right now is the ability to return the value of a question
>>>>>> rather than the test result of a question.
>>>>>>
>>>>>>
>>>>>>   --gun
>>>>>>
>>>>>>
>>>>>> On 9/12/2012 12:34 PM, Haynes, Dan wrote:
>>>>>>> I was re-reading this thread and I think that there may be a generic
>>>>>>> OVAL-only solution for this.  Specifically, the oval-def:NotesType
>>>>>>> which
>>>>>>> has the following documentation (see Section 4.3.7 of the OVAL
>>>>>>> Language
>>>>>>> Specification):
>>>>>>>
>>>>>>>     "The NotesType is a container for one or more notes, providing
>>>>>>> additional information, such as unresolved questions, reasons for
>>>>>>> specific implementation, or other documentation."
>>>>>>>
>>>>>>> The oval-def:NotesType construct is currently available to content
>>>>>>> authors for use in definitions, tests, objects, and states. It is not
>>>>>>> currently supported in oval-def:external_variable,
>>>>>>> oval-def:constant_variable, oval-def:local_variable, or
>>>>>>> oval-var:variable.  I looked around and I couldn't find a specific
>>>>>>> reason as to why the oval-def:NotesType construct was not included in
>>>>>>> the various variable constructs.  I think it was just something
>>>>>>> that we
>>>>>>> overlooked because there seemed to be consensus during the
>> development
>>>>>>> of OVAL 5.0 that notes should be extended to tests, objects, states,
>>>>>>> etc. (see
>>>>>>> http://making-security-measurable.1364806.n2.nabble.com/OVAL-
>> Metadata-tp22526.html).
>>>>>>>
>>>>>>>
>>>>>>> If we added support for it, using Panos' example, a variable in an
>>>>>>> OVAL
>>>>>>> Variable document might look like the following.
>>>>>>>
>>>>>>>     <variable id="oval:sample:var:1" datatype="string" comment="This
>>>>>>> variable holds the filename that contains x.">
>>>>>>>
>>>>>>>       <notes>
>>>>>>>
>>>>>>>         <note>This is the filename of the file that contains x.</note>
>>>>>>>
>>>>>>>         <note>You can identify this file by taking the following steps:
>>>>>>> ...</note>
>>>>>>>
>>>>>>>         ...
>>>>>>>
>>>>>>>       </notes>
>>>>>>>
>>>>>>>       <value>file.txt</value>
>>>>>>>
>>>>>>>     </variable>
>>>>>>>
>>>>>>> A tool could then take the information contained in the notes and
>>>>>>> present it to the user.  Or, even better, a tool might look for the
>>>>>>> notes in the oval-def:external_variables, in the OVAL Definitions
>>>>>>> document, and could generate any number of formats (OVAL Variables,
>>>>>>> XCCDF, etc.) for reading in the oval-def:external_variable values.  Of
>>>>>>> course, all of this would be optional and it would be up to the
>>>>>>> content
>>>>>>> author to put the notes in a location where the tool is expecting
>>>>>>> them.
>>>>>>>
>>>>>>> As for the schema, I think we could just pull the
>>>>>>> oval-def:NotesType up
>>>>>>> into the oval-common-schema.xsd.  From there, it could be used in
>> both
>>>>>>> the oval-definitions-schema.xsd and the oval-variables-schema.xsd.
>>>>>>>
>>>>>>> Does this seem like it would be a reasonable solution?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Danny
>>>>>>>
>>>>>>> *From:*David Solin [mailto:[hidden email]]
>>>>>>> *Sent:* Monday, August 27, 2012 4:12 PM
>>>>>>> *To:* oval-developer-list OVAL Developer List/Closed Public Discussion
>>>>>>> *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in VariableType of
>>>>>>> oval-variables-schema.xsd?
>>>>>>>
>>>>>>> The variables schema is independent of the definitions schemas. It's
>>>>>>> simply a means of feeding external variable values to an interpreter.
>>>>>>>
>>>>>>> Panos wanted to use this schema for some other purpose -- to work
>>>>>>> with a
>>>>>>> tool that would collect values.  Luis was just pointing out that SCAP
>>>>>>> actually has a way to do this exact thing, in an intended way.
>>>>>>>
>>>>>>> XML is flexible.  If one wanted to decorate a variables file with
>>>>>>> other
>>>>>>> information, it could be defined in a different schema, with its own
>>>>>>> namespace, and simply added to the document.  An OVAL interpreter
>>>>>>> expecting a variables schema could safely ignore the extra data.
>>>>>>> Alternatively, the tool could use its own format, and generate a
>>>>>>> schema-conforming variables document to feed into the OVAL
>> interpreter
>>>>>>> -- which is exactly what the variables format is intended to do.
>>>>>>>
>>>>>>> That's the issue I had with Panos's request.  I hope my reasoning
>>>>>>> makes
>>>>>>> sense!
>>>>>>>
>>>>>>> Regards,
>>>>>>> --David
>>>>>>>
>>>>>>> On 8/27/2012 11:43 AM, Robert Huffman wrote:
>>>>>>>
>>>>>>> As an OVAL novice, I was thinking Pano's idea was already supported by
>>>>>>> OVAL using the comment element of a variable. However, the real
>>>>>>> problem
>>>>>>> is that the variables section does not need to be included in the OVAL
>>>>>>> document.
>>>>>>>
>>>>>>> So, what if you simply allowed the inclusion of external_variable
>>>>>>> elements within an OVAL document without the value? Currently, the
>>>>>>> value
>>>>>>> is  required. If it was optional, then an OVAL author could include
>>>>>>> the
>>>>>>> external_variable and use the comment element to provide guidance
>> to
>>>>>>> tools that could collect input from the user.
>>>>>>>
>>>>>>> Using OCIL to collect values may be a decent idea, but that should be
>>>>>>> left up to vendors. Someone should be able to write a standalone
>> OVAL
>>>>>>> tool without implementing OCIL. Just provide a mechanism for
>> providing
>>>>>>> guidance about the meaning of an external variable within OVAL itself.
>>>>>>>
>>>>>>> On Tue, Aug 7, 2012 at 10:24 AM, Panos Kampanakis (pkampana)
>>>>>>> <[hidden email] <mailto:[hidden email]>> wrote:
>>>>>>>
>>>>>>>      Luis' idea is fine by me.
>>>>>>>
>>>>>>>      So, you are saying OCIL could be used with questionnaires to
>>>>>>>      generate OCIL results and then jOval XPERT can be enhanced to
>>>>>>>      generate the external variables from the OCI results?.
>>>>>>>
>>>>>>>      Is there a transition mechanism between OCIL output and OVAL
>>>>>>>      external variable files or is it practically up to the implementer
>>>>>>>      to perform the task?
>>>>>>>
>>>>>>>      Panos
>>>>>>>
>>>>>>>      *From:*David Solin [mailto:[hidden email]
>>>>>>> <mailto:[hidden email]>]
>>>>>>>      *Sent:* Tuesday, August 07, 2012 10:29 AM
>>>>>>>      *To:* [hidden email]
>>>>>>> <mailto:[hidden email]>
>>>>>>>
>>>>>>>
>>>>>>>      *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
>>>>>>> VariableType of
>>>>>>>      oval-variables-schema.xsd?
>>>>>>>
>>>>>>>      I only have experience with two products that make use of the OVAL
>>>>>>>      variables file: ovaldi and jOVAL.  Both take the external
>>>>>>> variables
>>>>>>>      file as input for processing OVAL definitions. What makes an
>>>>>>>      external variable "external" is that its value is not defined
>>>>>>> in the
>>>>>>>      OVAL definitions document.  The specification doesn't say anything
>>>>>>>      about querying users for values.  That kind of function is, in my
>>>>>>>      mind, external to OVAL.
>>>>>>>
>>>>>>>      Now, Luis makes a great point -- there is a standard in the SCAP
>>>>>>>      specification (OCIL) that is designed to be used to ask people
>>>>>>>      questions.  Furthermore, XCCDF has the capability to define both
>>>>>>>      variable imports and exports.  It would be fairly easy to
>>>>>>> import an
>>>>>>>      answer from an OCIL question result.
>>>>>>>
>>>>>>>      Currently, XPERT only supports imports from SCE scripts, but it
>>>>>>> can
>>>>>>>      produce OVAL variables file format documents encapsulating exports
>>>>>>>      from the XCCDF document to the OVAL system.  It also handles
>>>>>>>      importing OCIL results files.  So, with just a bit of extra
>>>>>>> work to
>>>>>>>      support OCIL imports, you could do exactly what Luis proposes.
>>>>>>>
>>>>>>>      Regards,
>>>>>>>      --David Solin
>>>>>>>
>>>>>>>      On 8/7/2012 8:44 AM, Luis Nunez wrote:
>>>>>>>
>>>>>>>          Can we use OCIL to generate external variables for OVAL?
>>>>>>> If can
>>>>>>>          define the right questions to ask maybe OCIL could be the UI?
>>>>>>>
>>>>>>>          -ln
>>>>>>>
>>>>>>>          On Aug 7, 2012, at 9:13 AM, Panos Kampanakis (pkampana) wrote:
>>>>>>>
>>>>>>>          Thanks David.
>>>>>>>
>>>>>>>          So, what is the tool that today collects external variables? I
>>>>>>>          don't know of any.
>>>>>>>
>>>>>>>          What I was thinking was that an evaluator that checks for an
>>>>>>>          oval def with an external variable certainly takes the
>>>>>>> external
>>>>>>>          variable as its input. Now, if that external variable needs to
>>>>>>>          be adjusted for my system I need to go in the external
>>>>>>> variable
>>>>>>>          file and edit the values that I need to edit. And it is more
>>>>>>>          likely that the external variable file will be provided as a
>>>>>>>          template with the def, I don't expect the user that will
>>>>>>> use the
>>>>>>>          evaluator tool to write the external variable file from
>>>>>>> scratch.
>>>>>>>
>>>>>>>          So, if my thinking is right and the external variable file
>>>>>>> goes
>>>>>>>          with the oval def, then wouldn't it make sense to have a field
>>>>>>>          that a GUI could use in order to take the external variable
>>>>>>>          template file for the oval def and present to the user the
>>>>>>>          fields he needs to populate and what they are?
>>>>>>>
>>>>>>>           > Given the above, couldn't you use a different format to
>>>>>>> feed
>>>>>>>          such questions into a collection UI?  That tool would
>>>>>>> generate a
>>>>>>>          variables file, but it certainly doesn't need to consume one.
>>>>>>>
>>>>>>>          Doesn't the OVAL author write the oval code and the external
>>>>>>>          variables he will use, that need to be adjusted on a
>>>>>>> per-system
>>>>>>>          basis? Having the oval author provide one more format to
>>>>>>> define
>>>>>>>          what the external variables needed are, I think, is more
>>>>>>>          complicated that what I am proposing.
>>>>>>>
>>>>>>>          BTW, has a format/schema or something been considered
>>>>>>> before for
>>>>>>>          the external variable collection? Or has it always been
>>>>>>> assumed
>>>>>>>          that external variables are provided somehow?
>>>>>>>
>>>>>>>          Rgs,
>>>>>>>
>>>>>>>          Panos
>>>>>>>
>>>>>>>          *From:* David Solin [mailto:[hidden email]] *On
>>>>>>>          Behalf Of *David Solin
>>>>>>>          *Sent:* Tuesday, August 07, 2012 12:29 AM
>>>>>>>          *To:* OVAL Developer List (Closed Public Discussion)
>>>>>>>          *Cc:* Panos Kampanakis (pkampana)
>>>>>>>          *Subject:* Re: [OVAL-DEVELOPER-LIST] New element in
>>>>>>> VariableType
>>>>>>>          of oval-variables-schema.xsd?
>>>>>>>
>>>>>>>          Hi Panos,
>>>>>>>
>>>>>>>          The purpose of the variables schema is to transmit external
>>>>>>>          variable values to an OVAL interpreter, not to collect those
>>>>>>>          values.  I assume that collecting those values is the job of
>>>>>>>          some other tool, that need not be restricted by the schema,
>>>>>>> and
>>>>>>>          which is potentially outside the scope of the OVAL standards.
>>>>>>>
>>>>>>>          Given the above, couldn't you use a different format to feed
>>>>>>>          such questions into a collection UI?  That tool would
>>>>>>> generate a
>>>>>>>          variables file, but it certainly doesn't need to consume one.
>>>>>>>          Or do you really think we need to expand the scope of the
>>>>>>>          external variables document to include collection of the
>>>>>>> values?
>>>>>>>
>>>>>>>          Regards,
>>>>>>>          --David Solin
>>>>>>>
>>>>>>>          On 8/6/2012 9:30 AM, Panos Kampanakis (pkampana) wrote:
>>>>>>>
>>>>>>>              Hello everyone,
>>>>>>>
>>>>>>>              I wanted to submit a new element user_friendly_description
>>>>>>>              in the VariableType of oval-variables-schema.xsd:
>>>>>>>
>>>>>>>              --------
>>>>>>>
>>>>>>>              <xsd:element name="user_friendly_description"
>>>>>>>              type="xsd:string" minOccurs="0" maxOccurs="1">
>>>>>>>
>>>>>>>                                <xsd:annotation>
>>>>>>>
>>>>>>> <xsd:documentation>Note that the
>>>>>>>              user_friendly_description is used by OVAL evaluation
>>>>>>> visual
>>>>>>>              tools to provide a visual text to the user to ensure
>>>>>>> that he
>>>>>>>              understands what the variable describes. Then he will be
>>>>>>>              able to provide the external variable value that will be
>>>>>>>              used by the tool to evaluate the
>>>>>>> definition.</xsd:documentation>
>>>>>>>
>>>>>>>                                </xsd:annotation>
>>>>>>>
>>>>>>>                           </xsd:element>
>>>>>>>
>>>>>>>              --------
>>>>>>>
>>>>>>>              That element will be used by the OVAL evaluators that
>>>>>>> have a
>>>>>>>              GUI to provide a visual text to the user. For example
>>>>>>> if the
>>>>>>>              variable is used to give the failename that will be
>>>>>>> checked
>>>>>>>              against something theuser_friendly_description could say
>>>>>>>              "This is the filename of the file that contains x".
>>>>>>>
>>>>>>>              What I envision is using an external variable file to be
>>>>>>>              imported in an automated evaluation tool. That automated
>>>>>>>              tool will show the field that needs its value populated in
>>>>>>>              the external variables and it will show a text to the user
>>>>>>>              based on the new element. So, the user can see what these
>>>>>>>              variables are. After populating them in the GUI the tool
>>>>>>>              will generate the external variable file to be run with
>>>>>>>              OVAL. That way you have a visual way to tell the user
>>>>>>> how to
>>>>>>>              populate the external variables and he doesn't need to go
>>>>>>>              update the xml directly and mess things up.
>>>>>>>
>>>>>>>              we can't enforce that the author will write the
>>>>>>> explanation
>>>>>>>              using the user_friendly_description. But we can enforce
>>>>>>> that
>>>>>>>              the tool will show what the author wants when he wants it.
>>>>>>>              We could have the tool to show the"comment" in the
>>>>>>> variable
>>>>>>>              instead, but the comment is used in many places and
>>>>>>> authors
>>>>>>>              could use it for many other reasons. So, the new
>>>>>>> element is
>>>>>>>              practically for the tool. Authors will still leave it
>>>>>>> out if
>>>>>>>              they want to, but if it is in there then the tool
>>>>>>> definitely
>>>>>>>              knows what is it there for, for the user's benefit and it
>>>>>>>              will show it in the GUI.
>>>>>>>
>>>>>>>              What does the community think? Would it be beneficial
>>>>>>> to add
>>>>>>>              it in the oval-variables-schema.xsd schema?
>>>>>>>
>>>>>>>              Rgs,
>>>>>>>
>>>>>>>              Panos
>>>>>>>
>>>>>>>              To unsubscribe, send an email message to
>>>>>>> [hidden email]
>>>>>>> <mailto:[hidden email]> with SIGNOFF
>>>>>>>              OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>>>>> have
>>>>>>>              difficulties, write to
>>>>>>> [hidden email]
>>>>>>> <mailto:[hidden email]>.
>>>>>>>
>>>>>>>          --
>>>>>>>
>>>>>>>          jOVAL.org <http://jOVAL.org>: OVAL implemented in Java.
>>>>>>>          /Scan any machine from any machine. For free!/
>>>>>>>          Learn More <http://www.joval.org> | Features
>>>>>>> <http://www.joval.org/features/> | Download
>>>>>>> <http://www.joval.org/download/>
>>>>>>>
>>>>>>>          To unsubscribe, send an email message to
>>>>>>> [hidden email] <mailto:[hidden email]> with
>>>>>>>          SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>>>>>          have difficulties, write to
>>>>>>> [hidden email]
>>>>>>> <mailto:[hidden email]>.
>>>>>>>
>>>>>>>          To unsubscribe, send an email message to
>>>>>>> [hidden email] <mailto:[hidden email]> with
>>>>>>>          SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you
>>>>>>>          have difficulties, write to
>>>>>>> [hidden email]
>>>>>>> <mailto:[hidden email]>.
>>>>>>>
>>>>>>>      --
>>>>>>>
>>>>>>>      jOVAL.org: OVAL implemented in Java.
>>>>>>>      /Scan any machine from any machine. For free!/
>>>>>>>      Learn More <http://www.joval.org> | Features
>>>>>>> <http://www.joval.org/features/> | Download
>>>>>>> <http://www.joval.org/download/>
>>>>>>>
>>>>>>>      To unsubscribe, send an email message to
>> [hidden email]
>>>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-
>> LIST
>>>>>>>      in the BODY of the message. If you have difficulties, write to
>>>>>>> [hidden email]
>>>>>>> <mailto:[hidden email]>.
>>>>>>>
>>>>>>>      To unsubscribe, send an email message to
>> [hidden email]
>>>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-
>> LIST
>>>>>>>      in the BODY of the message. If you have difficulties, write to
>>>>>>> [hidden email]
>>>>>>> <mailto:[hidden email]>.
>>>>>>>
>>>>>>> To unsubscribe, send an email message to [hidden email]
>>>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-
>> LIST in
>>>>>>> the BODY of the message. If you have difficulties, write to
>>>>>>> [hidden email]
>>>>>>> <mailto:[hidden email]>.
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> jOVAL.org: OVAL implemented in Java.
>>>>>>> /Scan any machine from any machine. For free!/
>>>>>>> Learn More <http://www.joval.org> | Features
>>>>>>> <http://www.joval.org/features/> | Download
>>>>>>> <http://www.joval.org/download/>
>>>>>>>
>>>>>>> To unsubscribe, send an email message to [hidden email]
>>>>>>> <mailto:[hidden email]> with SIGNOFF OVAL-DEVELOPER-
>> LIST in
>>>>>>> the BODY of the message. If you have difficulties, write to
>>>>>>> [hidden email]
>>>>>>> <mailto:[hidden email]>.
>>>>>>>
>>>>>>> To unsubscribe, send an email message to [hidden email]
>> with
>>>>>>> SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have
>>>>>>> difficulties, write to [hidden email].
>>>>>>
>>>>>> To unsubscribe, send an email message to [hidden email]
>> with
>>>>>> SIGNOFF OVAL-DEVELOPER-LIST
>>>>>> in the BODY of the message.  If you have difficulties, write to
>>>>>> [hidden email].
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> jOVAL.org: OVAL implemented in Java.
>>>>> /Scan any machine from any machine. For free!/
>>>>> Learn More <http://www.joval.org> | Features
>>>>> <http://www.joval.org/features/> | Download
>>>>> <http://www.joval.org/download/>
>>>>>
>>>>
>>>> To unsubscribe, send an email message to [hidden email]
>> with
>>>> SIGNOFF OVAL-DEVELOPER-LIST
>>>> in the BODY of the message.  If you have difficulties, write to
>>>> [hidden email].
>>>
>>>
>>> --
>>>
>>> jOVAL.org: OVAL implemented in Java.
>>> /Scan any machine from any machine. For free!/
>>> Learn More <http://www.joval.org> | Features
>>> <http://www.joval.org/features/> | Download
>>> <http://www.joval.org/download/>
>>>
>>
>> To unsubscribe, send an email message to [hidden email] with
>> SIGNOFF OVAL-DEVELOPER-LIST
>> in the BODY of the message.  If you have difficulties, write to OVAL-
>> [hidden email].
>
> To unsubscribe, send an email message to [hidden email] with
> SIGNOFF OVAL-DEVELOPER-LIST
> in the BODY of the message.  If you have difficulties, write to [hidden email].
>

To unsubscribe, send an email message to [hidden email] with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to [hidden email].
12