Open Vulnerability and Assessment Language

I notice that one of the ways Schematron rules are used extensively is enforcing "datatype" attribute values. For example:

<xsd:element name="password_hist_len" type="oval-def:EntityStateIntType" minOccurs="0">
 
<sch:pattern id="win-def_ppstepassword_hist_len">
  <sch:rule context="win-def:passwordpolicy_state/win-def:password_hist_len">
    <sch:assert test="@datatype='int'"><sch:value-of select="../@id"/> - datatype attribute for the password_hist_len entity of a passwordpolicy_state should be 'int'</sch:assert>
  </sch:rule>
</sch:pattern>

I started thinking,  "Why is every single element that is declared of type 'EntityStateIntType' enforcing the value of '@datatype'? Can't the 'EntityStateIntType' do that?" So I took a look at the definition of 'EntityStateIntType':

<xsd:complexType name="EntityStateIntType">
  <xsd:simpleContent>
    <xsd:restriction base="oval-def:EntityBaseType">
      <xsd:simpleType>
        <xsd:union memberTypes="xsd:integer oval:EmptyStringType"/>                                    
      </xsd:simpleType>
    </xsd:restriction>
  </xsd:simpleContent>        
</xsd:complexType>

OK, that puts a restriction on the content of the element to be an integer or an empty string. What about restricting the value of the 'datatype' attribute? Something like:
<xsd:restriction base="oval-def:EntityStateIntType">
<xsd:attribute name="datatype" type="oval:DatatypeEnumeration" use="required" fixed="int"/>
</xsd:restriction>

Which says you must have a datatype attribute and its value must be "int" – just what the Schematron rule enforces. (Although the Schematron rule says 'should' rather than 'must' so maybe datatype="int" is a strong recommendation and not a requirement? In which case Schematron is the way to go.) That gives us:

<xsd:complexType name="EntityStateIntType">
  <xsd:annotation>
    <xsd:documentation>The EntityStateIntType type is extended by the entities of an individual OVAL State. This type provides uniformity to each state entity by including the attributes found in the EntityStateBaseType. This specific type describes simple integer data. The empty string is also allowed when using a variable reference with an element.
    </xsd:documentation>
  </xsd:annotation>
  <xsd:simpleContent>
    <xsd:restriction base="oval-def:EntityBaseType">
      <xsd:simpleType>
        <xsd:union memberTypes="xsd:integer oval:EmptyStringType"/>                                    
      </xsd:simpleType>
      <xsd:attribute name="datatype" type="oval:DatatypeEnumeration" use="required" fixed="int"/>                
    </xsd:restriction>
  </xsd:simpleContent>
</xsd:complexType>

Which declares two restrictions on the EntityBaseType, one restricting the contents and one restricting the datatype attribute value.

I did a search of windows-definitions-schema.xsd and there are just over 500 Schematron rules related to checking the datatype attribute values. That seems like a lot of rules for something that could be enforced by XML Schema at the "Type" level rather than the element instance level.

Date Added: 2010-05-05 12:38:48
The change to use "fixed" in the attribute declaration has been implemented.

Date Added: 2010-05-26 17:58:31
included in draft 2 of version 5.8

The port entity of xinetd_item should have integer type, e.g. xsd:integer.

Date Added: 2010-08-05 16:45:45
The xinetd_state's port entity also needs to be changed to an integer. 

This change will be included in draft 6 of version 5.8.

The following should be oval-sc:EntityItemIntType instead of oval-sc:EntityItemStringType.  There may be more, but this is
a good start.

unix-sc:file_item 
group_id
user_id 
a_time 
c_time *
m_time *

unix-sc:password_item
user_id
group_id

unix-sc:process_item
user_id
priority
ruid

unix-sc:shadow_item
chg_lst
chg_allow
chg_req
exp_warn
exp_inact
exp_date

linux-sc:inetlisteningserver_item
local_port
foreign_port
user_id

In all cases listed above the documentation states that the entities should hold numeric values. Each of the items listed also needs to be changed in the corresponding state and object.


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

Date Added: 2010-08-03 11:19:04
The documentation for the unix-def:file_item now states that the a_time, c_time, and m_time are all in seconds since the Unix epoch.

Date Added: 2010-08-05 18:49:52
Each of the changes listed above also needs a parallel change in the unix definitions schema. 

Date Added: 2010-08-05 19:03:38
In all cases the documentation defines the listed entities as being integers. I have verified that in all cases the OVAL Interpreter currently only outputs numeric values for these entities. Any content that uses string values instead of numeric values is incorrect and will likely lead to incorrect results. 


All of the items listed above will be corrected an included in draft 6 of version 5.8.

the following was submitted in response to the version 5.6 schema:

