Open Vulnerability and Assessment Language

There is a Schematron rule that assures that items with a var_ref attribute also have a var_check attribute. This is more a best practice than a requirement. So the assertion message should be changed to reflect that it is only a warning and not invalid.

Date Added: 2010-01-22 21:21:58
Jon Baker: "I think the wording is fine for the moment." 

Date Added: 2010-01-23 01:50:34
for now we committed the change to make the schematron assertion a report. At a later time we will review and standardize all schematron rules. 

The additional values needed are:

TCPMUX
TCPMUXPLUS

n/a

>-----Original Message-----
>From: owner-oval-team-list@LISTS.MITRE.ORG [mailto:owner-oval-team-
>list@LISTS.MITRE.ORG] On Behalf Of Michael Chisholm
>Sent: Wednesday, September 16, 2009 2:45 PM
>To: oval-team-list
>Subject: Empty <value> not allowed in constant_variable?
>
>Mike Lah accidentally stumbled over a constraint with an oval
>definition, where <value>'s for <constant_variable>'s cannot be empty.
>Some of my thoughts:
>
>- Schematron validation passed, and that error was caught by the
>interpreter itself.  But there is a schematron rule which I think is
>supposed to catch this, and doesn't seem to be working.
>
><sch:rule context="oval-def:constant_variable/oval-def:value">
>  <sch:assert test=".!=''">....</sch:assert>
></sch:rule>
>
>Does this rule need to be fixed?  (I don't know schematron well enough
>to tell by looking)
>
>- An empty value is valid in some circumstances.  For example, it is
>possible for a regex to match the empty string.  If you aren't allowed
>to have empty strings as variable values, you can't represent some valid
>matches.  So I question whether this schematron rule should exist at
>all.  I can see that it would not make sense to have an empty value if
>the variable type is, say, 'int'.  Maybe a more appropriate rule would
>enforce values of the <value> element, according to the
>constant_variable's datatype?  (I thought I'd seen a rule like that in
>other places in the schema)
>
>Andy

Date Added: 2010-01-26 01:51:27
removed the schematron rule

Date Added: 2010-01-26 01:59:18
Removed the rule that checks that oval-def:literal_component is not empty. 
Looked for all other occurrences of several possible matching strings to try to find other areas where we are restricting the empty string. 

the definition of the oval-def:MetadataType should be updated to require that each child affected element have a unique family.

n/a

Need a test to test for listing DNS cache domain names and IP addresses.

n/a

The behaviors defined for searching files are inconsistent across the windows, independent, and unix component schemas. There are four different behaviors defined to help control file searches:

- max_depth - defined in all schemas
- recurse_direction - defined in all schemas
- recurse - only defined in the unix schema
- recurse_file_system - only defined in the unix schema

There are at least two problems with the fact that the file behaviors are not in alignment:

1- File related tests in the independent-definitions-schema are intended to apply to unix platforms. The recurse and recurse_file_system behavior probably needed when using the independent-definitions-schema tests on a unix platform.

2- There is no behavior in the widows or independent schemas to allow a user to specify which types of file systems should be searched. These schema probably need the 'recurse_file_system' behavior.


I recommend that we make the following changes in version 5.7 to address these issues and bring some consistency to the file related behaviors:

1- Add the 'recurse' and 'recurse_file_system' behaviors to the following objects in the independent-definitions-schema:
   - ind-def:filehash_object
   - ind-def:textfilecontent54_object
   - ind-def:xmlfilecontent_object
   - ind-def:filemd5_object - no change here because it is deprecated

This addition would require us to document that the 'recurse' behavior does not apply when an independent-definitions-schema test is evaluated on windows.

2- Add the 'recurse_file_system' behavior to the following objects in the windows-definitions-schema:
   - win-def:file_object 
   - win-def:fileauditedpermissions53_object
   - win-def:fileeffectiverights53_object


