Version 5.8 (Archived)

This page provides information on the proposed changes to the OVAL Language. All information about the new version is included in this centralized location. The major highlights of the release are listed below:

  • Refactoring of datatype constraints on all entities resulting in removal of many schematron rules.
  • Added support for unbounded filter elements in objects.
  • Added an explicit mapping of tests, objects, states, and items.
  • Added an OVAL Directives schema to allow for a tool to supply a set of directives to more easily specify desired results content.
  • Enhanced OVAL Results directives to allow for more flexibility in allowed results content.
  • Added many new tests and entities to the Windows, UNIX, Linux, Solaris, and Mac OS component schemas.
  • Corrected many inconsistencies across item, object, and state entity names, types, and multiplicity under the new Exceptions provision in the Versioning Methodology.

A complete listing of the tests available in this release can be found here.

Downloads

Includes downloads for the Version 5.8 Definition Schema, System Characteristics Schema, Results Schema, and Element Dictionaries.

KEY
Complete Schema - has all documentation embedded and the Schematron mark-up.
Minimal Schema - includes the raw xml schema only.
Schematron - a schema that can provide additional validation of OVAL V5 documents.
Documentation html - element dictionaries, which users can elect to view in a browser or save.
All files zip - all files zipped together to allow for one simple download.
xsd/sch - a user can either right click to download the file or left click to open the file in their default viewer.
Deprecation Listing - a list of all deprecated language constructs.

OVAL Definition Schema Downloads

File Name Complete Schema Minimal Schema Documentation Schematron Deprecation Listing
All Files zip zip zip zip | sch -
Core xsd xsd html - -
Common xsd xsd html - html
Independent xsd xsd html - html
Apache xsd xsd html - html
Apple Macintosh xsd xsd html - -
Cisco CatOS xsd xsd html - html
Cisco IOS xsd xsd html - html
Cisco PixOS xsd xsd html - -
FreeBSD xsd xsd html - -
HP-UX xsd xsd html - html
IBM AIX xsd xsd html - -
Linux xsd xsd html - -
Microsoft Windows xsd xsd html - html
SharePoint xsd xsd html - -
Sun Solaris xsd xsd html - html
UNIX xsd xsd html - html
Vmware ESX xsd xsd html - html
 

OVAL System Characteristics Schema Downloads

File Name Complete Schema Minimal Schema Documentation Schematron Deprecation Listing
All Files zip zip zip zip | sch -
Core xsd xsd html - -
Common xsd xsd html - html
Independent xsd xsd html - html
Apache xsd xsd html - html
Apple Macintosh xsd xsd html - -
Cisco CatOS xsd xsd html - html
Cisco IOS xsd xsd html - html
Cisco PixOS xsd xsd html - -
FreeBSD xsd xsd html - -
HP-UX xsd xsd html - -
IBM AIX xsd xsd html - -
Linux xsd xsd html - -
Microsoft Windows xsd xsd html - html
SharePoint xsd xsd html - -
Sun Solaris xsd xsd html - -
UNIX xsd xsd html - -
Vmware ESX xsd xsd html - html
 

OVAL Results Schema Downloads

File Name Complete Schema Minimal Schema Documentation Schematron Deprecation Listing
All Files zip zip zip zip | sch -
Core xsd xsd html - -
Common xsd xsd html - html
 

OVAL Variables Schema Downloads

File Name Complete Schema Minimal Schema Documentation Schematron Deprecation Listing
All Files zip zip zip zip | sch -
Core xsd xsd html - -
Common xsd xsd html - html
 

OVAL Directives Schema Downloads

File Name Complete Schema Minimal Schema Documentation Schematron Deprecation Listing
All Files zip zip zip zip | sch -
Core xsd xsd html - -
Common xsd xsd html - html
Results xsd xsd html - -
 

Example XML Stylesheets

File Name Description
results_to_html.xsl The results_to_html stylesheet converts an OVAL Results document into a more readable html format.
minimal_schema.xsl The minimal_schema stylesheet removes all annotation elements from the OVAL Schema leaving only the minimal schema.
element_dictionary.xsl The element_dictionary stylesheet creates documentation files from the OVAL Schema.
reference_mapping.xsl The reference_mapping stylesheet creates a map between each OVAL Definition in a document and a specified reference source.
Back to top

New in Version 5.8

Version 5.8 of the Official OVAL Schema is a direct result of feedback from the OVAL Community. This will be a minor version change and may require some new development by tools that support earlier versions of the Language. The changes pending to the different schemas are outlined below. "Open" status means the item is under consideration or being worked upon and "Closed" status means that the item has been incorporated and work on it is completed. For full deatils on a particular item please expand the item by clicking the + icon in the left column.

Tracker items in this version include:

ID Title Status Date Opened Resolution
25088 Revise "datatype" attribute declarations and associated Schematron rules Closed 2010-03-02 Fixed
Priority: Medium High | Category: Definition Schemas | Date Closed: 2010-05-07 12:33:19
Details:
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.
Follow-ups:
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

25942 add support for "extended attributes" on files. Closed 2010-05-05 Fixed
Priority: Medium High | Category: n/a | Date Closed: 2010-08-03 15:19:39
Details:
See http://en.wikipedia.org/wiki/Extended_file_attributes for a brief explanation of extended attributes. They are used by several operating systems, and security related information is often stored within them. OVAL needs a way to inspect them.

Specifically, SE Linux uses them to store security context, and POSIX Access Control Lists (ACLs) on Linux are implemented using extended attributes. However, it has been determined that OVAL should implement these items as first class entities rather than relying on extended attributes.

See the OVAL Developer list archives for further discussions on this topic.
Follow-ups:
Date Added: 2010-05-11 17:30:42
Note need to be added to the documentation stating that the OVAL definition for Extended Attributes does not include what Solaris calls Extended Attributes.

Date Added: 2010-05-17 17:08:32
Draft 2 of version 5.8 will include a solution like the following: Create a new fileextendedattribute_test. This new test would have the following object and state: unix-def:fileextendedattribute_object - path - filename - attribute_name - the name of an attribute. Could be a pattern match or variable to allow searching for sets of names. unix-def:fileextendedattribute_state - path - filename - attribute_name - value unix-sc:fileextendedattribute_item - path - filename - attribute_name - value

23829 xinetd_item port entity should have integer type Closed 2009-10-14 Fixed
Priority: Medium | Category: System Characteristics Schemas | Date Closed: 2010-08-12 10:38:11
Details:
The port entity of xinetd_item should have integer type, e.g. xsd:integer.
Follow-ups:
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.

25238 process_object needs a pid entity Closed 2010-03-08 Fixed
Priority: High | Category: Definition Schemas | Date Closed: 2010-06-07 18:35:19
Details:
Currently process_object has one entity, 'command'.  This is a poor choice for an object entity, since there can be many processes which were started from the same command.  The real identifier for a process is the process ID, which we currently have as an item entity.  We need to promote this to an object entity.
Follow-ups:
Date Added: 2010-05-26 17:48:59
included in draft 2 of version 5.8

