Quantcast

non-printable chars in OVAL results?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

non-printable chars in OVAL results?

John Ulmer

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    (843) 218-5953

    [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
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

Danny Haynes
Administrator

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    (843) 218-5953

    [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].
<script id="dstb-id" language="javascript">if(typeof(dstb)!= "undefined"){ dstb();}</script>
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
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

joval
Hi John,

I was just writing a similar response when Danny's email came!

The specification says that the textfilecontent[54]_object is used "to check the contents of a text file (aka a configuration file)".  That's really not sufficiently descriptive, is it?  The content author should probably be able to specify an RFC2278 character set (i.e., US-ASCII -- which I'd use as the default, UTF-8, UTF-16LE, etc.) that's used to read the file and perform the pattern matching.

The interpreter would then use the specified character set for the operation, and convert the matching items into whatever encoding it used to write the XML file ... possibly using a safe encoding scheme like Windows-1252, which would avoid the problem of non-printable control characters.

Pointing to a binary file would actually be outside the scope of the specification and hence I would consider the result to be undefined, and quite possibly it should result in an error (although you can't necessarily tell if there should be an error the way the test is currently defined).  It would be like pointing to a non-XML file with an xmlfilecontent_object.

An independent:binaryfile_test would be interesting.  In the absence of a specific use-case, I could imagine it offering the ability to specify a magic header, a byte-range and pattern for matching, and we'd probably want to borrow the binary encoding convention from the registry_test (reg_binary) to make it workable.  IIRC, the way the binary test was originally pitched pertained to interpreting PE file headers, but in my opinion the windows:file_test pretty much already covers that case.

Regards,
--David

On 2/14/2012 3:54 PM, Haynes, Dan wrote:

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    (843) 218-5953

    [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].
<script id="dstb-id" language="javascript">if(typeof(dstb)!= "undefined"){ dstb();}</script>
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
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

John Ulmer
In reply to this post by Danny Haynes

That was generally our read on the situation.   And, with your concurrence, I think we’ll sniff any files that the textfilecontent or xmlfilecontent or similar tests want to open and make sure they appear to be an appropriate file type.  If we find something other than an appropriate file type, we’ll alert our user.

 

Thanks for the rapid response.

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Haynes, Dan
Sent: Tuesday, February 14, 2012 4:54 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    (843) 218-5953

    [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].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

joval
Hi John -- are you thinking: make sure each bytes falls between 0x20 and 0x7E, and if not report an error?  Or some other "sniff test"?

On 2/14/2012 4:23 PM, Ulmer, John R. wrote:

That was generally our read on the situation.   And, with your concurrence, I think we’ll sniff any files that the textfilecontent or xmlfilecontent or similar tests want to open and make sure they appear to be an appropriate file type.  If we find something other than an appropriate file type, we’ll alert our user.

 

Thanks for the rapid response.

 

 

From: [hidden email] [[hidden email]] On Behalf Of Haynes, Dan
Sent: Tuesday, February 14, 2012 4:54 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    (843) 218-5953

    [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].


--

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
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

Casey Jaymes

XML has built-in escaping. You could run the results through a filter to escape the illegal character into valid XML.

Casey

On Feb 14, 2012 5:27 PM, "David Solin" <[hidden email]> wrote:
Hi John -- are you thinking: make sure each bytes falls between 0x20 and 0x7E, and if not report an error?  Or some other "sniff test"?

On 2/14/2012 4:23 PM, Ulmer, John R. wrote:

That was generally our read on the situation.   And, with your concurrence, I think we’ll sniff any files that the textfilecontent or xmlfilecontent or similar tests want to open and make sure they appear to be an appropriate file type.  If we find something other than an appropriate file type, we’ll alert our user.

 

Thanks for the rapid response.

 

 

From: [hidden email] [[hidden email]] On Behalf Of Haynes, Dan
Sent: Tuesday, February 14, 2012 4:54 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    (843) 218-5953

    [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].


--

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
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

John Ulmer

We thought about doing something like that.  But, if you escape illegal chars in  the match results that are stored in an item,  won’t that make it pretty tricky  when it comes to applying a state comparison to that item?

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Casey Jaymes
Sent: Tuesday, February 14, 2012 7:37 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

XML has built-in escaping. You could run the results through a filter to escape the illegal character into valid XML.

Casey

On Feb 14, 2012 5:27 PM, "David Solin" <[hidden email]> wrote:

Hi John -- are you thinking: make sure each bytes falls between 0x20 and 0x7E, and if not report an error?  Or some other "sniff test"?

On 2/14/2012 4:23 PM, Ulmer, John R. wrote:

That was generally our read on the situation.   And, with your concurrence, I think we’ll sniff any files that the textfilecontent or xmlfilecontent or similar tests want to open and make sure they appear to be an appropriate file type.  If we find something other than an appropriate file type, we’ll alert our user.

 

Thanks for the rapid response.

 

 

From: [hidden email] [[hidden email]] On Behalf Of Haynes, Dan
Sent: Tuesday, February 14, 2012 4:54 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    (843) 218-5953

    [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].

 

--

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
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

Casey Jaymes

I would store them unescaped for processing and only escape them before outputting XML.

On Feb 15, 2012 9:33 AM, "Ulmer, John R." <[hidden email]> wrote:

We thought about doing something like that.  But, if you escape illegal chars in  the match results that are stored in an item,  won’t that make it pretty tricky  when it comes to applying a state comparison to that item?

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Casey Jaymes
Sent: Tuesday, February 14, 2012 7:37 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

XML has built-in escaping. You could run the results through a filter to escape the illegal character into valid XML.

Casey

On Feb 14, 2012 5:27 PM, "David Solin" <[hidden email]> wrote:

Hi John -- are you thinking: make sure each bytes falls between 0x20 and 0x7E, and if not report an error?  Or some other "sniff test"?

On 2/14/2012 4:23 PM, Ulmer, John R. wrote:

That was generally our read on the situation.   And, with your concurrence, I think we’ll sniff any files that the textfilecontent or xmlfilecontent or similar tests want to open and make sure they appear to be an appropriate file type.  If we find something other than an appropriate file type, we’ll alert our user.

 

Thanks for the rapid response.

 

 

From: [hidden email] [[hidden email]] On Behalf Of Haynes, Dan
Sent: Tuesday, February 14, 2012 4:54 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    <a href="tel:%28843%29%20218-5953" value="+18432185953" target="_blank">(843) 218-5953

    [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].

 

--

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].
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