>
>* The environmentvariable_item for example is meaningless unless tied to a
>process ID. Each process can have a unique environment and in many cases,
>daemon initscripts purge or reset values. Should this element require a pid or
>at least allow specifying one?
>

Good point. I think the correct solution here would be to add a pid entity to the environmentvariable_object since really the environment variables are tied to a process. This would suggest that the pid will distinguish one set on environment variables from another. I would also suggest making this new pid entity nillable. This would allow a content author to essentially leave off the pid which we could define as meaning that the tools should collect environment variables information for the tool's running process. Then the pid would of course be added to the environmentvariable_state and environmentvariable_item. If we go this route we will of course need to update the documentation around this test, object, state, and item. 

Date Added: 2010-05-26 17:56:32
included in draft 2 of version 5.8

Date Added: 2010-06-02 11:14:39
Adding a pid entity to the environmentvariable_object will invalidate existing content and break backward compatibility. Created a new environmentvariable58_test, environmentvariable58_object, environmentvariable58_state, and environmentvariable58_item in order to add the pid entity and not invalidate existing content. This change will be included in draft 3 of version 5.8

From Steve Grubb

"As for AF_PACKET family...I was going to propose another test. Turns out 
things like tcpdump can bind to a device (eth0 for example) rather than an IP 
address. So, I was thinking that to find any network sniffers, you need a 
if_listeners test."

Date Added: 2010-07-02 20:16:03
Initial proposal to the oval-developer-list:

linux-def:if_listeners_object
	interface_name (string)	

linux-def:if_listeners_state
	interface_name (string)
	protocol (linux-def:EntityStateProtocolType)
	hw_address (string)
	program_name (string)
	pid (int)
	user_id (int)

linux-sc:if_listeners_item
	interface_name (string)
	protocol (linux-sc:EntityItemProtocolType)
	hw_address (string)
	program_name (string)
	pid (int)
	user_id (int)


The linux-def:EntityStateProtocolType and linux-sc:EntityItemProtocolType
enumerations will contain the protocol types defined in linux/if_ether.h.

Additional information regarding this proposal can be found on the
oval-developer-list archives at the following link.

http://making-security-measurable.1364806.n2.nabble.com/Comments-on-OVAL-5-7-tp4784920.html

These changes will be available in Draft 3 of Version 5.8.

Date Added: 2010-07-06 15:10:06
Updated if_listeners_* to iflisteners_* to align with the naming convention for OVAL tests.  This change will be available in Draft 4 of Version 5.8.

Copied from developer list email:


Looking at the OVAL schema docs, it doesn't appear that information on the remote (foreign) side of open connections is available in the Windows port_test.  Is this an intentional omission, or an oversight?  Note that it's available via netstat on the commandline.  I expected to see foreign_address and foreign_port analogs to the local_address and local_port elements of port_object and port_state (not sure if they'd want to be in the object or just the state).

I should add that I've only checked netstat output under Windows XP.  I suppose if this test dates back far enough, and earlier versions of Windows didn't report the foreign addr & port information, that would explain why the test doesn't include them.  Probably worth checking different versions of Windows.

Anyway, if there isn't some compelling reason to keep the remote side out of the test, could it be added in 5.8?

Thanks,

--Woj

Date Added: 2010-05-25 11:11:35
Added foreign_address and foreign_port entities to draft 2 of version 5.8.

>
>* In the shadow_item, the encryption algorithm is specified within the
>password
>field ( http://people.redhat.com/drepper/SHA-crypt.txt ). Should the
>algorithm
>be broken out specifically? How would someone write a test that checks
>that a
>system has SHA256 encoded passwords?
>

I think we simply need to add a new field to the unix-def:shadow_state and unix-sc-shadow_item to capture the algorithm that was use to encode the password. I think this is a simple string based entity that will record the algorithm. 

In order to do effective tests of the algorithm we need to make sure we define what the allowed values are in this new algorithm entity. I would be inclined to define an enumeration of the allowed values. Is there a system api that will list the values? Or is this list of algorithms going to be essentially the same as the list used for the filehash_test that we have been discussing? 

Date Added: 2010-05-07 20:19:14
see also:

http://making-security-measurable.1364806.n2.nabble.com/Comments-on-OVAL-5-7-tp4784920p5021246.html

Date Added: 2010-05-26 17:56:10
included in draft 2 of version 5.8

The key entity of the win-def:regkeyeffectiverights53_object should be nilable to allow effective rights to be collected on registry hives.

Date Added: 2010-05-26 17:55:43
included in draft 2 of version 5.8

As of draft 1 of version 5.8 there are many instances in the schema where the immediate xsd:sequence parent element of the object entity has a minOccurs="0".  

This is also true for their corresponding set elements (minOccurs = "0").  As a result, these objects will pass validation without having any child elements which will result in undefined behaviors for tool implementers. There are very few objects that should actually be permitted to have no child entities.

A few examples of this are:

independent-definitions-schema.xsd (environmentvariable_object)
Severity: info
Description: <xsd:sequence minOccurs="0" maxOccurs="1">
Start location: 438:43
Offset: 41504
Length: 42

independent-definitions-schema.xsd (textfilecontent54_object)
Severity: info
Description: <xsd:sequence minOccurs="0" maxOccurs="1">
Start location: 1101:43
Offset: 107300
Length: 42

independent-definitions-schema.xsd (textfilecontent_object)
Severity: info
Description: <xsd:sequence minOccurs="0" maxOccurs="1">
Start location: 1345:43
Offset: 132993
Length: 42

independent-definitions-schema.xsd (variable_object)
Severity: info
Description: <xsd:sequence minOccurs="0" maxOccurs="1">
Start location: 1504:43
Offset: 147837
Length: 42

independent-definitions-schema.xsd (xmlfilecontent_object)
Severity: info
Description: <xsd:sequence minOccurs="0" maxOccurs="1">
Start location: 1594:43
Offset: 156184
Length: 42

unix-definitions-schema.xsd (dnscache_object)
Severity: info
Description: <xsd:sequence minOccurs="0" maxOccurs="1">
Start location: 55:43
Offset: 6434
Length: 42

unix-definitions-schema.xsd (partition_object)
Severity: info
Description: <xsd:sequence minOccurs="0" maxOccurs="1">
Start location: 788:43
Offset: 78257
Length: 42

windows-definitions-schema.xsd (dnscache_object)
Severity: info
Description: <xsd:sequence minOccurs="0" maxOccurs="1">
Start location: 1063:43
Offset: 109317
Length: 42

Date Added: 2010-05-24 17:53:53
This should be considered a high priority issue that requires fixing in a minor release despite the fact that it breaks backwards compatibility. 

Technically speaking any existing content that included empty object declarations would no longer validate. However, these empty objects should really be considered invalid since a tool cannot possibly collect information specified by one of these empty objects.

Date Added: 2010-05-26 17:55:21
included in draft 2 of version 5.8

I received a request for a test that would allow OVAL content authors to verify rpms similar to the behavior supported by the rpm -V command. Do we need this capability in OVAL?

Assuming we had such a test will we actually use it?


Below is a bit more background and a mock up of how we might implement this test:
rpmverify_test - holds a reference to a rpmverify_object and rpmverify_state.

rpmverify_object
 - name - the name of the package to test. 
          Could be a regex to allow checking of all, or sets of rpms.
 - filepath - the full path to a file in a package.
          Could be a regex to allow checking of all files or sets of files.

rpmverify_state
 - name - string
 - filepath - string
 - size_differs - possible values = pass/fail/not performed
 - mode_differs - possible values = pass/fail/not performed
 - md5_differs - possible values = pass/fail/not performed
 - device_differs - possible values = pass/fail/not performed
 - link_mismatch - possible values = pass/fail/not performed
 - ownership_differs - possible values = pass/fail/not performed
 - group_differs - possible values = pass/fail/not performed
 - mtime_differs - possible values = pass/fail/not performed
 - capabilities_differ - possible values = pass/fail/not performed
 - attribute_marker - possible values = configuration file/documentation file/
                                        ghost file/license file/readme file


RpmVerifyBehaviors
These behaviors will be defined to allow for tailoring of the data collection process. These behaviors will essentially mirror all needed flags on the rpm -V command. 
 - nodeps - (boolean) - Don't verify dependencies of packages. 
 - nodigest - (boolean) - Don't verify package or header digests when reading. 
 - nofiles - (boolean) - Don't verify any attributes of package files. 
 - noscripts - (boolean) - Don't execute the %verifyscript scriptlet (if any). 
 - nosignature - (boolean) - Don't verify package or header signatures when reading. 
 - nolinkto - (boolean) - Don't verify symbolic links attribute.
 - nomd5 - (boolean) - Don't verify the file md5 attribute.
 - nosize - (boolean) - Don't verify the file size attribute.
 - nouser - (boolean) - Don't verify the file owner attribute.
 - nogroup - (boolean) - Don't verify the file group owner attribute.
 - nomtime - (boolean) - Don't verify the file mtime attribute.
 - nomode - (boolean) - Don't verify the file mode attribute.
 - nordev - (boolean) - Don't verify the file rdev attribute.
 - noconfigfiles - (boolean) - skip files that are marked with the %config attribute marker.
 - noghostfiles - (boolean) - skip files that are maked with %ghost attribute marker.

The full discussion on this topic can be viewed in the archives here:
http://making-security-measurable.1364806.n2.nabble.com/do-we-need-a-linux-def-rpmverify-test-tp5099612p5099612.html

Date Added: 2010-05-26 17:49:24
included in draft 2 of version 5.8

all schema files currently assume the default character encoding. This should be explicitly set to UTF-8

n/a

The original request for this issue was in the context of the inet listening servers test and what types of addresses it supports. In response to a clarification the following questions were asked:

"If you have an ipv6 mapped ipv4 address and you send a query with an ipv4 address, what is the expected result? And in the case of a query containing an ip6 mapped ipv4 address?"

As of version 5.7 the expected results would be that the IP addresses would not match as they are different string values (e.g. d.d.d.d (IPv4 representation) vs. ::FFFF:d.d.d.d (IPv6 mapped IPv4 representation)).


However, since there is a way to convert between a IPv4 address and a IPv6 mapped IPv4 address (the IPv6 mapped IPv4 address is just ::FFFF:d.d.d.d where d.d.d.d is the IPv4 address) it seems that we may want to consider adding datatypes to represent both IPv4 addresses and IPv6 addresses?  The addition of
these datatypes would ensure that well-formed IP addresses are being parsed as
well as provide information as to how the IP addresses should be converted to see if they are equivalent.  Would the addition of datatypes to represent IP addresses be beneficial to the language?  Are there other possible solutions to consider?


In order to handle the mapping between ipv4 and ipv6 addresses should we consider adding datatypes to the 5.8 release of oval? Adding datatypes will allow us to define how to compare these addresses to ensure that they are properly and consistently compared. Without a set datatype here we can do string equality operations, but cannot equate the two different types of addresses to each other. 

This topic was discussed on the mailing list here:
http://making-security-measurable.1364806.n2.nabble.com/Comments-on-OVAL-5-7-tp4784920p4932736.html

Date Added: 2010-08-19 03:37:58
These changes will be included in the Version 5.8 Release Candidate 1.

The visdkmanagedobject_test will be used to check information about Managed Objects in the VMware Infrastructure.

Date Added: 2010-06-25 11:39:22
For more information see:
http://making-security-measurable.1364806.n2.nabble.com/Proposed-ESX-test-for-5-8-tp5220509p5220509.html

Date Added: 2010-07-01 15:22:10
This update will be included in version 5.8 draft 3.

In version 5.6 the variable_objectKeyRef and variable_stateKeyRef keyrefs were added to the oval-definitions-schema.xsd. These keyrefs use the independent schema and the independent schema uses the oval-definitions-schema. 

Here are the keyrefs as they are defined in the version 5.7 oval-definitions-schema:

<xsd:keyref name="variable_objectKeyRef" refer="oval-def:variableKey">
    <xsd:annotation>
        <xsd:documentation>Require each variable reference in a variable_object to refer to a valid variable id.</xsd:documentation>
    </xsd:annotation>
    <xsd:selector xpath=".//ind-def:variable_object"/>
    <xsd:field xpath="ind-def:var_ref"/>
</xsd:keyref>
<xsd:keyref name="variable_stateKeyRef" refer="oval-def:variableKey">
    <xsd:annotation>
        <xsd:documentation>Require each variable reference in a variable_state to refer to a valid variable id.</xsd:documentation>
    </xsd:annotation>
    <xsd:selector xpath=".//ind-def:variable_state"/>
    <xsd:field xpath="ind-def:var_ref"/>
</xsd:keyref>


The possible solutions are to remove the keyrefs and use Schematron rules in the independent-definitions-schema, or attempt to refactor the keyrefs such that they do not use the independent-definitions-schema namespace.  

Date Added: 2010-07-02 12:29:30
Upon further investigation the existing keyrefs cannot be moved to the independent-definitions-schema because then the key they refer to is out of scope. The subset of xpath that is supported for a keyref selector and keyref field does not allow for wild cards. This means that the keyrefs cannot be written to simply not use the ind-def namespace. As a result the only solution seems to be to drop the keyrefs and create two new Schematron rules in the independent-definitions-schema to enforce the reference to a variable that exists in the document.

In order allow for more flexibility in the contents of an OVAL Results document directives should be tailorable by definition class. This was a topic for discussion during the oval discussion at 2010 developer days.

Date Added: 2010-07-01 16:52:00
This topic was also discussed on the OVAL Developer List. Archives of this discussion can be found here:
http://making-security-measurable.1364806.n2.nabble.com/OVAL-Results-Directives-by-definition-class-tp5244195p5244195.html

Date Added: 2010-07-02 01:24:54
This update will be included in version 5.8 draft 3.

To fully utilize OVAL Results Directives a schema should be created capture the input set of directives that an OVAL Definition consumer should utilize when producing OVAL Results. Without this format there is not way to to a set of OVAL Definition Evaluators that a given definition should be evaluated and the corresponding results should be produced in a specific way.

Date Added: 2010-08-03 18:55:16
More information on this proposal can be found here:
http://making-security-measurable.1364806.n2.nabble.com/OVAL-Results-Input-OVAL-Directives-Document-Format-tp5330891p5330891.html

This new schema will be added to draft 6 of version 5.8

As of draft 3 of version 5.8 the behaviors used for controlling file searching and collection are defined 17 times. These behaviors need to be consolidated so that they are defined once or maybe once per component schema since we don't typically allow for dependencies between component schemas.

Are there other behaviors that should be consolidated? Maybe the windows registry related behaviors?

Date Added: 2010-07-20 16:19:06
Consolidated the file related behaviors so that the behaviors are only defined once per component schema. Also consolidated the registry related behaviors in the windows-definitions-schema so that the behaviors are only defined once.

This change will be included in version 5.8 draft 5.

The SeTrustedCredManAccessPrivilege is not currently included in the win-def:accesstoken_state and win-def:accesstoken_item.

See:
http://making-security-measurable.1364806.n2.nabble.com/Missing-Privilege-under-accestoken-state-tp5329290p5329290.html

Date Added: 2010-07-23 14:43:53
This change will be included in draft 5 of version 5.8

ndd_object
------------
- device: string - the name of the device to examine. For example, /dev/tcp
- parameter: string - the name of the parameter for example, ip_forwarding

ndd_state
-----------
- device: string
- parameter: string
- value: string - the value to compare to

This is of course based on the solaris man page for /usr/sbin/ndd:

http://docs.sun.com/app/docs/doc/816-0211/6m6nc671g?a=view

Finally, given that this test will apply to both HP-UX and Solaris and not generically to unix I will be creating parallel tests in the
hpux-definitions-schema and the solaris-definitions-schema.

Date Added: 2010-08-18 19:52:56
This test is also closely related to the aix-def:no_test.

Date Added: 2010-08-18 19:53:51
This test will be included in the Version 5.8 Release Candidate 1.

Date Added: 2010-09-09 19:43:50
An instance entity should be added to the sol-def:ndd_state and sol-sc:ndd_item. This entity will be used to distinguish different devices on the system that may have multiple instances each with their own set of parameter/value pairs.

The following items have been corrected as a result of comparing item, state, and object entity names, types, and multiplicity:
- corrected typo in catos-def:version55_state/switch_series entity name
- corrected type of esx-def:patch_state/patch_number and esx-:patch_item/patch_number entities
- corrected type of win-def:sharedresource_item/shared_type entity
- corrected type of unix-sc:sccs_item/module_name and module_type entities
- corrected type of unix-def:routingtable_state/flags entity
- corrected type and multiplicity of sol-def:packagecheck_object/filepath entity
- corrected type of pixos-sc:version_item/pix_major_release entity
- corrected type of macos-def:diskutil_object/filepath entity
- corrected type of ind-def:sql_state/engine entity
- corrected type of ind-def:sql57_state/engine entity
- added missing hpux-sc:patch_item/patch_name entity
- corrected name of hpux-sc:patch_item/patch_base entity
- corrected multiplicity of hpux-def:trusted_state/username entity to have minOccurs="0"
- corrected multiplicity of ios-def:global_state/global_command entity to have minOccurs="0"
- corrected multiplicity of macos-def:diskutil_object/filepath entity to have minOccurs="1"
- corrected multiplicity of
sp-def:spwebapplication_state/deletelistitems entity to have maxOccurs="1"
- corrected multiplicity of
sp-def:spwebapplication_state/deleteversions entity to have maxOccurs="1"
- corrected multiplicity of
sp-def:spwebapplication_state/editlistitems entity to have maxOccurs="1"
- corrected multiplicity of
sp-def:spwebapplication_state/open entity to have maxOccurs="1"
- corrected multiplicity of
sp-def:spwebapplication_state/useremoteapis entity to have maxOccurs="1"
- corrected multiplicity of 
sp-sc:spantivirussettings_item/spwebservicename entity to have minOccurs="0"
- corrected multiplicity of 
sp-sc:spantivirussettings_item/spfarmname entity to have minOccurs="0"
 - corrected multiplicity of 
sp-sc:spcrawlrule_item/spsiteurl entity to have minOccurs="0"
- corrected multiplicity of 
sp-sc:spjobdefinition_item/webappuri entity to have minOccurs="0"

These corrections will be available in Version 5.8 Release Candidate 2.

n/a

Change the maxOccurs attribute value in win-sc:sharedresource_item/win-sc:max_uses from "unbounded" to "1" as the max_uses entity is simply a single integer value. For more information, please consult Microsoft's documentation at http://msdn.microsoft.com/en-us/library/bb525408(VS.85).aspx. Currently, this is being classified as a tracker item for the Version 6 release as it could potentially invalidate existing OVAL content.

Date Added: 2010-08-05 13:47:09
This change will be included in draft 6 of version 5.8.

Add support for a windows service test.

Date Added: 2010-03-10 18:02:39
assume the test will be modeled after this api:

http://msdn.microsoft.com/en-us/library/ms682640(VS.85).aspx

Date Added: 2010-07-09 18:55:54
Proposal of schema changes from the oval-developer-list:

win-def:service_object
        service_name (string)

win-def:service_state
        service_name (string)
        display_name (string)
        description (string)
        service_type (win-def:EntityStateServiceTypeType)
        start_type (win-def:EntityStateServiceStartTypeType)
        current_state (win-def:EntityStateServiceCurrentStateType)
        controls_accepted (win-def:EntityStateServiceControlsAcceptedType)
        start_name (string)
        path (string)
        pid (int)
        service_flag (boolean)
        dependencies (string)

win-sc:service_item
        service_name (string)
        display_name (string)
        description (string)
        service_type (win-sc:EntityItemServiceTypeType - unbounded)
        start_type (win-sc:EntityItemServiceStartTypeType)
        current_state (win-sc:EntityItemServiceCurrentStateType)
        controls_accepted (win-sc:EntityItemServiceControlsAcceptedType - unbounded)
        start_name (string)
        path (string)
        pid (int)
        service_flag (boolean) 
        dependencies (string - unbounded)


A brief description of each entity is provided below.

        service_name      - the service name as stored in the SCM database
        display_name      - the service name as used in tools such as Services
        description       - a description of the service
        service_type      - the type of the service
        start_type        - the startup options of the service
        current_state     - the current state of the service
        controls_accepted - specifies the control codes that the service accepts
        start_name        - indicates the account under which the service should run
        path              - the path to the binary of the service
        pid               - the process ID of the service
        service_flag      - indicates if the service is in a system process that must always run or if the service is in a non-system
                           process or is not running
        dependencies      - the dependencies of this service on other services

In addition, we will also want to add the following enumerations.

win-def:EntityStateServiceTypeType / win-sc:EntityItemServiceTypeType

        SERVICE_FILE_SYSTEM_DRIVER (0x00000002)
        SERVICE_KERNEL_DRIVER (0x00000001)
        SERVICE_WIN32_OWN_PROCESS (0x00000010)
        SERVICE_WIN32_SHARE_PROCESS (0x00000020)
        SERVICE_INTERACTIVE_PROCESS (0x00000100)

win-def:EntityStateServiceStartTypeType / win-sc:EntityItemServiceStartTypeType

        SERVICE_AUTO_START (0x00000002)
        SERVICE_BOOT_START (0x00000000)
        SERVICE_DEMAND_START (0x00000003)
        SERVICE_DISABLED (0x00000004)
        SERVICE_SYSTEM_START (0x00000001)

win-def:EntityStateServiceCurrentStateType / win-sc:EntityItemServiceCurrentStateType

        SERVICE_CONTINUE_PENDING (0x00000005)
        SERVICE_PAUSE_PENDING (0x00000006)
        SERVICE_PAUSED (0x00000007)
        SERVICE_RUNNING (0x00000004)
        SERVICE_START_PENDING (0x00000002)
        SERVICE_STOP_PENDING (0x00000003)
        SERVICE_STOPPED (0x00000001)

win-def:EntityStateServiceControlsAcceptedType / win-sc:EntityItemServiceControlsAcceptedType

        SERVICE_ACCEPT_NETBINDCHANGE (0x00000010)
        SERVICE_ACCEPT_PARAMCHANGE (0x00000008)
        SERVICE_ACCEPT_PAUSE_CONTINUE (0x00000002)
        SERVICE_ACCEPT_PRESHUTDOWN (0x00000100)
        SERVICE_ACCEPT_SHUTDOWN (0x00000004)
        SERVICE_ACCEPT_STOP (0x00000001)
        SERVICE_ACCEPT_HARDWAREPROFILECHANGE (0x00000020)
        SERVICE_ACCEPT_POWEREVENT (0x00000040)
        SERVICE_ACCEPT_SESSIONCHANGE (0x00000080)
        SERVICE_ACCEPT_TIMECHANGE (0x00000200)
        SERVICE_ACCEPT_TRIGGEREVENT (0x00000400)

These changes will be available in Draft 4 of Version 5.8. 

In the independent-system-characteristics schema file there are a few instances where we have made copy and paste errors (ind-def instead of ind-sc). The specific errors can be seen below.

Severity: info
Description: <sch:pattern id="ind-def_envitemvalue">
Start location: 148:63

Severity: info
Description: <sch:rule context="ind-def:environmentvariable_item/ind-def:value">
Start location: 149:70

Severity: info
Description: <sch:rule context="ind-def:environmentvariable_item/ind-def:value">
Start location: 149:103

Severity: info
Description: <sch:rule context="ind-def:ldap_item">
Start location: 174:45

Severity: info
Description: <sch:pattern id="ind-def_ldapitemvalue">
Start location: 249:63

Severity: info
Description: <sch:rule context="ind-def:sql_item">
Start location: 364:45

Severity: info
Description: <sch:pattern id="ind-def_sqlitemresult">
Start location: 426:63

Severity: info
Description: <sch:pattern id="ind-def_txtitemsubexpression">
Start location: 620:63

Date Added: 2010-05-26 17:55:58
included in draft 2 of version 5.8

Request from Steve Grubb:

3) selinux-booleans: name, status. Similar to running "getsebool -a". SE 
   Linux booleans are used for swinging in and out policy options based on 
   local customizations. For example, you may have a web server that does 
   nothing but static content, so you would tell SE linux to not allow 
   cgi-bin apps. But if one day the boolean was found to be on...you would 
   want to know that since its change the risk profile of the system. 

Initial proposal to the oval-developer-list:

selinux_boolean_object:
  -name (string)

selinux_boolean_state:
  -name (string)
  -current_status (boolean)
  -pending_status (boolean)

selinux_boolean_item:
  -name (string)
  -current_status (booean)
  -pending_status (boolean)

Additional information regarding this proposal can be found on the
oval-developer-list archives at the following link.

http://making-security-measurable.1364806.n2.nabble.com/RFC-New-items-for-Linux-tp4785229ef20093.html.

Date Added: 2010-05-26 17:50:41
included in draft 2 of version 5.8. Based on developer list discussions, this item may be dropped from the next draft as it may not be needed.

Date Added: 2010-06-01 18:34:55
This test is not currently being considered for removal from the next draft.  The comment above, regarding the removal of this test, was meant for the linux-def:sestatus_test.

Request from Steve Grubb:

5) partition: fs_type, name, mount options, total space, space_used, space 
left. This information can be derived by the statfs() syscall. The proposed 
FDCC content spells out some mount options that should be used. Its also not 
always possible to get this from /etc/fstab since udev policy controls hotplug 
events. 