Date Added: 2010-06-07 18:35:19
Adding a pid entity to the process_object will invalidate existing content and break backward compatibility. We have created a new process58_test, process58_object, and process58_state in order to add the pid entity and not invalidate existing content. The process58_object will collect process_items. This change will be included in draft 3 of version 5.8.

19662 change several unix-sc item entities to be based on ints rather than strings Closed 2009-05-06 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-08-12 10:38:10
Details:
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.
Follow-ups:
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.

23995 add capability to specify test result other than unknown, true or false Closed 2009-10-31 Rejected
Priority: High | Category: n/a | Date Closed: 2010-06-29 18:03:43
Details:
Users would like to have a definition evaluate to true in one condition, false in another, and not applicable in yet another condition. 

The oval-res:ResultEnumeration defines 6 results possible result values. Do users need to be able to force evaluation to additional values beyond not applicable?

One of the posts that requested this is here: 
http://n2.nabble.com/Thoughts-about-compliance-assessments-result-tp3830946ef20093.html
Follow-ups:
Date Added: 2010-03-10 13:33:38
http://n2.nabble.com/Oval-toc-heck-for-Windows-Services-Status-tp4623881p4708988.html

Date Added: 2010-06-10 13:25:20
see also: http://n2.nabble.com/Thoughts-about-compliance-assessments-result-tp3830946ef20093.html

Date Added: 2010-06-29 18:03:42
This feature request was a topic of discussion at 2010 OVAL Developer Days. The group strongly supported not addressing this feature request and noted tow important items: 1- OVAL Definitions should be thought of as granular checks and as such, the higher level context should determine which checks should be applied to a system. 2- OVAL Results currently provide adequate data to determine if a false test result was due to an existence_check failure or a state evaluation failure.

25751 add pid entity to the ind-def:environmentvariable_object Closed 2010-04-17 Fixed
Priority: High | Category: n/a | Date Closed: 2010-08-02 19:06:52
Details:
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. 
Follow-ups:
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

25752 add support for additional hash algorithms to the ind-def:filehash_test Closed 2010-04-17 Fixed
Priority: High | Category: n/a | Date Closed: 2010-07-06 16:04:40
Details:
>
>* The filehash_item asks for a md5sum to be calculated. If the system is in
>FIPS-140 certified mode, md5 is a forbidden hash algorithm. So, should md5 be
>deprecated at this point? Then if you look at the NIST Hash Migration policy,
>http://csrc.nist.gov/groups/ST/hash/policy.html, it says that the SHA2 family
>of hashes should be used from 2010 forward. NIST is also having a new hash
>algorithm contest, so there will be a new hash at some point in the future.
>Should this item be amended so that a hash algorithm can be specified in the
>test? Perhaps defaulting to SHA256 in the absence of anything.
>

Clearly our supported hash choices are dated. I don't think we want to deprecate MD5 for some use cases it is still perfectly valid. If a system is in FIPS mode and a tool running on that system is supplies an oval definition that want to examine the md5 of a file the tool should be able to simply not collect the file's md5. The fact that the tools did not collect the md5 could be recorded on the entity in the item by setting the status attribute to "not collected". The tool could even add a message to the item stating that the md5 could not be collected because md5 is forbidden when running in fips mode.

OPTION 1 - Add Entities Per Hash Algorithm
As of version 5.6 and soon to be version 5.7 only md5 and sha1 are supported. The standard approach to adding support for more hashing algorithms would be to add a new entity to the filehash_state and filehash_item to support each additional hashing algorithm. If we take this approach we would of course have an ever growing list of entities in the filehash_sate. The fact that the list grows is not a huge concern to me since really this list will not grow very fast, and we can add new entities with each minor release if needed. If we take this approach we end up with filehash_items potentially including a long list of hashes. There is nothing that states that a tool mush support all these hashes, and there is nothing that says that a tool must actually collect all of the possible hashes. If the list gets long and tools do try to collect all the supported hashes they will run into performance issues. One benefit of this approach is that we can be very explicit and define elements for each supported hash algorithm. This will facilitate interoperability by allowing tools to essentially code directly to a defined set of elements. 

OPTION 2 - Add Hash Type to Object Specification
I think you have suggested that that the type of hash be specified in the object like:

<filehash_object>
  <path>/foo</path>
  <filename>bar.txt</filename>
  <hash_type>sha256</hash_type>
</filehash_object>

This would result in a new filehash_state that looked like:

<filehash_state>
  <path>/foo</path>
  <filename>bar.txt</filename>
  <hash_type>sha256</hash_type>
  <hash>123412341234</hash>
</filehash_state>

You have suggested another approach that would allow for a possibly more dynamic list of hashes to be supported, and provided a suggestion to tool implementers that only one specific hash should be collected. I like the sound of this suggestion because it clearly states to tool implementers that they need only collect a specific hash and I think it fits with the notion of an OVAL Object because the three entities in the example filehash_object would uniquely identify a file with its specific hash. My concern with this suggestion is around the content of the <hash_type> entity. I would like to restrict the set of possible values and explicitly define what each of those values means to ensure content interoperability. This would lead me to restrict the possible values of the element to a defined enumeration. If we define an enumeration, the set of supported hash algorithms is not any more dynamic than simply adding a new state entity for each new hash algorithm.

In considering both options the first option is really just adding new entities to an existing test. Option 2 suggests that we deprecate the current test and create a new test that includes the hash type as a parameter in the object and deprecating the existing filehash_test. Option 2 suggests a bit of an implementation change for tools and is a fairly simple concept for content authors to pick up. Option 2 may lead tool implementers towards a more efficient solution by reducing the hashing that a tool might do on a given file down to only the requested hash.

I am not sure what the best approach is here and would be interested in how others would like to see us proceed. Either way I think we clearly need to add support for more hashing algorithms in the next release. 
Follow-ups:
Date Added: 2010-04-20 13:51:17
consider the following resource: http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html

Date Added: 2010-05-07 18:08:54
More information can be found in the mailing list archives here: http://making-security-measurable.1364806.n2.nabble.com/Comments-on-OVAL-5-7-tp4784920p4916033.html

Date Added: 2010-05-26 17:50:54
included in draft 2 of version 5.8

Date Added: 2010-06-08 12:08:13
Still need to consider the list of supported hash algorithms. Are there others that we should support?

Date Added: 2010-07-06 16:04:40
There are no outstanding requests for additional hash algorithms.

25790 add new lin-def:if_listeners_test for AF_PACKET family Closed 2010-04-20 Fixed
Priority: High | Category: n/a | Date Closed: 2010-07-12 17:55:08
Details:
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."
Follow-ups:
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.

25945 add result directive to allow for lighter weight results with ability to track causal information Closed 2010-05-05 Deferred
Priority: High | Category: Result Schemas | Date Closed: 2011-01-12 11:40:53
Details:
Currently OVAL Results can be tailored through the use of directives to control various levels of result verbosity. The ability to specify a lightweight set of results that includes only information about issues detected and what caused the definition to report the issue is needed. Consider the following definition criteria:

Example definition id=123
- non compliant config on windows xp or
  - widows xp is installed and
  - minimum password length is 8 or more