Assuming these changes are made such that the default behavior matches the current behavior of all modified objects, this change should not impact existing content. The change should reduce confusion about the various file related behaviors and add in the capability restrict file searched on windows platforms based on the type of file system.

n/a

As outline in the "OVAL Language Deprecation Policy" any construct that has been deprecated for more than one release may be removed from a subsequent minor release of the OVAL Language (http://oval.mitre.org/language/about/deprecation.html). 

I would like to propose the following deprecated items be removed in the next draft of version 5.7:

In the independent-definitions-schema
- ind-def:filemd5_test
- ind-def:filemd5_object
- ind-def:filemd5_sate
See: http://oval.mitre.org/language/download/schema/version5.6/ovaldefinition/deprecation/independent-definitions-schema.html

In the independent-system-characteristics-schema:
- ind-sc:filemd5_item
See: http://oval.mitre.org/language/download/schema/version5.6/ovalsc/deprecation/independent-system-characteristics-schema.html

n/a

In reviewing the release candidate we discovered that some of the Schematron rules that relate a test to the correct object and state are missing. These rules were simply never added when we started using schematron or when the test itself was created. These are important rules and we feel that we should add them to the 5.7 release. 

The following tests were missing Schematron rules:

- catos-def:version55_test
- catos-def:version_test
- hpux-def:getconf_test
- hpux-def:patch53_test
- hpux-def:patch_test
- hpux-def:swlist_test
- hpux-def:trusted_test
- linux-def:dpkginfo_test
- linux-def:inetlisteningservers_test
- linux-def:rpminfo_test
- linux-def:slackwarepkginfo_test
- macos-def:accountinfo_test
- macos-def:inetlisteningservers_test
- macos-def:nvram_test
- macos-def:pwpolicy_test

n/a

The schema documentation does not currently describe how an interpreter should handle datatype and operation when a var_ref is used to retrieve record. The documentation needs to explicitly state that the datatype used for evaluation of a given field is the datatype found on that field. The operation will always be equals.

Date Added: 2010-04-17 01:27:28
Due to the impact of this change we will defer this feature until a later release. It will not be included in version 5.7.

Date Added: 2011-01-12 11:50:23
This issue was addressed with documentation in the version 5.7 release that clearly states that the use of var_ref is not permitted when the datatype is record.

There is an inconsistency in the type for the local_port entity in the port_object.  The inconsistency is that the local_port entity is of type ‘oval-def:EntityObjectIntType’ yet the corresponding assertion test checks to see if the local_port entity value is of type string.  Below is the offending XML from the windows-definitions-schema.xsd file.

<xsd:element name="local_port" type="oval-def:EntityObjectIntType">
      <xsd:annotation>
            <xsd:documentation>This element specifies the number assigned to the local listening port.</xsd:documentation>
            <xsd:appinfo>
                  <sch:pattern id="winportobjlocal_port">
                        <sch:rule context="win-def:port_object/win-def:local_port">
                              <sch:assert test="not(@datatype) or @datatype='string'"><sch:value-of select="../@id"/> - datatype attribute for the local_port entity of a port_object should be 'string'</sch:assert>
                        </sch:rule>
                  </sch:pattern>
            </xsd:appinfo>
      </xsd:annotation>
</xsd:element> 


Also, in the windows-system-charactersistics-schema.xsd file, the port_item specifies the local_port entity should be of type ‘oval-def:EntityObjectIntType’.  Therefore the local_port entity in the windows-definitions-schema.xsd file should be updated to align with the port_item windows-system-characteristics.xsd file. 

Date Added: 2010-01-25 21:18:16
Updated appropriate Schematron rules.

The OVAL Language does not currently specify how to handle a substring_start value greater than the length of the string.  This should be specified and implemented in OVALDI as necessary.

n/a

A schematron rule should be added to check to make sure that behaviors are not used with the filepath entity as they are not allowed.

<xsd:documentation>

It is important to note that the ‘max_depth’ and ‘recurse_direction’ attributes of the ‘behaviors’ element do not apply to the ‘filepath’ element, only to the ‘path’ and ‘filename’ elements. This is because the ‘filepath’ element represents an absolute path to a particular file and it is not possible to recurse over a file.

</xsd:documentation>

Date Added: 2010-01-22 21:26:10
Which schemas does this affect? Windows only?

Date Added: 2010-01-25 16:10:55
Fixed in windows definitions schema.

Date Added: 2010-01-25 16:19:45
This issue applies to all component definition schemas. Simply search for all instances of "filepath". This should find matches at least in the independent and unix schemas. 

To me more specific, the general notion of behaviors with the filepath entity should be allowed. However, there are a few specific behaviors that should not be allowed. We need to look at the behaviors around each filepath and make sure we prohibit those that do not make sense.

Date Added: 2010-01-25 16:37:48
Are the "few specific behaviors" limited to max_depth and "recurse_direction"? I do see in the independent-definitions-schema.xsd "ignore_case", "multiline" and "singleline". I don't know enough about the meanings, but they appear to be valid with a filepath. I'll try to examine the behaviors and if I have any questions about specific ones, I'll ask.

Date Added: 2010-01-25 16:44:48
each behavior should be documented. If a behavior is not documented then we need to fix that and add documentation. The examples you gave from the independent-definitions-schema do not apply to the filepath entity. 

For a bit of background, in version 5.6 we added the filepath entity as a choice instead of path+filename. When we did this we forgot to add any schematron assertions to prevent the behaviors that applied to one portion of the choice (path+filename) from being applied to the filepath portion of the choice.

Date Added: 2010-01-26 01:34:17
is this one complete now?

Date Added: 2010-01-26 14:08:52
Fixed in Unix definitions schema. This is complete now.

When zero items are collected by the system for a specified object (when the equals operation is used) it will provide an item specifying which elements were successfully collected and which elements did not exist.  However, when behaviors are used with the specified object it can result in many items with a status of "does not exist" to be collected, and can significantly impact the time it takes to analyze the definition.  It needs to be decided how to handle this case and then updated in the documentation.  An example of this scenario is if a file_object where the path equals "c:\" and the filename equals "test.txt" and the behaviors recurse_direction equals “down" and max_depth equals “-1" are applied.  As OVALDI recurses the directory, for every path it searches for "test.txt", and doesn't find it, it will collect an item that does not exist with a path equal to "c:\some_path" and a filename equal to "test.txt" with a status of "does not exist".  As a result, if there are many subdirectories of the path "c:\", there will be many items referenced by the object that do not exist and will increase the time it takes to analyze the definition.

Date Added: 2010-01-27 16:10:39
These changes should be reviewed and improved if possible.

Places in the schema where we mention sets (e.g. a set of items, a set of objects, etc.), we should say a unique set of items, a unique set of objects, etc.  This will clarify any confusion where a set may be interpreted as a collection of elements that are not necessarily unique.

n/a

The language has many file-based tests; however, it does not necessarily make sense for all file types to be collected for each test.  The documentation for each file-based test should explicitly state which file types will be collected.

n/a

Please see
http://n2.nabble.com/Proposed-Changes-to-the-ind-def-ldap-test-tp4171575ef20093.html
for information on the required changes.

n/a

Please see
http://n2.nabble.com/Proposed-Changes-to-the-ind-def-ldap-test-tp4171575ef20093.html
for additional information.

n/a

It should be explicitly stated that the owner entity should specify the owner in the DOMAIN\username format.

n/a

Due to the slow performance of the schematron rules for the OVAL Language, we should investigate different ways to optimize and improve their performance.

n/a

Please see http://n2.nabble.com/OVAL-Filter-behavior-tp4420626ef20093.html for more information.

n/a

Update the win-sc:group_item to include a subgroup entity as outlined in the proposal.

Date Added: 2010-02-03 21:12:20
This was also applied to the win-sc:group_sid_item.

Jon,

One issue that comes to mind with respect to any new setting is that the OVAL documentation currently does not document restrictions on usage of specific elements with the version(s) of a product or platform in which they are supported.  This may be something to consider for future additions to the documentation as well as the schematrons.
 
To ensure comprehensive support for the audit subcategories I suggest that the following child elements be added to auditeventpolicysubcategories_state:
 
Child Elements                                               Type                                   MinOccurs   MaxOccurs
kerberos_authentication_service            win-def:EntityStateAuditType                0                 1
kerberos_service_ticket_operations        win-def:EntityStateAuditType                0                 1
network_policy_server                          win-def:EntityStateAuditType                0                 1
detailed_file_share                               win-def:EntityStateAuditType                0                 1
 
This page contains a listing of what's new to security auditing in Windows 7 and Windows 2008 R2.
http://technet.microsoft.com/en-us/library/dd560628(WS.10).aspx
 
I have pasted the description of the previously listed settings below for your convenience.
 
Audit Policy: Account Logon: Kerberos Authentication Service:

Audit events generated by Kerberos authentication ticket-granting ticket (TGT) requests.

Audit Policy: Account Logon: Kerberos Service Ticket Operations:

Audit events generated by Kerberos service ticket requests.
 
Audit Policy: Logon-Logoff: Network Policy Server:
Audit events generated by RADIUS (IAS) and Network Access Protection (NAP) user access requests. These requests can be Grant, Deny, Discard, Quarantine, Lock, and Unlock.


Audit Policy: Object Access: Detailed File Share:

Audit attempts to access files and folders on a shared folder. The Detailed File Share setting logs an event every time a file or folder is accessed, whereas the File Share setting only records one event for any connection established between a client and file share. Detailed File Share audit events include detailed information about the permissions or other criteria used to grant or deny access.
 
Thanks,
Tim Harrison
SCAP Content Development
National Institute of Standards and Technology
(717)561-2923
[hidden email]

--------------------------------------------------------------------------------
From: Baker, Jon [[hidden email]]
Sent: Monday, February 01, 2010 9:21 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] Windows 7 audit settings

