Open Vulnerability and Assessment Language

For the Windows file test, the a_time, c_time, and m_time entities should be changed from ints to the built-in xml date/time datatype.

Date Added: 2008-04-02 14:16:33
This should not be just limited to the window file test, but all date/time entities should use the built-in xml date type.  We should create a new entity type for this.

We need the required position attribute on a component to add these operations in.  The position attribute is scheduled to be added for version 6.0/

n/a

Unix file_state includes a <type> entity, defined as an oval-def:EntityStateStringType.  This effectively does not specify what are the valid values for <type>.  We should enumerate these in a future version of OVAL, so this field can be used effectively.

The schema documentation says:

"This is the file's type: regular file (regular), directory, named pipe (fifo), symbolic link, socket or block special."

The (Solaris) system include file /usr/include/sys/stat.h lists the following types:

#define S_IFIFO         0x1000  /* fifo */
#define S_IFCHR         0x2000  /* character special */
#define S_IFDIR         0x4000  /* directory */
#define S_IFNAM         0x5000  /* XENIX special named file */
#define S_INSEM         0x1     /* XENIX semaphore subtype of IFNAM */
#define S_INSHD         0x2     /* XENIX shared data subtype of IFNAM */
#define S_IFBLK         0x6000  /* block special */
#define S_IFREG         0x8000  /* regular */
#define S_IFLNK         0xA000  /* symbolic link */
#define S_IFSOCK        0xC000  /* socket */
#define S_IFDOOR        0xD000  /* door */

(The XENIX types can probably be ignored.)

We should probably also reconsider whether the <filename> of a file_object should be nillable.  If you want to test whether directory /etc/foo exists, you could have a file_object with path of /etc, filename of foo, and a file_state that checks for type=directory.

n/a

My concern (from SQL Server development experience) is that there will
be proliferation over time of more items (factorial)

I would prefer to see a @sensistivity attribute added instead, this
would consist of a list of up to 4 of the following pairs.

* CI, CS :Case Insensitive
* AI, AS: Accent Insensitive
* KI, KS: Kana Insensitive
* WI, WS: Width Insensitive

Remember -- SQL Server tests are inscope and thus the above may occur in
some cases in the SQL world. We have not seen it --- but "they have
built it, the need will come".

- Ken Lassesen

Date Added: 2008-02-22 12:44:13
in version 5.4 we added case insensitive operations.  for version 6, should we consider an attribute?

for both the accesstoken_state (win:def schema) and the accesstoken_item (win:sc schema) there is a typo.  the 'I' in sedenyremoteInteractivelogonright should not be capitalized.

n/a

>-----Original Message-----
>From: Matt Woodyard [mailto:matt@MATTWOODYARD.COM]
>Sent: Friday, May 01, 2009 4:18 PM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: [OVAL-DEVELOPER-LIST] pixos_object
>
>In the pix schema there is a line_object. If one uses the following
>
><line_object><show_subcommand>running-
>config</show_subcommand></line_object>
>
>Should this generate a set of line_items (one for each line of config)
>or one line_item with the entire config in it?
>
>matt




>-----Original Message-----
>From: Buttner, Drew [mailto:abuttner@MITRE.ORG]
>Sent: Tuesday, May 12, 2009 11:12 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] pixos_object
>
>I think the way the schema is written that there should be one
><line_item> in the system characteristic file should contain the entire
>config in it.  I agree that the documentation and wording is a bit
>confusing.  We will try to update this with the results of this thread.
>
>Question:  Do the other SHOW commands result in one line from the
>config?
>
>Thanks
>Drew





>-----Original Message-----
>From: Matt Woodyard [mailto:matt@MATTWOODYARD.COM]
>Sent: Tuesday, May 12, 2009 11:31 AM
>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>Subject: Re: [OVAL-DEVELOPER-LIST] pixos_object
>
>I'm not sure what you mean about the other SHOW commands. There are
>plenty of show commands in the PIX/IOS that don't pull lines from the
>config(eg show mac-address-table). They pretty universally produce
>chunks of newline/space delimited text that has some sort of meaning.
>
>My personal preference would be to rework all the cisco (PIX, IOS,etc)
>schemas to have the line_* look like the independent schema
>textfilecontent_*. I find myself wanting to write content for line_tests
>in the same way I would write them for handling a textfilecontent_test.
>
>matt

Date Added: 2009-07-09 12:10:32
http://www.cisco.com/en/US/docs/ios/12_1/configfun/command/reference/frd2002.html#wp1019218


Question:  For the example used in the webpage above, would the OVAL Object use

"running-config"

or

"show running-confi interface serial 1"

The following entities should have enumeration types:

flags: INTERCEPT, NORETRY, IDONLY, NAMEINARGS, NODELAY, KEEPALIVE, NOLIBWRAP, SENSOR, IPv4, IPv6, LABELED, REUSE

socket_type: stream, dgram, raw, seqpacket

n/a

the uac_test is not needed. see:

http://n2.nabble.com/Is-the-win-def-uac-test-Necessary-tp3999228ef20093.html

n/a

>Alternatively, the OVAL windows-definitions-schema.xsd could be 
>modified to define an EntityStateRegistryValueType whose default 
>operation is "case insensitive equals". I think this would most 
>closely match what people would expect to happen when defining 
>registry states. A similar thing could be done for 
>EntityStateRegistryHiveType, EntityStateRegistryKeyType, and 
>EntityStateRegistryNameType. 

I like the suggestion, but I think I would go for just defining something like EntityStateStringIType and EntityObjectStringIType where these entities would have a default operation of "case insensitive equals". These could be used fairly widely in the windows schema. 

However, if we simply created the new schema types and then based the relevant entities on this new type we would be changing the meaning of essentially all windows content, despite the fact that this is a small change to the actual schema. This change would not make existing content fail schema validation, but it would change the meaning of a large portion of the existing content. My inclination is to log this as an issue to address in a major version where it is assumed that we will make changes that will significantly impact existing content. 

Please see the following link for additional information.

http://making-security-measurable.1364806.n2.nabble.com/Windows-case-insensitivity-tp4101606.html

n/a

Has it been brought to anyone's attention that the oval "id" and
"ref_id" attributes are invalid according to Namespaces in XML 1.0[1]? I
ran across this non-conformance while testing for XML Encryption
compatibility.

Here's the relevant statement:

<snip>
No attributes with a declared type of ID, IDREF(S), ENTITY(IES), or
NOTATION contain any colons.
</snip>

Also, I might inject at this time that as of the 2nd Edition of XML
Signature Syntax[2] and Processing that the "xml:id" attribute is the
recommended define for an id attribute. I have tested the oval schemas
and a change would be necessary to accommodate the xml namespace
declaration.

From stdout:
<snip>
Severity: Error
Message: Attribute 'id' should be un-qualified
</snip>

Cheers.
Thomas


[1] http://www.w3.org/TR/REC-xml-names/
[2] http://www.w3.org/TR/xmldsig-core/

Date Added: 2010-09-03 10:38:58
The easiest solution I see would be to change the delimiter used in the OVAL id attributes. Use "/" instead of ":".

Date Added: 2010-09-20 10:30:14
Can't use "/", it is not a valid NCName character.
How about "-"?
http://www.w3.org/TR/REC-xml-names/#NT-NCName

The server_arguements entity in the sol-def:smf_state and the sol-sc:smf_item should be changed to server_arguments.

n/a