- non compliant config on windows vista or
  - widows vista is installed and 
  - minimum password length is 8 or more

- non compliant config on windows 7
  - widows 7 is installed and
  - minimum password length is 8 or more 

If my system is running windows 7 in my lightweight results i would like to see something like:

definition 123: result = false, observed value = 6, expected value >= 8
Follow-ups:
Date Added: 2010-08-04 11:01:02
This topic was discussed during the oval session at the 2010 Security Automation Developer Days. here is link to the minutes from that discussion: https://oval.mitre.org/oval/about/OVAL_Developer_Days_2010_Minutes.pdf

Date Added: 2010-08-04 11:37:58
As a result of the developer days discussion, two other tracker items were opened and have been fixed in the drafts of version 5.8. 1- allow source OVAL Definition documents to be optional in OVAL Results 2- add capability to tailor OVAL Result directives by OVAL Definition class Based on the discussion at developer days there are two additional issue that remain open for discussion: 1- add additional levels to the oval-res:ContentEnumeration beyond thin and full that are defined as of version 5.7. See tracker item #27171 2- add an optional report_value attribute to all state entities in the oval-definitions-schema. See tracker item #27172

Date Added: 2010-08-04 11:39:10
This item is being marked as deferred and closed since it has been replaced by several other smaller tracker items.

25946 add foreign_port and foreign_address entities to the win-def:port_test Closed 2010-05-05 Fixed
Priority: High | Category: n/a | Date Closed: 2010-05-25 11:11:35
Details:
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
Follow-ups:
Date Added: 2010-05-25 11:11:35
Added foreign_address and foreign_port entities to draft 2 of version 5.8.

25958 allow local_port to be a regex in the win-def:port_test Closed 2010-05-06 Rejected
Priority: High | Category: Definition Schemas | Date Closed: 2010-05-14 23:51:39
Details:
in version 5.7 the local_port entity in the win-def:port_test is based on the oval-def:EntityObjectIntType. This type will restrict the allowed datatype and value to be only integers. If only integers are allowed then we cannot use a regular expression to match more sophisticated criteria than a simple port number. It should be common to need to match ranges of ports or to allow for a match of any port.

A search of the schema for other similar issues should also be conducted. Need to verify that oval-def:EntityObjectIntType is properly being used.
Follow-ups:
Date Added: 2010-05-14 23:51:39
Further investigation an consideration suggests that all uses of the oval-def:EntityObjectIntType are in fact appropriate. In the specific case of the local_port entity restricting the datatype to only allow int will work since we have the ability to use variables and greater than and less than operators to identify port ranges.

25980 add algorithm entity to the unix-def:shadow_state and unix-sc:shadow_item Closed 2010-05-07 Fixed
Priority: High | Category: n/a | Date Closed: 2010-05-25 11:55:15
Details:
>
>* 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? 
Follow-ups:
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

25988 add aix-def:netop_test Closed 2010-05-10 Fixed
Priority: High | Category: n/a | Date Closed: 2010-05-12 12:22:25
Details:
Security guide authors need to look at AIX's tunable (i.e., configurable)
network parameters.  These parameters are queried via the AIX /usr/sbin/no
command.  I'd like to propose the following netop_test be added to the OVAL AIX
component schema so that these parameters can be examined:

	netop_object
	------------
	- tunable: string - the name of the tuning parameter

	netop_state
	-----------
	- tunable: string
	- value: string - the value to compare to

See the developer list forum for more information:

http://making-security-measurable.1364806.n2.nabble.com/New-netop-test-for-AIX-tp5030928p5030928.html

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

26092 allow key on win-def:regkeyeffectiverights53_object to be nil Closed 2010-05-14 Fixed
Priority: Low | Category: n/a | Date Closed: 2010-05-14 11:47:42
Details:
The key entity of the win-def:regkeyeffectiverights53_object should be nilable to allow effective rights to be collected on registry hives.
Follow-ups:
Date Added: 2010-05-26 17:55:43
included in draft 2 of version 5.8

26149 allow more than one message on an oval-sc:ItemType Closed 2010-05-21 Fixed
Priority: Medium | Category: System Characteristics Schemas | Date Closed: 2010-05-21 13:46:29
Details:
The oval-sc:ItemType currently allows 0 or 1 message. For more verbose error reporting from data collection operations more than 1 message needs to be supported.

Follow-ups:
Date Added: 2010-05-21 16:50:24
Ended up setting the maxOccurs to 50 to allow for a fairly large, but not unbounded set of messages.

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

26164 minOccurs and maxOccurs in object declarations allow for numerous empty objects Closed 2010-05-24 Fixed
Priority: High | Category: n/a | Date Closed: 2010-05-24 17:53:53
Details:
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
Follow-ups:
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

26178 deprecate password entity in the unix-def:shadow_test Closed 2010-05-25 Rejected
Priority: Medium | Category: n/a | Date Closed: 2010-06-23 17:44:03
Details:
There is a general concern about the security implications of holding the password hash in possibly unprotected oval result files.  

One possible solution might be to simply use the mask attribute to hide the password entity value.

This request was discussed on the following developer list thread:
http://making-security-measurable.1364806.n2.nabble.com/Comments-on-OVAL-5-7-tp4784920p5030819.html
Follow-ups:
Date Added: 2010-06-07 11:43:02
The mask attribute can be used to hide the password hash if desired.

26184 add linux-def:rpmverify_test Closed 2010-05-26 Fixed
Priority: High | Category: n/a | Date Closed: 2010-06-23 17:43:27
Details:
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
Follow-ups:
Date Added: 2010-05-26 17:49:24
included in draft 2 of version 5.8

26222 create explicit mapping of tests, objects, states, and items Closed 2010-05-28 Fixed
Priority: High | Category: Definition Schemas | Date Closed: 2010-08-12 10:38:07
Details:
Currently the relationship between a test, object, state, and item is largely implied based on the names of the elements. This mapping should be made explicit in a machine interpretable format. It should be possibly to examine a test and reliably know which object, state, and item it relates to.
Follow-ups:
Date Added: 2010-08-07 00:35:51
Added new types tot eh oval-common-schema.xsd to represent a mapping structure that will relate a test, object, state, and item to each other. See the oval:element_mapping. The resulting structure looks like: <oval:element_mapping> <oval:test>family_test</oval:test> <oval:object>family_object</oval:object> <oval:state>family_state</oval:state> <oval:item target_namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#independent">family_item</oval:item> </oval:element_mapping> This change will be included in draft 6 of version 5.8.

26260 specify encoding on all schema files Closed 2010-06-02 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-06-08 12:02:34
Details:
all schema files currently assume the default character encoding. This should be explicitly set to UTF-8
Follow-ups:
n/a
26340 remove mixed='true' from declaration of entity types Closed 2010-06-08 Fixed
Priority: Medium | Category: Definition Schemas | Date Closed: 2010-07-03 00:46:47
Details:
In version 5.7 we incorrectly added the mixed='true' attribute to the EntityBaseType, EntityStateBaseType, or EntityStateRecordType. We really don’t need to allow for mixed content on the EntityBaseType, EntityStateBaseType, or EntityStateRecordType. 