Tim,

We have not had a chance to look at Windows 7 yet, but it does look like some changes were made to the auditing capabilities in windows 7 and server 2008. Would it be possible to suggest the changes that need to be made and provide a link to the correct Microsoft article to justify the changes? 

Thanks,

Jon 

============================================

Jonathan O. Baker

G022 - IA Industry Collaboration

The MITRE Corporation

Email: [hidden email]

From: Harrison, Tim [mailto:[hidden email]] 
Sent: Thursday, January 28, 2010 5:38 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] Windows 7 audit settings 

I appear to have run accross 4 new audit policy subcategories in Windows 7:

Audit Policy: Account Logon: Kerberos Authentication Service
Audit Policy: Account Logon: Kerberos Service Ticket Operations
Audit Policy: Logon-Logoff: Network Policy Server
Audit Policy: Object Access: Detailed File Share

Do do any of the current OVAL versions address these audit subcategories?
 
If not, are there are any plans to add them?

If the answer to both of these questions is 'no' then I would like to request the following element be added as child elements of auditeventpolicysubcategories_state:

kerberos_authentication_service
kerberos_service_ticket_operations
network_policy_server
detailed_file_share
 
Respectfully,

Tim Harrison
SCAP Content Development
National Institute of Standards and Technology
(717)561-2923
[hidden email]