Initial proposal of schema changes to the oval-developer-list:

partition_object 
  -name (string) 

partition_state 
  -name          (string) 
  -fs_type       (string) 
  -mount_options (string) 
  -total_space   (integer) 
  -space_used    (integer) 
  -space_left    (integer) 

partition_item 
  -name          (string) 
  -fs_type       (string) 
  -mount_options (string) (0-unbounded) 
  -total_space   (integer) 
  -space_used    (integer) 
  -space_left    (integer) 

Additional information regarding this proposal can be found on the
oval-developer-list archives at the following link.

http://making-security-measurable.1364806.n2.nabble.com/RFC-New-items-for-Linux-tp4785229ef20093.html

Date Added: 2010-05-26 17:49:35
included in draft 2 of version 5.8

Date Added: 2010-08-17 18:24:36
We need to add a device and uuid entity to the partition_item and partition_state. For additional information, please see the following link.

http://making-security-measurable.1364806.n2.nabble.com/Version-5-8-Draft-4-is-now-available-tp5276709.html

Date Added: 2010-08-18 22:56:57
These changes will be included in the Version 5.8 Release Candidate 1.

An unbounded filter element should be added to all objects in the OVAL Language 
such that the set of items collected by an object can be fine-tuned. This will allow content authors to collect only the items that they are interested and will result in smaller OVAL System Characteristics and Results files. This will also reduce the resources needed by tools to process the set of collected items. An example of an object that only collects world-writable files, using a filter element, can be seen below.