joval
That won't work if you're accepting input from a system-characteristics.xml file.  You'd need to be able to specify an encoding scheme, which you simply can't do with the existing definitions for textfilecontent tests.

I think the test just isn't usable with binary file content as defined -- and if there's a need for that, we should come up with a new test.

On 2/15/2012 8:45 AM, Casey Jaymes wrote:

I would store them unescaped for processing and only escape them before outputting XML.

On Feb 15, 2012 9:33 AM, "Ulmer, John R." <[hidden email]> wrote:

We thought about doing something like that.  But, if you escape illegal chars in  the match results that are stored in an item,  won’t that make it pretty tricky  when it comes to applying a state comparison to that item?

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Casey Jaymes
Sent: Tuesday, February 14, 2012 7:37 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

XML has built-in escaping. You could run the results through a filter to escape the illegal character into valid XML.

Casey

On Feb 14, 2012 5:27 PM, "David Solin" <[hidden email]> wrote:

Hi John -- are you thinking: make sure each bytes falls between 0x20 and 0x7E, and if not report an error?  Or some other "sniff test"?

On 2/14/2012 4:23 PM, Ulmer, John R. wrote:

That was generally our read on the situation.   And, with your concurrence, I think we’ll sniff any files that the textfilecontent or xmlfilecontent or similar tests want to open and make sure they appear to be an appropriate file type.  If we find something other than an appropriate file type, we’ll alert our user.

 

Thanks for the rapid response.

 

 

From: [hidden email] [[hidden email]] On Behalf Of Haynes, Dan
Sent: Tuesday, February 14, 2012 4:54 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    <a moz-do-not-send="true" href="tel:%28843%29%20218-5953" value="+18432185953" target="_blank">(843) 218-5953

    [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].

 