the change in version 5.7 to setting mixed='true' was made to support the record datatype that was introduced in version 5.7, but the record datatype does not make use of mixed content.
Follow-ups:
Date Added: 2010-07-01 15:22:23
This update will be included in version 5.8 draft 3.

26380 add support for ipv4 to ipv6 address comparisons Closed 2010-06-10 Fixed
Priority: Medium High | Category: n/a | Date Closed: 2010-09-10 13:35:56
Details:
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
Follow-ups:
Date Added: 2010-08-19 03:37:58
These changes will be included in the Version 5.8 Release Candidate 1.

26589 deprecate the apache-def:httpd_test Closed 2010-06-23 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-07-03 00:42:07
Details:
There is a great deal of ambiguity in the definition of the httpd_test. There is not clear and reliable method for determining if apache httpd is installed or locating all installed versions of apache httpd. As the test is defied the tool implementer is left to define how to find apache httpd on a system. Without a specific search space there is no way for different products to reliably collect the same set of information on a system and then generate the same assessment results. 

Content authors that need to examine the version of apache should use one of the following approaches:
 - look for the hashes of files when there is an organizationally accepted version of http
 - use the native operating systems package management api (like RPM).
Follow-ups:
Date Added: 2010-06-23 15:28:36
included in draft 3 of version 5.8

26621 add esx-def:visdkmanagedobject_test Closed 2010-06-25 Fixed
Priority: High | Category: n/a | Date Closed: 2010-07-22 17:44:09
Details:
The visdkmanagedobject_test will be used to check information about Managed Objects in the VMware Infrastructure.
Follow-ups:
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.

26622 document the values in the oval:FamilyEnumeration Closed 2010-06-25 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-07-03 00:48:10
Details:
The individual values in the oval:FamilyEnumeration are not currently documented.
Follow-ups:
Date Added: 2010-06-25 12:52:07
this update will be included in version 5.8 draft 3

26637 remove circular schema references between the oval-def and the ind-def schemas Closed 2010-06-25 Fixed
Priority: High | Category: Definition Schemas | Date Closed: 2010-07-03 00:47:25
Details:
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.  
Follow-ups:
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.

26691 align entity names in win-def:process58_test and unix-def:process58_test Closed 2010-06-29 Fixed
Priority: High | Category: n/a | Date Closed: 2010-07-02 18:31:31
Details:
The unix and windows process test is documented differently.  The entities are 
different too.  win-def:process_object has entity "command_line". 
unix-def:process_object has entity "command".  Windows' command_line docs say:

"The command_line entity is the string used to start the process. This includes 
any parameters that are part of the command line."

Unix command docs say:

"The command element specifies the command/program name to check."

The docs for windows are clear that we should get a whole command line.  The 
unix docs suggest we just get the name of the executable.  In fact, "program 
name" suggests we just get the filename without any path information.

Also, the docs for the unix command object entity seem to contradict the docs on process_state and object itself, which say:

"The process_state element defines the different metadata associated with a UNIX process. This includes the command line [...]"

unix-def:process_object says:

"A process object defines the command line used to start the process(es)."

I.e. the entity says to get the command name, but the state and object say to 
get the command line.

I think it was probably meant that we should whole command lines on unix too, 
right?  
Can we clean up the documentation for this?  
And can we perhaps rename the command entity in process58 to be the same as for windows (command_line instead of command)?
Follow-ups:
Date Added: 2010-07-02 18:31:31
Deprecated the win-def:process_test, win-def:process_object, win-def:process_state, unix-def:process_test, unix-def:process_object, unix-def:process_state, and unix-sc:process_item. Changed the command entity to command line and updated the documentation to state the value is: "This is the string used to start the process. This includes any parameters that are part of the command line.". Also, a process58_item was created that uses the command line entity. These changes will be available in Draft 3 of Version 5.8.

26700 add capability to tailor OVAL Result directives by OVAL Definition class Closed 2010-06-29 Fixed
Priority: High | Category: Result Schemas | Date Closed: 2010-07-22 17:36:21
Details:
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.
Follow-ups:
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.

26702 allow source OVAL Definition documents to be optional in OVAL Results Closed 2010-06-30 Fixed
Priority: High | Category: Result Schemas | Date Closed: 2010-07-22 17:36:19
Details:
In order to allow for flexibility and greatly reduce the size of OVAL Results we need to consider allowing the source OVAL Definition document to be optional in a valid OVAL Results document. There may be additional options in between simply including the source document or not including the document. For example, is there value to simply supplying the location of the source document and the set of definition ids that were evaluated?
Follow-ups:
Date Added: 2010-07-02 01:07:31
In version 5.7 the oval_definitions element in the OVAL Results schema is optional. The schema documentation states: "The oval_definitions section is optional and dependent on the directives that are set. Its purpose is to provide an exact copy of the definitions evaluated for the results file." However, in reviewing the schema documentation there is no mention in the directives or the supporting Schematron of any such capability.

Date Added: 2010-07-09 17:56:04
This topic was discussed on the oval-developer-list. The archive of that discussion can be found here: http://making-security-measurable.1364806.n2.nabble.com/OVAL-Results-Optional-source-OVAL-Definitions-tp5265046p5265046.html

Date Added: 2010-07-09 17:56:32
this change will be included in draft 4 of version 5.8

26703 create an OVAL Directives schema to allow a tool to supply a set of directives Closed 2010-06-30 Fixed
Priority: High | Category: n/a | Date Closed: 2010-08-12 10:38:12
Details:
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.
Follow-ups:
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

26731 numerous entities are based on a string type and need to allow any simple type Closed 2010-07-02 Fixed
Priority: High | Category: n/a | Date Closed: 2010-07-22 17:36:22
Details:
After a quick check of the schemas, it looks like there are a few entities that are incorrectly based on the oval-sc:EntityItemStringType and the oval-def:EntityStateStringType. This is preventing the needed state operations from being expressed. 

This is known to affect the following entities:
- xmlfilecontent_state/value_of
- variable_state/value
- textfilecontent54_state/text

There are likely other instances of this issues in other component schemas. A complete search of the other component schemas is needed.
Follow-ups:
Date Added: 2010-07-02 17:58:16
This issue has been corrected for the following entities: - xmlfilecontent_state/value_of - variable_state/value - textfilecontent54_state/text These fixes will be included in draft 3 of version 5.8.

Date Added: 2010-07-09 19:34:28
This issue has been corrected for the following entities: - netop_state/value - getconf_state/output - sysctl_state/value These fixes will be included in draft 4 of version 5.8

26732 consolidate file behaviors Closed 2010-07-06 Fixed
Priority: High | Category: Definition Schemas | Date Closed: 2010-08-02 19:07:18
Details:
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?
Follow-ups:
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.

26944 max_depth behaviors defined in the independent-definitions-schema have the wrong default value Closed 2010-07-20 Fixed
Priority: High | Category: Definition Schemas | Date Closed: 2010-08-03 11:42:43
Details:
The default value for the max_depth behavior defined in the independent-definitions-schema has the wrong default value. This behavior is documented as having a default value of -1 indicating that there is no limitation on recursion. However, the schema sets the default value to 1 meaning that only the current directory will be searched. 