n/a

The audit event policy subcategories do not have any documentation. This should be added.

http://technet.microsoft.com/en-us/library/dd560628(WS.10).aspx

n/a

Classification:  UNCLASSIFIED 
Caveats: NONE

Hi Danny,

That looks good to me.

Thanks,

-Brady

-----Original Message-----
From: Haynes, Dan [mailto:dhaynes@MITRE.ORG] 
Sent: Tuesday, February 16, 2010 2:25 PM
To: OVAL-DEVELOPER-LIST@LISTS.MITRE.ORG
Subject: Re: [OVAL-DEVELOPER-LIST] Proposal for UNIX ACL child element
(UNCLASSIFIED)

Hi Brady,

I agree that this information would be beneficial for anyone
investigating the permissions of a file.  However, I do have one
comment.  Rather than not having the 'has_extended_acl' entity present
if the interpreter or system do not support ACL, the entity could have a
status of 'not collected' if the interpreter doesn't support ACL and a
status of 'does not exist' if the system doesn't support ACL.  I think
that this would be useful because it would provide the user with more
information as to why a value for the 'has_extended_acl' entity was not
retrieved.  With these changes, and what you specified below, the
outcome of retrieving the value for the 'has_extended_acl' entity would
look something like this:

1) If an interpreter doesn't support the collection of ACL information,
the status will be 'not collected'.
2) If there is an error trying to retrieve this information, the status
will be 'error'.
3) If a system doesn't support ACLs, the status will be 'does not
exist'.
4) If a system supports ACLs, the status will be 'exists'.
5) If a file doesn't have an ACL, or it matches the standard UNIX
permissions, the value will be 'false'
6) If a file has an ACL, the value will be 'true'.