--

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].


--

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
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

sprabhu
Well,

In supportive to John, I have similar test case but this is w.r.t "unix:Process58_test"
specific to Mac OS where
my result.xml contains non-printable chars at
"priority" attribute while collecting processes,
with "command_line operation being pattern match having" '.*',  thus overall run throws following error.

"Fatal Error.Occurred at file results.xml, line 376, column 39. Invalid character (Unicode: 0x18)"
(Attached the "result.xml" for reference)

However my Schematron validation is successful and test result is also as expected and the same test against
other OS variant works fine.

Note :

Though it has been made cleared that there is some issue with the implementation "process58_test" for Mac OS
from my previous discussions.


So I guess this might be the issue again with "Unix:process58_test" implementation for Mac OS,
then I would request this must be taken in consideration for fix, if this sounds to be an error.

-- 
Thanks !!
Prabhu S A

On 02/15/2012 08:30 PM, David Solin wrote:
That won't work if you're accepting input from a system-characteristics.xml file.  You'd need to be able to specify an encoding scheme, which you simply can't do with the existing definitions for textfilecontent tests.

I think the test just isn't usable with binary file content as defined -- and if there's a need for that, we should come up with a new test.

On 2/15/2012 8:45 AM, Casey Jaymes wrote:

I would store them unescaped for processing and only escape them before outputting XML.

On Feb 15, 2012 9:33 AM, "Ulmer, John R." <[hidden email]> wrote:

We thought about doing something like that.  But, if you escape illegal chars in  the match results that are stored in an item,  won’t that make it pretty tricky  when it comes to applying a state comparison to that item?

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Casey Jaymes
Sent: Tuesday, February 14, 2012 7:37 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

XML has built-in escaping. You could run the results through a filter to escape the illegal character into valid XML.

Casey

On Feb 14, 2012 5:27 PM, "David Solin" <[hidden email]> wrote:

Hi John -- are you thinking: make sure each bytes falls between 0x20 and 0x7E, and if not report an error?  Or some other "sniff test"?

On 2/14/2012 4:23 PM, Ulmer, John R. wrote:

That was generally our read on the situation.   And, with your concurrence, I think we’ll sniff any files that the textfilecontent or xmlfilecontent or similar tests want to open and make sure they appear to be an appropriate file type.  If we find something other than an appropriate file type, we’ll alert our user.

 

Thanks for the rapid response.

 

 

From: [hidden email] [[hidden email]] On Behalf Of Haynes, Dan
Sent: Tuesday, February 14, 2012 4:54 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    <a moz-do-not-send="true" href="tel:%28843%29%20218-5953" value="+18432185953" target="_blank">(843) 218-5953

    [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].

 

--

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].


--

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].