This error occurs on all four definitions of the max_depth behavior in the independent-definitions-schema. The following schema types need to be corrected:
- FileHashBehaviors
- Textfilecontent54Behaviors
- TextfilecontentBehaviors
- XmlfilecontentBehaviors
Follow-ups:
Date Added: 2010-07-20 16:19:15
This change will be included in version 5.8 draft 5.

27025 Missing Privilege under win-def:accestoken_state and win-sc:accestoken_item Closed 2010-07-23 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-08-03 16:00:06
Details:
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
Follow-ups:
Date Added: 2010-07-23 14:43:53
This change will be included in draft 5 of version 5.8

27214 clarify how the starting directory is considered when doing a recursive file search Closed 2010-08-06 Fixed
Priority: Medium | Category: Definition Schemas | Date Closed: 2010-08-12 10:38:09
Details:
The documentation do not currently indicate how the initial directory is to be handled when recursively searching the file system. The documentation should explicitly indicate that the initial directory must also be examined.
Follow-ups:
Date Added: 2010-08-06 00:18:44
The following text will be added to the documentation of the max_depth behavior. "For a 'max_depth' of -1 or any value of 1 or more the starting directory must be considered in the recursive search." This change will be included in draft 6 of version 5.8.

Date Added: 2010-08-06 00:20:32
A similar clarification was also added to the max_depth behavior defined for windows registry searches.

27411 add support for a hpux-def:ndd_test and sol-def:ndd_test Closed 2010-08-16 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-09-10 13:35:52
Details:
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.
Follow-ups:
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.

27438 add several entities to the unix-def:process58_test Closed 2010-08-18 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-09-10 13:35:58
Details:
The following entities were requested for the process_test:

- posix capabilities
An enumeration of the POSIX capabilities associated with the process. 
Is linux/include/linux/capability.h the best source of values for this enumeration?
There are three sets of capabilities on a process: the effective, inheritable, and permitted capabilities. Should this be the effective capabilities?
This new entity seems to be linux specific.

- selinux domain labels

- exec shield
Is this simply a boolean that when true would indicate that ExecShield is enabled for the process?
Where can this information be found for a process?
This new entity seems to be Linux specific.

- session identifier
  The session ID of the process.

- loginuid
The loginuid shows which account a user gained access to the system with. The /proc/XXXX/loginuid shows this value.

- cgroup attribute
We need a good reference for this new entity.

See the following thread in the oval-developer-list archives for more information:

http://making-security-measurable.1364806.n2.nabble.com/Comments-on-OVAL-5-7-tp4784920p4916173.html
Follow-ups:
Date Added: 2010-08-19 01:54:52
This test will be included in the Version 5.8 Release Candidate 1.

27726 correct inconsistencies across items, object, and state entity names and types Closed 2010-09-10 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-09-10 13:52:54
Details:
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.
Follow-ups:
n/a
19742 change the maxOccurs attribute value in win-sc:sharedresource_item/win-sc:current_uses Closed 2009-05-13 Fixed
Priority: Medium | Category: System Characteristics Schemas | Date Closed: 2010-08-05 13:47:28
Details:
Change the maxOccurs attribute value in win-sc:sharedresource_item/win-sc:current_uses from "unbounded" to "1" as the current_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.
Follow-ups:
Date Added: 2010-08-05 13:47:27
This change will be included in draft 6 of version 5.8.

19743 change the maxOccurs attribute value in win-sc:sharedresource_item/win-sc:max_uses Closed 2009-05-13 Fixed
Priority: Medium | Category: System Characteristics Schemas | Date Closed: 2010-08-05 13:47:10
Details:
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.
Follow-ups:
Date Added: 2010-08-05 13:47:09
This change will be included in draft 6 of version 5.8.

19744 change the win-sc:sharedresource_item/win-sc:shared_type entity type to align with the windows-definitions-schema Closed 2009-05-13 Fixed
Priority: Medium | Category: System Characteristics Schemas | Date Closed: 2010-09-10 13:35:54
Details:
Change the win-sc:sharedresource_item/win-sc:shared_type entity type to use an enumeration similar to the EntityStateSharedResourceTypeType enumeration found in the windows-definition-schema.
Follow-ups:
Date Added: 2010-09-09 12:16:20
This issue has been corrected for RC2 of Version 5.8

25271 add support for a windows service test Closed 2010-03-09 Fixed
Priority: High | Category: n/a | Date Closed: 2010-07-22 17:44:59
Details:
Add support for a windows service test.
Follow-ups:
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.

25310 add ruid entity to the unix-def:process_state and the unix-sc:process_item Closed 2010-03-11 Fixed
Priority: Medium High | Category: n/a | Date Closed: 2010-05-24 20:16:45
Details:
UNIX processes have both real and effective user IDs.  See section 'C.1.3.2 Process real and effective UID' of http://docstore.mik.ua/orelly/networking/puis/appc_01.htm.

Since a process has both a real and effective uid, it seems that we may want to be able to collect both.  Also, the process test is supposed to be equivalent to parsing the output of the 'ps' command.  With the 'ps' command it is possible to collect both the real and effective uids (e.g. 'ps -a -o "args pid ppid pri start tty ruid uid"').  Please see the 'ps' man page at http://linux.die.net/man/1/ps for more information.  We should update the the uid documentation to state it is the effective uid and then add an ruid entity for the real uid.
Follow-ups:
Date Added: 2010-05-26 17:56:42
included in draft 2 of version 5.8

25987 Fix errors in the independent-system-characteristics schema where ind-def is used instead of ind-sc Closed 2010-05-10 Fixed
Priority: High | Category: System Characteristics Schemas | Date Closed: 2010-05-12 13:12:39
Details:
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
Follow-ups:
Date Added: 2010-05-26 17:55:58
included in draft 2 of version 5.8

26101 add support for a linux-def:sestatus_test Closed 2010-05-17 Rejected
Priority: Medium | Category: n/a | Date Closed: 2010-06-16 18:38:57
Details:
Request from Steve Grubb:

2) selinux: status, mode, policy_ver, policy_name. Similar to running
   sestatus. The RHEL FDCC content being worked on will require SE Linux to
   be enabled and enforcing. This would allow testing for SE Linux status.

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

sestatus_object (no entities because there is only one sestatus_object)

sestatus_state 
  -status         (boolean) 
  -mode           (string) 
  -policy_version (integer) 
  -policy_name    (string) 

sestatus_item 
  -status         (boolean) 
  -mode           (string) 
  -policy_version (integer) 
  -policy_name    (string) 

In addition, we could add enumerations for the mode value (enforcing, permissive, and disabled) and for the policy_name value (targeted and strict).

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.
Follow-ups:
Date Added: 2010-05-26 17:50:48
included in draft 2 of version 5.8

Date Added: 2010-06-01 18:38:53
Based on oval-developer-list discussions, this test is being considered for removal from the next draft of Version 5.8 as it may not be needed.