<file_object id="oval:sample:obj:1">
    <path operation="pattern match">.*</path>
    <filename operation="pattern match">.*</filename>
    <filter action="include">oval:sample:ste:1</filter>
</file_object>

<file_state id="oval:sample:ste:1">
    <owrite datatype="boolean">1</owrite>
</file_state>

For more information on this topic, please see the following links.

2010 OVAL Developer Days Minutes - Optimizing Item Searches
http://oval.mitre.org/oval/about/OVAL_Developer_Days_2010_Minutes.pdf

Original Discussion from oval-developer-list 
http://making-security-measurable.1364806.n2.nabble.com/oval-object-criteria-tp4931198.html

Date Added: 2010-07-09 20:12:53
This change will be available in Draft 4 of Version 5.8.

Request from Vladimir Giszpenc:

>Getting runtime values of GConf settings is another possible test we
>should consider.  Using an API would allow us not to care what file the
>setting actually lives in.  

Additional information regarding this proposal can be found on the
oval-developer-list archives at the following link.

http://making-security-measurable.1364806.n2.nabble.com/RFC-New-items-for-Linux-tp4785229p4785936.html

Date Added: 2010-08-06 02:50:43
The unix-def:gconf_test will be available in Draft 6 of Version 5.8.

In the Windows component schema, specifically the audited permissions and effective rights tests, we use the term ACL.  However, the term ACL can be ambiguous as there are two types of ACLs; a discretionary access control list (DACL) and a system access control list (SACL). Therefore, where possible, the documentation should be more specific.