results.xml (118K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: non-printable chars in OVAL results?

Danny Haynes
Administrator

Hi Prabhu,

 

This is a known issue with the OVAL Interpreter.  You can find the bug tracker at the following link.

 

http://sourceforge.net/tracker/index.php?func=detail&aid=3384967&group_id=215469&atid=1033794

 

Thanks,

Danny

 

From: Prabhu S Angadi [mailto:[hidden email]]
Sent: Wednesday, March 21, 2012 10:06 AM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

Well,

In supportive to John, I have similar test case but this is w.r.t "unix:Process58_test"
specific to Mac OS where
my result.xml contains non-printable chars at "priority" attribute while collecting processes,
with "command_line operation being pattern match having" '.*',  thus overall run throws following error.

"Fatal Error.Occurred at file results.xml, line 376, column 39. Invalid character (Unicode: 0x18)"
(Attached the "result.xml" for reference)

However my Schematron validation is successful and test result is also as expected and the same test against
other OS variant works fine.

Note :

Though it has been made cleared that there is some issue with the implementation "process58_test" for Mac OS
from my previous discussions.


So I guess this might be the issue again with "Unix:process58_test" implementation for Mac OS,
then I would request this must be taken in consideration for fix, if this sounds to be an error.


-- 
Thanks !!
Prabhu S A


On 02/15/2012 08:30 PM, David Solin wrote:

That won't work if you're accepting input from a system-characteristics.xml file.  You'd need to be able to specify an encoding scheme, which you simply can't do with the existing definitions for textfilecontent tests.

I think the test just isn't usable with binary file content as defined -- and if there's a need for that, we should come up with a new test.

On 2/15/2012 8:45 AM, Casey Jaymes wrote:

I would store them unescaped for processing and only escape them before outputting XML.

On Feb 15, 2012 9:33 AM, "Ulmer, John R." <[hidden email]> wrote:

We thought about doing something like that.  But, if you escape illegal chars in  the match results that are stored in an item,  won’t that make it pretty tricky  when it comes to applying a state comparison to that item?

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Casey Jaymes
Sent: Tuesday, February 14, 2012 7:37 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

XML has built-in escaping. You could run the results through a filter to escape the illegal character into valid XML.

Casey

On Feb 14, 2012 5:27 PM, "David Solin" <[hidden email]> wrote:

Hi John -- are you thinking: make sure each bytes falls between 0x20 and 0x7E, and if not report an error?  Or some other "sniff test"?

On 2/14/2012 4:23 PM, Ulmer, John R. wrote:

That was generally our read on the situation.   And, with your concurrence, I think we’ll sniff any files that the textfilecontent or xmlfilecontent or similar tests want to open and make sure they appear to be an appropriate file type.  If we find something other than an appropriate file type, we’ll alert our user.

 

Thanks for the rapid response.

 

 

From: [hidden email] [[hidden email]] On Behalf Of Haynes, Dan
Sent: Tuesday, February 14, 2012 4:54 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

 

Hi John,

Good question.  In OVAL, we don't say anything specifically in the context of the ind-def:textfilecontent54_test.  However, in order for content to be valid it must pass both XML schema and schematron validation.  If you read something like a binary file and end up with illegal characters in your document, it would not be valid XML and therefore not valid OVAL.  As a result, in cases like this, we should be reporting errors. 

 

With that said, we don't have a good way to deal with binary files right now.  During the development of OVAL 5.10, there was a thread about creating a binary_test, however, it never really materialized into a proposal and as a result was not included in the OVAL 5.10 release.  The thread can be found here.

 

http://making-security-measurable.1364806.n2.nabble.com/Question-regarding-reading-a-binary-file-containing-NULL-bytes-tp6289707p6289707.html

 

This is probably something we should re-investigate for OVAL 5.11.  I will check to see if there is a tracker for this issue.  If not, I will add one.

 

Hope this helps.

 

Thanks,

Danny

 


From: Ulmer, John R. [[hidden email]]
Sent: Tuesday, February 14, 2012 4:40 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] non-printable chars in OVAL results?

On occasion, when we process certain content, the resulting items contain non-printable characters.

 

For instance, a textfilecontent54 object may specify a path and file (either explicitly or, more likely, via regex evaluation), which turns out to be a binary file and, in which, it is possible to find a match for the pattern.  If the text pattern is a regex, this can cause the item to contain unexpected characters.  Such characters can make subsequent XSLT transformations and other XML processing impossible.

 

    <textfilecontent54_object id=" obj:1">
      <path>/tmp/Some/path</path>
      <filename operation=”pattern match”>.*</filename>
      <pattern operation="pattern match">.*abc.*</pattern>
      <instance datatype="int" operation="greater than or equal">1</instance>
    </textfilecontent54_object>

 

Evaluating that object could easily result in trying to create items for binary files.

 

Trying to maintain a philosophy that the SCAP tool only does what the content author says (via the content) to do, how should this be handled? 

Does OVAL or SCAP address this issue directly?

Since evaluation of the content stream results in the creation of non-legal XML, should this be considered an error in the content?

 

Thanks,

--------------------------------------

John R. Ulmer       

 

    SPAWAR Systems Center Atlantic

    <a href="tel:%28843%29%20218-5953" target="_blank">(843) 218-5953

    [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].

 

--

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].

 

--

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].

smime.p7s (9K) Download Attachment
Loading...