Date Added: 2010-06-16 18:38:56
It was determined that we can collect the information defined in this test using the unix-def:file_test and the ind-def:textfilecontent54_test. As a result, this test is not needed and will be removed from Draft 3 of Version 5.8.

26102 add support for a linux-def:selinux_boolean_test Closed 2010-05-17 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-06-23 17:44:56
Details:
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.
Follow-ups:
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.

26103 add support for a unix-def:sysctl_test Closed 2010-05-17 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-06-23 17:44:55
Details:
Request from Steve Grubb:

4) sysctl: name, value. Similar to running "sysctl -A". There are some specific
settings that might be called out in the FDCC content for RHEL. For example,
The fs.suid_dumpable setting will need to be tested.

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

sysctl_object
  -name (string)

sysctl_state
  -name  (string)
  -value (string)

sysctl_item
  -name  (string) 
  -value (string)

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.
Follow-ups:
Date Added: 2010-05-26 17:49:55
included in draft 2 of version 5.8

26148 add support for a unix-def:partition_test Closed 2010-05-21 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-09-10 13:35:59
Details:
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
Follow-ups:
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.

26239 correct documentation specifying the use of all capital letters for well known trustees Closed 2010-06-01 Fixed
Priority: High | Category: n/a | Date Closed: 2010-07-02 16:56:37
Details:
In the Windows schemas, there are multiple instances where the documentation specifies that all capital letters should be used because it is how the Windows APIs return them. As an example, in the trustee_name entity in the win-def:fileauditedpermissions_object, it states:

"Note that the built-in trustee names should be all caps as that is how the Windows APIs return them."

We should review how the Windows APIs return these values and determine if they are in fact returning them using all capital letters.  If not, this documentation should be removed.
Follow-ups:
Date Added: 2010-06-07 12:41:56
After looking into this issue, we have determined that the documentation recommending the use of all capital letters is no longer valid. This documentation should be removed in favor of stating when an entity is natively case-insensitive and recommending that the case-insensitive operations be used.

26734 add support for an unbounded filter element in all objects Closed 2010-07-06 Fixed
Priority: High | Category: Definition Schemas | Date Closed: 2010-07-22 17:36:20
Details:
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





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

26737 add support for a macos-def:plist_test Closed 2010-07-06 Fixed
Priority: High | Category: n/a | Date Closed: 2010-09-10 21:10:54
Details:
Plists can be stored in XML, binary, and text formats. While existing tests (ind-def:xmlfilecontent_test and ind-def:textfilecontent54_test) can be used to extract information from the XML and text plists, they cannot be used to extract the information from the binary plists. As a result, a new macos:plist_test is needed to retrieve plist settings regardless of the format in which they are stored.
Follow-ups:
Date Added: 2010-08-07 00:36:40
This test will be added to draft 6 of version 5.8.

Date Added: 2010-09-10 21:10:54
A few issues as described in the following oval-developer-list post were discovered with the plist_test. http://making-security-measurable.1364806.n2.nabble.com/Is-There-a-Need-for-a-macos-plist-test-tp5367977p5519414.html As a result, the following changes were made changes to the plist_test to fix some outstanding issues. 1) Added documentation stating the string datatype should be used for CFData values as it is base64-encoded and not hex-encoded like the OVAL binary datatype. 2) Added documentation stating that CFDictionary values (i.e. records) could not be collected and only the collection of simple data would be allowed. 3) Added the ability to collect a plist's value when there are no keys associated with it by using the xsi:nil attribute. 4) Added an instance entity to provide uniqueness among plist_items that have the same preference key. These changes will be available in the Version 5.8 Release Candidate 2.

26738 add support for a unix-def:gconf_test Closed 2010-07-06 Fixed
Priority: High | Category: n/a | Date Closed: 2010-08-16 17:21:58
Details:
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

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

26756 change instances of 'sid' to 'SID'. Closed 2010-07-07 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-07-07 13:22:12
Details:
In the documentation, there are instances where we refer to the security identifier (SID) as 'sid'.  All instances of 'sid' should be changed to 'SID' to align with how Microsoft abbreviates the term security identifier. 
Follow-ups:
Date Added: 2010-07-10 01:47:23
this change will be included in draft 4 of version 5.8

26757 clarify references to ACL Closed 2010-07-07 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-07-08 03:32:06
Details:
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.
Follow-ups:
Date Added: 2010-07-10 01:47:32
this change will be included in draft 4 of version 5.8

26786 bug in the sp-def:sppolicy_object Closed 2010-07-08 Fixed
Priority: Medium | Category: Definition Schemas | Date Closed: 2010-08-03 15:57:07
Details:
The way that the schema is written for the sp-def:sppolicy_object allows for the choice of a set or a webappuri and a urlzone.  As a result, you can write the following content:

<sppolicy_object>
    <set>
    ...
    </set>
    <urlzone>...</urlzone>
</sppolicy_object>

This is incorrect. The documentation specifies that an sp-def:sppolicy_object consists of a set or a webappuri and a urlzone.  The schema should be changed to reflect this.
Follow-ups:
Date Added: 2010-07-10 01:45:40
this change will be included in draft 4 of version 5.8

26809 add a drive_type entity to the win-def:volume_state and the win-sc:volume_item Closed 2010-07-12 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-08-03 15:59:54
Details:
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
Follow-ups:
Date Added: 2010-07-13 00:32:40
This change will be available in Draft 5 of Version 5.8.

27215 change the maxOccurs attribute value in ind-def:ldap_state/ind-def:value entity Closed 2010-08-06 Fixed
Priority: Medium | Category: Definition Schemas | Date Closed: 2010-08-12 10:38:06
Details:
Change the maxOccurs attribute value in ind-def:ldap_state/ind-def:value from "unbounded" to "1".
Follow-ups:
Date Added: 2010-08-07 00:38:40
This change will be included in draft 6 of version 5.8.

27331 add support for a macos-def:diskutil_test Closed 2010-08-12 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-09-10 13:36:01
Details:
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
Follow-ups:
Date Added: 2010-08-18 22:56:27
This test will be included in the Version 5.8 Release Candidate 1.

27332 add support for a linux-def:selinuxsecuritycontext_test Closed 2010-08-12 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-09-10 13:37:02
Details:
Please see the following link for additional information.

http://making-security-measurable.1364806.n2.nabble.com/SELinux-Security-Context-Test-tp5140599.html
Follow-ups:
Date Added: 2010-08-18 17:45:47
At some later time, we should contact the SELinux mailing list for help regarding enhancing the capabilities of this test. We should also consider the following issues: Another issue is classification of the results. Perhaps the admin running the scan is not himself cleared to see the results and only the security officer is allowed. So, that brings up the question of what level the scan runs at as well as taking the right precautions along the way... 1) pay attention to networking and use the labeled networking APIs if the scan is done remotely. 2) classify results 3) store results on disk with the correct label 4) perhaps support views of the data in any presentation layer or the ability to exclude data above the viewer's classification. Also, a MLS system introduces another idea, polyinstantiation. 1) directories: This means that ls /tmp, for example, will certainly have different contents based on the sensitivity level of the scanner. 2) networking: inetlistening daemon tests might have different results depending on the sensitivity level of the scanner. Some of these ideas may take more discussion than 5.8 has time for. But I believe this is a quick overview of the major issues. Getting a SE Linux test and collection of labels on the major system objects is a very good first step. Deciding the access control, classification of results, and other things outlined above could be saved for a later day. I can try to get some MLS people involved in this discussion if you like.

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