Date Added: 2010-07-10 01:47:32
this change will be included in draft 4 of version 5.8

A request has been made to add a drive_type entity to the win-def:volume_state and the win-def:volume_item. The addition of this entity would require the following enumerations to be added.

win-def:volume_state / win-def:entitydrivetype
    DRIVE_UNKNOWN (0)
    DRIVE_NO_ROOT_DIR (1)
    DRIVE_REMOVABLE (2)
    DRIVE_FIXED (3)
    DRIVE_REMOTE (4)
    DRIVE_CDROM (5)
    DRIVE_RAMDISK (6)

win-sc:volume_item / win-sc:entitydrivetype
    DRIVE_UNKNOWN (0)
    DRIVE_NO_ROOT_DIR (1)
    DRIVE_REMOVABLE (2)
    DRIVE_FIXED (3)
    DRIVE_REMOTE (4)
    DRIVE_CDROM (5)
    DRIVE_RAMDISK (6)

Additional information regarding this proposal can be found on the
oval-developer-list archives at the following link.

http://making-security-measurable.1364806.n2.nabble.com/volume-test-Microsoft-System-Error-21-The-device-is-not-ready-tp5031095p5275216.html

Date Added: 2010-07-13 00:32:40
This change will be available in Draft 5 of Version 5.8.