Does this make sense?  Is this along the lines of what you were
thinking?  

Thanks,

Danny

>-----Original Message-----
>From: Jeff Saxton [mailto:jeff_saxton@BIGFIX.COM]
>Sent: Tuesday, February 09, 2010 7:12 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] Proposal for UNIX ACL child element
>(UNCLASSIFIED)
>
>I like it fwiw
>
>"Alleman, Brady G CTR DISA FSO" <Brady.Alleman.ctr@DISA.MIL> wrote:
>
>
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>I would like to propose a schema change to allow for the testing for
the
>presence of file access control lists (ACLs) on UNIX platforms.  While
many
>UNIX systems support ACLs, their use and implementation are not
consistent or
>standardized.  It could be difficult to create a structure that
satisfactorily
>represents ACLs from multiple platforms.  Regardless, the existence of
a file
>ACL that contains permissions beyond those of the file's mode is a
>characteristic that would be useful in security assessment, and a
concept
>recognized by UNIX systems supporting ACLs.  Depending on the platform,
such
>ACLs are referred to as "extended," "non-trivial," or "optional."
>
>I suggest adding a boolean "has_extended_acl" child element to the
existing
>file_state element in the UNIX schema.  This element could be absent if
the
>system does not support ACLs, or the interpreter does not support ACLs
on the
>system.  The element would be false if the file has no ACL, or a
so-called
>"trivial," "minimal," or "base" ACL that exactly matches the
permissions of the
>file's mode number and ownership, and true otherwise.  This is, with a
few
>possible exceptions, the condition represented by a '+' appearing in
the
>permissions of a file as output by "ls -l".  A multiple-platform
implementation
>example of this can be found in the file-has-acl.c file of the GNU
Coreutils
>project.
>
>Does this seem like an appropriate change to support this capability,
or are
>there alternatives that should be considered?
>
>Thanks,
>
>--
>Brady Alleman
>tapestry technologies, LLC
>DISA FSO, IA Standards (CTR)
>Classification:  UNCLASSIFIED
>Caveats: NONE
>
>
>To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
OVAL-DEVELOPER-
>LIST-request@LISTS.MITRE.ORG.
>
>To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message.  If you have difficulties, write to
OVAL-DEVELOPER-
>LIST-request@LISTS.MITRE.ORG.

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to
OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.
Classification:  UNCLASSIFIED 
Caveats: NONE

To unsubscribe, send an email message to LISTSERV@LISTS.MITRE.ORG with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message.  If you have difficulties, write to OVAL-DEVELOPER-LIST-request@LISTS.MITRE.ORG.

n/a

The uid entity documentation should be updated to state that the uid entity refers to the effective user id.

n/a