Open Vulnerability and Assessment Language

With version 4 of the schema, you can not perform a pattern match operation in a field bound by an enumeration.  This is because the pattern that is entered is not part of the enumeration and will cause validation to fail.

Date Added: 2005-01-28 20:00:37
Logged In: YES 
user_id=29178

This is also a problem for component and version datatypes, as well as non-string datatypes like int.

Date Added: 2008-10-21 16:23:48
Maybe we could use schematron validation to enforce the enumeration instead of XSD schema.  This would allow us to make a judgement call base on the operation attribute.  If it is patter match, then allow any string.  If it is string, then enforce the enumeration.

Date Added: 2009-05-11 15:35:19
Consider leveraging variables to support this. NIST published FDCC content that used a var_ref on an entity bound by an enumeration. They specified a pattern match as the operator. The referenced variable held a regex that identifies several values.

Another option would be to use the var_ref and refer to a variable that held a list of values. This would allow an author to specify the full set of values without a regex. The author would need to consider the var_check attr.

Date Added: 2009-06-10 18:10:01
As a result of the discussion at the Security Automation Conference, it has been decided that we will keep the pattern match work-around with enumerations in the OVAL Language and simply update the documentation to explicitly state this work-around as a feature.  The driving force behind keeping this work-around is that removing it would invalidate a lot of existing content.  It has also been recommended that any regular expression specified as a result of this work-around should be anchored to ensure that the pattern must match the entire string.

Date Added: 2009-06-10 23:07:46
let's put the documentation update at a fairly high level in the schema. Perhaps we can document this once on the base entity types? Something like "note that when an entity is restricted to an enumerated value any usage of pattern matches and variables must be careful to ensure the the regular expression and variable values align with the enumerated values."

http://msdn2.microsoft.com/en-us/library/ms724878.aspx

 

Quote “Registry keys do not support the SYNCHRONIZE standard access right.”

 

It looks like this right should be removed from a future version of the test.



I believe ‘synchronize’ rights refers to an ability to work offline, and to synchronize files and folders once reconnected to the network.  Does this setting apply to registry keys?

Date Added: 2009-05-04 13:53:21
For version 5.6 let's make sure we deprecate the SYNCHRONIZE value.

Date Added: 2009-05-11 15:39:41
if the description is correct let's deprecate the entity in version 5.6 draft 2

Date Added: 2009-05-12 20:43:40
Danny, can you track down deprecating this item in the next draft of version 5.6

The windows SC schema is missing the <sid_sid_item>.

n/a

Hi,

Can I get a little clarification on this statement from the spec (regarding the Arithmetic function)?

“The arithmetic function takes two or more integer or float components and performs a basic mathmetical function on them.  The result of this function in a single integer or float.”

If any of the components are multi-valued, the result will be multiple integers or floats, correct? 

Thanks,
Ken Simone

n/a

Many of the security bulletins for VMWARE ESX Server contain non-numerical characters in the patche numbers for vulnerabilities.  We would like to update the schema to reflect this.  The patch_object and patch_state datatypes should be changed from 'int' to 'string'.  (Micheal Wood - HP)

Date Added: 2009-03-18 17:13:55
change has been made

I'm looking at using a <local_variable> in an OVAL Test that I am developing.  I have some questions on how the datatype attribute should be used / enforced.  The current schema is a bit vague in the situation I am looking at ...

 <local_variable id="var:1" datatype="??????">
   <substring> ... returns 1
 </local_variable>

The local_variable being referenced looks at a string and performs a substring function to return the first character.  (assume that this character normally is either '0' or '1' so it satisfies W3C boolean datatype)

Can the variable datatype be set to "boolean"?  What happens if the character(s) returned by the substring function do not represent boolean data?

The current documentation for the datatype attribute of a variable reads ... "The required datatype attribute specifies the type of value being defined. The set of values identified by a variable must comply with the specified datatype."

I interpret this to mean that the <variable> does its thing to return a set of characters (could be a string, or a number, or a version, etc).  This set of characters should then be treated as the stated datatype.  If the set of characters returned does not satisfy the stated datatype, then an error should be returned by the variable.