27333 add support for a sol-def:packagecheck_test Closed 2010-08-12 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-09-10 13:36:02
Details:
Please see the following link for additional information.

http://making-security-measurable.1364806.n2.nabble.com/Proposal-for-Solaris-Pkgchk-based-Test-tp5351678.html
Follow-ups:
Date Added: 2010-08-18 22:56:17
This test will be included in the Version 5.8 Release Candidate 1.

27444 add support for a unix-def:routingtable_test Closed 2010-08-18 Fixed
Priority: Medium | Category: n/a | Date Closed: 2010-09-10 13:35:53
Details:
Please see the following link for additional information.

http://making-security-measurable.1364806.n2.nabble.com/RFC-New-items-for-Linux-tp4785229p4785229.html
Follow-ups:
Date Added: 2010-08-19 03:38:19
This test will be included in the Version 5.8 Release Candidate 1.

Date Added: 2010-09-09 14:31:56
Remove the unix-def:routingtable_state/unix-def:netmask and unix-sc:routingtable_item/unix-sc:netmask entities in favor of specifying the destination address and netmask/prefix-length as an address prefix in the destination entity. Please see the following link for additional information. http://making-security-measurable.1364806.n2.nabble.com/RFC-New-items-for-Linux-tp4785229p5492459.html

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

27670 the win-sc:regkeyauditedpermissions_item does not allow for the use of the xsi:nil attribute on the key entity Closed 2010-09-08 Fixed
Priority: Medium | Category: System Characteristics Schemas | Date Closed: 2010-09-08 16:18:03
Details:
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. 
Follow-ups:
Date Added: 2010-09-08 18:43:26
This change will be included in the Version 5.8 Release Candidate 2.

27674 make the pid entity in the linux-def:selinuxsecuritycontext_object nillable Closed 2010-09-08 Fixed
Priority: Medium | Category: Definition Schemas | Date Closed: 2010-09-08 19:00:57
Details:
It may be necessary to collect the security context of the current process. As a result, the pid entity in the linux-def:selinuxsecuritycontext_object should be nillable. The pid entity in the linux-sc:selinuxsecuritycontext_item will not be nillable as it will take on the value of the current process.    
Follow-ups:
Date Added: 2010-09-08 19:00:57
This change will be included in the Version 5.8 Release Candidate 2.

27676 the macos-sc:pwpolicy_item does not allow for the use of the xsi:nil attribute on the username, userpass, and directory_node entities Closed 2010-09-08 Fixed
Priority: Medium | Category: System Characteristics Schemas | Date Closed: 2010-09-08 19:01:36
Details:
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. 
Follow-ups:
Date Added: 2010-09-08 19:01:35
These changes will be included in the Version 5.8 Release Candidate 2.

27677 the unix-sc:gconf_item does not allow for the use of the xsi:nil attribute on the source entity Closed 2010-09-08 Fixed
Priority: Medium | Category: System Characteristics Schemas | Date Closed: 2010-09-08 19:00:33
Details:
The unix-sc:gconf_item does not currently allow for the xsi:nil attribute on the unix-sc:gconf_item/unix-sc:source entity even though the xsi:nil attribute can be specified on the unix-def:gconf_object/unix-def:source entity. The source entity in the unix-sc:gconf_item should be fixed to allow for the use of the xsi:nil attribute. 
Follow-ups:
Date Added: 2010-09-08 19:00:33
This change will be included in the Version 5.8 Release Candidate 2.

27678 the linux-sc:selinuxsecuritycontext_item does not allow for the use of the xsi:nil attribute on the filename entity Closed 2010-09-08 Fixed
Priority: Medium | Category: System Characteristics Schemas | Date Closed: 2010-09-08 19:01:18
Details:
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. 
Follow-ups:
Date Added: 2010-09-08 19:01:17
This change will be included in the Version 5.8 Release Candidate 2.

27420 make sure that platform and product names are unique in a definition's metadata Closed 2010-08-17 Fixed
Priority: Medium | Category: Definition Schemas | Date Closed: 2010-09-10 13:35:57
Details:
In an OVAL definition file, add a validation check (either in schematron or in the schema) to make sure that platform names are unique.

<affected family="windows">
  <platform>Microsoft Windows 7</platform>
  <platform>Microsoft Windows XP</platform>
  <platform>Microsoft Windows Server 2003</platform>
  <platform>Microsoft Windows Vista</platform>
  <platform>Microsoft Windows Server 2008</platform>
  <platform>Microsoft Windows 7</platform>  <-- WRONG, REPEATED PLATFORM
  <product>Wireshark</product>
  ...
Follow-ups:
Date Added: 2010-08-17 16:12:32
oval-def:UniqueAffectedFamily also appears to not be working.

Date Added: 2010-08-19 02:09:24
Verified that oval-def:UniqueAffectedFamily is working and added unique constraints to ensure platform and product values are unique. This change will be included in the Version 5.8 Release Candidate 1.

Back to top

Timeline for Version 5.8

PLANNING DRAFT RELEASE CANDIDATE OFFICIAL
15 January 2010 5 May 2010 18 August 2010 15 September 2010
Back to top

Status Reports on Version 5.8

Status updates are included below. You may also review the OVAL Developer’s Forum Archives for discussions about Version 5.8.

[2010-09-15]

Version 5.8 has been officially released. Many thanks to all in the community that helped with this minor release.

[2010-09-10]