Please see the following link for more information.

http://making-security-measurable.1364806.n2.nabble.com/A-couple-of-tests-of-OS-X-tp5369043.html

Date Added: 2010-08-18 22:56:27
This test will be included in the Version 5.8 Release Candidate 1.

Please see the following link for additional information.

http://making-security-measurable.1364806.n2.nabble.com/Proposal-for-Solaris-Pkgchk-based-Test-tp5351678.html

Date Added: 2010-08-18 22:56:17
This test will be included in the Version 5.8 Release Candidate 1.

The win-sc:regkeyauditedpermissions_item does not currently allow for the xsi:nil attribute on the win-sc:regkeyauditedpermissions_item/win-sc:key entity even though the xsi:nil attribute can be specified on the win-def:regkeyauditedpermissions53_object/win-def:key entity. The win-sc:regkeyauditedpermissions_item/win-sc:key entity should be fixed to allow for the use of the xsi:nil attribute. 

Date Added: 2010-09-08 18:43:26
This change will be included in the Version 5.8 Release Candidate 2.

The macos-sc:pwpolicy_item does not currently allow for the
xsi:nil attribute on the macos-sc:pwpolicy_item/macos-sc:username, macos-sc:pwpolicy_item/macos-sc:userpass, and macos-sc:pwpolicy_item/macos-sc:directory_node entities even though the xsi:nil attribute can be specified on the macos-def:pwpolicy_object/macos-def:username, macos-def:pwpolicy_object/macos-def:userpass, and macos-def:pwpolicy_object/macos-def:directory_node entities. The username, userpass, and directory_node entities in the macos-sc:pwpolicy_item should be fixed to allow for the use of the xsi:nil attribute. 

Date Added: 2010-09-08 19:01:35
These changes will be included in the Version 5.8 Release Candidate 2.

The linux-sc:selinuxsecuritycontext_item does not currently allow for the xsi:nil attribute on the linux-sc:selinuxsecuritycontext_item/linux-sc:filename entity even though the xsi:nil attribute can be specified on the linux-def:selinuxsecuritycontext_object/linux-def:filename entity. The source entity in the linux-sc:selinuxsecuritycontext_item should be fixed to allow for the use of the xsi:nil attribute. 

Date Added: 2010-09-08 19:01:17
This change will be included in the Version 5.8 Release Candidate 2.