I propose clarifying this documentation to read ...

"The required datatype attribute specifies the type of value being defined.  The set of values identified by a variable must comply with the specified datatype, otherwise and error should be reported.  Please see the DatatypeEnumeration for details about each valid datatype.  For example, if the datatype of the variable is specified as boolean then the value(s) returned by the component / function should be "true", "false", "1", or "0".

Thoughts?

Date Added: 2009-05-11 15:36:26
Can this be addressed in the second draft of version 5.6

The tests in the Unix schema are missing schematron checks that verify that the objects and states referenced by the test are of the correct type.

Date Added: 2009-03-18 17:08:04
new schematron checks have been added to the unix component schema

The schematron rules in the password_state found in the UNIX component schema refer to the package_state by mistake.

Date Added: 2009-05-14 15:52:33
fixed

in windows many registry keys hold the complete filepath for a file like:
c:/program files/progam/file.exe

there is a common need to be able to query the registry for the location of a file and then check its version. This currently can no be done because there is no way to separate the filename and path from the complete file path. 

Possible solutions are:
- to add additional functions to be used with variables to support this(strlen, findlastindexof, substringafter).

- modify the file_object declaration to support this.

- others....


There are a few examples of this in the oval repository

Date Added: 2008-11-11 19:20:04
the current thinking is to solve this with a choice structure inside the OVAL Object that allows both representations.

Date Added: 2009-06-22 17:10:06
Closing this as it is a duplicate of #12789

The documentation needs to be updated to specify that the behavior should recursively resolve groups.

Date Added: 2008-11-11 17:58:20
The 'resolve_group' behavior defines whether an object set defined by a group sid should be resolved to return a set that contains all the user sids that are a member of that group.  Note that all child groups should also be resolved any valid domain users that are members of the group should also be included.  The intent of this behavior is to end up with a list of all individual users from that system that make up the group once everything has been resolved.

The original component schema submission was made on Tue 4/14/2009 9:21 AM. The submission email is in the oval-developer-list archive. 

n/a

In unix-system-characteristics
File_item 
a_time 
c_time *
m_time *

* If this is seconds since last Epoch --documentation is not clear.  An
example or guidance based on stat man page would be nice


This was reported on: Fri 5/1/2009 7:30 AM 
by:  Vladimir Giszpenc 
DSCI Contractor Supporting
US Army CERDEC S&TCD IAD Tactical Network Protection Branch
(732) 532-8959

Date Added: 2009-05-06 14:52:13
Please also review the documentation for the a_time element and look at the documentation in the unix-definition-schema for the same constructs

There is currently no constraint in the xsd that forces a referenced variable to exist in the definitions document. For example:

<variable_object id="oval:org.mitre.oval:obj:6625" version="1" ...>
  <var_ref>oval:org.mitre.oval:var:944</var_ref>
</variable_object>

can exist in a document where var:994 does not also exist. This should not be permitted and is enforced with keyrefs. Here is the keyref copied form the oval-definitions-schema for the @var_ref 

<xsd:keyref name="variableKeyRef" refer="oval-def:variableKey">
  <xsd:annotation>
    <xsd:documentation>Requires each variable reference to refer to a valid variable id.</xsd:documentation>
  </xsd:annotation>
  <xsd:selector xpath=".//*"/>
  <xsd:field xpath="@var_ref"/>
</xsd:keyref>


In this case the solution should be to add a similar key ref to the ind-def:variable_object declaration to ensure that the var_ref element's value exists.

n/a

This topic was discussed and agreed to at 2008 OVAL Developer Days. See the minutes from the event for detailed discussion.

n/a

This issue was reported in email to the oval developer list