Version 5.8 Release Candidate 2 is now available for community review and comment. As a reminder a release candidate signifies that the proposed OVAL Language revision has reached a level of consensus within the OVAL Community, and the OVAL Moderator has verified that the language is valid. In the release candidate stage, the language remains frozen for a period of time determined by the OVAL Board. It is during this stage that vendors and tool developers should update their tools with the knowledge that the schema will remain stable. Subsequent release candidates may be released if a serious problem is discovered in the proposed language. This release candidate represents a complete implementation of all planned changes for Version 5.8 and includes the following updates since the last release candidate:

  • changed the "subsetof" and "supersetof" operations to "subset of" and "superset of" to align with the naming scheme used for operations.
  • added documentation to state that the unix-def:routingtable_test only collects IPv4 and IPv6 entries from the primary routing table.
  • added documentation to state that the unix-def:routingtable_test only collects IPv4 and IPv6 addresses in their numerical form.
  • removed the netmask entity in the unix-def:routingtable_test and unix-sc:routingtable_item.
  • changed the unix-def:routingtable_object/destination entity documentation to indicate that the destination should now be an address prefix.
  • updated the unix-def:interface_test and win-def:interface_test documentation to specify how to handle the collection of IPv6 addresses.
  • added an instance entity to the sol-def:ndd_state and the sol-sc:ndd_item.
  • aligned the EntityObjectBaseType documentation with the EntityBaseType documentation.
  • updated the ipv4_address documentation with a description of what representations are legal.
  • removed the linux-def:EntityStateSeLinuxModeType and the linux-sc:EntityItemSeLinuxModeType enumerations.
  • added the xsi:nil attribute to the linux-def:selinuxsecuritycontext_object/pid entity.
  • corrected the linux-sc:selinuxsecuritycontext_item/filename entity to allow for the use of the xsi:nil attribute.
  • added an instance entity to the macos-def:plist_state and macos-sc:plist_item to provide uniqueness among items.
  • added the xsi:nil attribute to the macos-def:plist_object/key and macos-sc:plist_item/key entities.
  • added documentation to the macos-def:EntityStatePlistTypeType and macos-sc:EnityItemPlistTypeType to indicate how the values map to OVAL datatypes.
  • corrected inconsistencies across items, states, and object entity names, types, and multiplicity.
  • changed the win-sc:sharedresource_item/win-sc:shared_type entity type to use the EntityItemSharedResourceTypeType enumeration.
  • fixed the username, userpass, and directory_node entities in the macos-sc:pwpolicy_item to allow for the use of the xsi:nil attribute.
  • fixed the source entity in the unix-sc:gconf_item to allow for the use of the xsi:nil attribute.
  • fixed the key entity in the win-sc:regkeyauditedpermissions_item to allow for the use of the xsi:nil attribute.

[2010-08-19]

Version 5.8 Release Candidate 1 is now available for community review and comment. As a reminder a release candidate signifies that the proposed OVAL Language revision has reached a level of consensus within the OVAL Community, and the OVAL Moderator has verified that the language is valid. In the release candidate stage, the language remains frozen for a period of time determined by the OVAL Board. It is during this stage that vendors and tool developers should update their tools with the knowledge that the schema will remain stable. Subsequent release candidates may be released if a serious problem is discovered in the proposed language. This release candidate represents a complete implementation of all planned changes for Version 5.8 and includes the following updates since the last draft:

  • ensure that platform and product names are unique in a definition's metadata
  • added several entities to the unix-def:process58_test
  • added support for a unix-def:routingtable_test
  • added support for a unix-def:partition_test
  • added support for a macos-def:diskutil_test
  • added support for a sol-def:packagecheck_test
  • added support for a linux-def:selinuxsecuritycontext_test
  • added support for ipv4 to ipv6 address comparisons
  • added support for a hpux-def:ndd_test and sol-def:ndd_test
  • added support for a unix-def:gconf_test
  • added support for a macos-def:plist_test

[2010-08-06]

Version 5.8 Draft 6 is now available for community review and comment. This draft includes the following updates:

  • changed the maxOccurs attribute value in ind-def:ldap_state/ind-def:value entity from unbounded to 1
  • added support for a macos:plist_test
  • created explicit mapping of tests, objects, states, and items
  • added support for a unix-def:gconf_test
  • clarified how the starting directory is considered when doing a recursive file search
  • changed several unix-sc and linux-sc item entities to be based on ints rather than strings
  • changed the documentation on the epoch entity of rpminfo_test to require the string (none) for a null epoch
  • changed the xinetd_item port entity from a string to an integer
  • changed the maxOccurs attribute value in win-sc:sharedresource_item/win-sc:current_uses
  • changed the maxOccurs attribute value in win-sc:sharedresource_item/win-sc:max_uses
  • created an OVAL Directives schema to allow a tool to supply a set of directives

[2010-07-23]

Version 5.8 Draft 5 is now available for community review and comment. This draft includes the following updates:

  • consolidated file behaviors in all component schemas to simplify schemas and clarify documentation
  • added a drive_type entity to the win-def:volume_state and the win-sc:volume_item
  • added a setrustedcredmanaccessnameright entity to the win-def:accestoken_state and the win-sc:accestoken_item
  • corrected max_depth behaviors defined in the independent-definitions-schema
  • corrected numerous documentation typos

[2010-07-09]

Version 5.8 Draft 4 is now available for community review and comment. This draft includes the following updates:

  • clarified references to ACL in the schema documentation
  • changed instances of "sid" to "SID" in the schema documentation
  • corrected bug in the sp-def:sppolicy_object
  • added capability to filter an object with an unbounded filter elements
  • added support for a windows service test
  • added directive attribute to indicate when the source OVAL Definition document is excluded from an OVAL Results document
  • added new lin-def:if_listeners_test for AF_PACKET family
  • corrected numerous documentation typos

[2010-07-02]

Version 5.8 Draft 3 is now available for community review and comment. This draft includes the following updates:

  • added new lin-def:if_listeners_test for AF_PACKET family
  • added esx-def:visdkmanagedobject_test
  • removed circular schema references between the oval-def and the ind-def schemas
  • added capability to tailor OVAL Result directives by OVAL Definition class
  • documented the values in the oval:FamilyEnumeration
  • deprecated the apache-def:httpd_test
  • removed mixed="true" from declaration of entity types
  • removed the linux-def:sestatus_test. This test was introduced in draft 2 and then it was determined that the test was not needed.
  • corrected documentation specifying the use of all capital letters for well known trustees in the windows component schema
  • aligned entity names in win-def:process58_test and unix-def:process58_test
  • specified encoding on all schema files
  • corrected numerous documentation typos

[2010-05-26]

Version 5.8 Draft 2 is now available for community review and comment. This draft includes the following updates:

  • allowed key on win-def:regkeyeffectiverights53_object to be nil
  • added foreign_port and foreign_address entities to the win-def:port_test
  • added pid entity to the win-def:process_object and unix-def:process_object
  • added linux-def:rpmverify_test
  • added support for a unix-def:partition_test
  • added support for a unix-def:sysctl_test
  • added support for a linux-def:selinux_boolean_test - This test may be removed in a later draft because it may not actually be needed.
  • added support for a linux-def:sestatus_test
  • added support for additional hash algorithms to the ind-def:filehash_test
  • corrected issue with minOccurs and maxOccurs in object declarations allowing for numerous empty objects
  • allow more than one message on an oval-sc:ItemType
  • added aix-def:netop_test
  • corrected errors in the independent-system-characteristics schema where ind-def is used instead of ind-sc in schematron rules
  • added algorithm entity to the unix-def:shadow_state and unix-sc:shadow_item
  • added pid entity to the ind-def:environmentvariable_object
  • added ruid entity to the unix-def:process_state and the unix-sc:process_item
  • corrected numerous documentation typos

[2010-05-05]

Version 5.8 Draft 1 is now available for community review and comment. This first draft includes a significant refactoring of the datatype constraints on entities. These constraints were implemented on each entity as Schematron rules in previous versions of OVAL, but beginning in Version 5.8 will be expressed as a small set of XML Schema types. This change removes literally thousands of Schematron rules and will represent a significant improvement in content validation time.

[2010-01-15]

Version 5.8 is currently in the planning stage. If you have any suggestions for changes that should be included, please send them to the OVAL Community.

Back to top

Page Last Updated: February 17, 2011