>-----Original Message-----
>From: Timothy Harrison [mailto:tim.harrison@NIST.GOV]
>Sent: Tuesday, June 09, 2009 3:15 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] oval definitions schematron errors
>relating to win-def:wuaupdatesearcher_test
>
>The OVAL 5.5, and 5.6, oval-definitions-schematron use the wrong
>element name when asserting that the child elements of
>win-def:wuaupdatesearcher_test reference the correct type of
>object/state.  Instead of using "win-def:wuaupdatesearcher_object" and
>"win-def:wuaupdatesearcher_state" the assertions use
>"win-def:wuasearch_object" and "win-def:wuasearch_state",
>respectively.  These errors can be found on lines 6063 and 6067 in the
>OVAL 5.5 schematron and lines 6548 6552 in the OVAL 5.6 schematron.
>It is important to note that the text displayed for these rules uses
>the correct element names.
>

n/a

In reviewing the documentation for the win-def:sid_sid_object i noticed this statement 

"The potential object set should be limited to just the trustees on the DACL/SACL of the object in question." 

This was inadvertently copied from the fileeffectiverights_test. It looks like all of this type of documentation needs to be reviewed for consistency and correctness.

n/a

see developer list:

http://n2.nabble.com/Proposed-ldap-test-tp3170199p3170199.html

n/a

in draft 2 of version 5.6 we added a path + filename or filepath choice. need to clarify that the max_depth and recurse_direction file behaviors apply to the path enty and not to the filepath entity.

n/a

This looks to be an error in the documentation.  Thank you very much for pointing this out.  We will work to correct this in the upcoming draft.

What I think is going on here is that when we first added the <directives> to an OVAL Results document, the definition of what made of thin results and what made up full results was going to be held in a stylesheet.  But since then, this definition has been encoded in the Schematron statements located in the results schema itself.  We just did not update this documentation accordingly.

Thanks
Drew


>-----Original Message-----
>From: John Firebaugh [mailto:john_firebaugh@BIGFIX.COM]
>Sent: Tuesday, July 07, 2009 8:53 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] Results schema content directive style
>sheet
>
>The documentation for the results schema ContentEnumeration type reads:
>
>> Defines the valid values for the directives controlling the expected
>content
>> of the results file. The specific content that is expected with each
>value is
>> defined by a style sheet that complements the OVAL Results Schema.
>Please
>> refer to these style sheets for more information.
>
>To what style sheets does this refer and where can I find them?
>
>Thanks,
>John

Date Added: 2009-07-08 17:33:04
Updated the documentation to:

"The ContentEnumeration defines the valid values for the directives controlling the amount of expected depth found in the results file.  Each directive specified at the top of an OVAL Results file defines how much information should be included in the document for each of the different result types.  The amount of content that is expected with each value is defined by Schematron statements embedded throughout the OVAL Results Schema.  Currently, the enumeration defines two values: thin and full.  Please refer to the documentation of each individual value of this enumeration for more information about what each means."

need to allow collection and testing of the type of a unix interface

n/a

This test will allow checking for interim fixes. see:
http://n2.nabble.com/Potential-AIX-Limitations-with-OVAL-Schema-tp3475053ef20093.html

n/a

Update the win-def:EntityStateSharedResourceTypeType definition such that it accounts for all possible values of the shared_type entity as specified in the Microsoft documentation.  For more information about this change, please consult the following link. 

http://n2.nabble.com/Proposal-to-Amend-the-win-def%3AEntityStateSharedResourceTypeType-Definition-td2617124ef20093.html

n/a

For additional information, please see the proposal that has been posted to the OVAL Developer List at http://n2.nabble.com/Proposal-to-Modify-the-win-def%3Aactivedirectory_test-and-the-ind-def%3Aldap_test-tp3351022ef20093.html.

n/a

If a person is constructing a file_object from a value found in the registry, they typically pull a path out of the registry and the concatenate a filename onto the path.

Sometimes the registry stores the fully qualified path to a file such as "C:\itunes\iTunes.exe".  We need to be able to construct a file object from this registry key--right now this is not possible.

Date Added: 2008-11-11 19:18:42
the current thinking is to solve this with a choice structure inside the OVAL Object that allows both representations.

Date Added: 2009-05-11 15:42:08
closed because it is a dup of a prior bug (#12024).