|
8701
|
make it uniform throughout the schema to put references as attributes |
Open |
2006-05-23 |
n/a |
Priority:
Medium
| Category:
n/a
| Date Closed:
n/a
|
Details:
While writing OVAL that illustrated the use of the <set> element, I
noticed the following anomaly in the oval-definitions schema:
<set>
<object_reference>oval:org.cisecurity:obj:999000</object_reference>
<filter>oval:org.cisecurity:ste:999002001</filter>
<filter>oval:org.cisecurity:ste:999002002</filter>
</set>
Notice the text nodes for the references. Why are these text nodes, when
everywhere else attributes are used for object and state references?
|
Follow-ups:
n/a
|
|
14134
|
date/time entities should use the built-in xml date type |
Open |
2008-01-22 |
n/a |
Priority:
Medium High
| Category:
n/a
| Date Closed:
n/a
|
Details:
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.
|
Follow-ups:
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.
|
|
14938
|
add attribute supporting order of elements for functions like concat |
Open |
2008-04-03 |
n/a |
Priority:
High
| Category:
Definition Schemas
| Date Closed:
n/a
|
Details:
Since order of elements is lost when and XML doc is loaded into a parser, we need to add and ordering attribute to support functions like <concat> where order matters.
|
Follow-ups:
n/a
|
|
16665
|
add the divide and subtract operations to the arithmetic function |
Open |
2008-08-26 |
n/a |
Priority:
Medium
| Category:
Definition Schemas
| Date Closed:
n/a
|
Details:
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/
|
Follow-ups:
n/a
|
|
14379
|
add the ability to use xml:lang for comment attributes |
Open |
2008-02-18 |
n/a |
Priority:
Very Low
| Category:
Definition Schemas
| Date Closed:
n/a
|
Details:
The scope of xml:lang applies to both the attributes and the content of the element where it appears. One cannot specify different languages for an attribute and the element content. Therefore, avoid translatable attributes.
Don't do this:
<Book title="La ma vie et périodes">
Instead, do this:
<Book>
<Title xml:lang="fr">La ma vie et périodes</Title>
|
Follow-ups:
Date Added: 2009-05-04 09:52:28 Why can't this be supported in a minor version change?
Date Added: 2009-05-04 11:03:20 The reason this is target for Version 6 is that moving an attribute to an element seems like a significant change to the structure of elements.
Date Added: 2009-05-04 11:05:19 Sorry, i miss read the tracker item. Completely agree that this has to be a version 6 item.
|
|
10531
|
unix files: need enumeration for type, rethink nillable filename |
Open |
2007-01-22 |
n/a |
Priority:
Medium
| Category:
n/a
| Date Closed:
n/a
|
Details:
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.
|
Follow-ups:
n/a
|
|
9458
|
introduce a way to leverage content at an external location |
Open |
2006-08-01 |
n/a |
Priority:
Medium High
| Category:
n/a
| Date Closed:
n/a
|
Details:
At developer days the following feature was asked for ...
A feature to the language that could help with the relationship between external repositories was discussed. Currently in version 5.0, any <extended_definition> must reside in the document. The proposal is to have an <external_definition> that is just a reference to a definition located in some external repository. The id and location of this definition would be provided so tools can fetch the definition during evaluation. This allows extension of other's content without forcing the definition writer to pull in all the content they are extending. Note that XML Includes could be used with the current schema to accomplish something similar.
|
Follow-ups:
n/a
|
|
14428
|
add an attribute to the entity base type for case sensistivity |
Open |
2008-02-22 |
n/a |
Priority:
Very Low
| Category:
n/a
| Date Closed:
n/a
|
Details:
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
|
Follow-ups:
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?
|
|
17366
|
align all test, object, state, and item names |
Open |
2008-10-01 |
n/a |
Priority:
Medium High
| Category:
n/a
| Date Closed:
n/a
|
Details:
names should align despite the risk of duplicate constructs being defined in the schema. The upside is a big simplification to the code that associates items and objects and states across the definition schema and the sc schema.
|
Follow-ups:
Date Added: 2008-10-01 16:06:29 Currently, when a new version of a test is created during minor schema release, the test is given the name <name><version>_test. (eg fileeffectiverights53_test) But the corresponding item in the SC file does not need a new version (entities in the SC are optional) and so the existing item is used. This creates a possible issue where an exact 1:1 mapping between test names and item names does not exist.
Is this something that should be corrected? Either by always creating new items or maybe by changing how we create new version of test in a minor release?
Date Added: 2009-05-04 09:58:03 Why is this targeted for version 6? This could be version 5.6 right? it is just adding new items and deprecating old ones right?
Date Added: 2009-05-04 10:58:14 This was targeted for Version 6 since it represents a different test / item relationship. I am also not convinced that this is definetly the correct way to go so I wanted to hold off until a major version to discuss it and think it through.
|
|
9664
|
typo in sedenyremoteInteractivelogonright entity name |
Open |
2006-09-06 |
n/a |
Priority:
Low
| Category:
n/a
| Date Closed:
n/a
|
Details:
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.
|
Follow-ups:
n/a
|
|
15946
|
typo in inetlisteningservers_test name |
Open |
2008-07-09 |
n/a |
Priority:
Low
| Category:
n/a
| Date Closed:
n/a
|
Details:
One small inconsistency I noticed is that there is an object and state (in the Linux schema) called inetlisteningservers but the item in the SC schema is called inetlisteningserver.
|
Follow-ups:
Date Added: 2009-05-04 09:59:02 why is this not targeted for version 5.6?
Date Added: 2009-05-04 10:55:05 This is targeted for version 6 since changing the element name (i.e. fixing the typeo) will invalidate existing comment
Date Added: 2009-05-04 10:56:54 Can't we create a new correctly named item in the SC and deprecate the old one? No need to rename anything.
|
|
19734
|
PIXOS line_test doesn't seem to be setup to work off of a single line |
Open |
2009-05-12 |
n/a |
Priority:
Medium
| Category:
Definition Schemas
| Date Closed:
n/a
|
Details:
>-----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
|
Follow-ups:
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"
|
|
20466
|
limit the flag entity of the unix-def:interface_state and unix-sc:interface_item to an enumeration |
Open |
2009-07-14 |
n/a |
Priority:
Medium
| Category:
n/a
| Date Closed:
n/a
|
Details:
>b) Changing the type of the "flag" entity to be an enumeration of flag
>strings, e.g. (UP, MULTICAST, etc. See /usr/include/net/if.h).
>
I looked at a couple of different unix systems and it seems like this might be a reasonable set to start with:
IFF_UP = 0x1, /* Interface is up. */
IFF_BROADCAST = 0x2, /* Broadcast address valid. */
IFF_DEBUG = 0x4, /* Turn on debugging. */
IFF_LOOPBACK = 0x8, /* Is a loopback net. */
IFF_POINTOPOINT = 0x10, /* Interface is point-to-point link. */
IFF_NOTRAILERS = 0x20, /* Avoid use of trailers. */
IFF_RUNNING = 0x40, /* Resources allocated. */
IFF_NOARP = 0x80, /* No address resolution protocol. */
IFF_PROMISC = 0x100, /* Receive all packets. */
Are there any concerns with limiting the enumeration in OVAL to just this set?
Given that this is a restriction on the valid data this should probably be a change for the next major version.
|
Follow-ups:
n/a
|
|
23827
|
Create enumeration types for certain xinetd_item entities |
Open |
2009-10-14 |
n/a |
Priority:
Medium
| Category:
System Characteristics Schemas
| Date Closed:
n/a
|
Details:
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
|
Follow-ups:
n/a
|
|
24971
|
typo in security_principle entities |
Open |
2010-02-17 |
n/a |
Priority:
Medium
| Category:
n/a
| Date Closed:
n/a
|
Details:
There is a typo in any text that says security_principle. It should be security_principal. Please see http://technet.microsoft.com/en-us/library/cc780957(WS.10).aspx for more information.
|
Follow-ups:
n/a
|
|
24134
|
deprecate win-def:uac_test since uac settings are simply stored in the registry |
Open |
2009-11-17 |
n/a |
Priority:
Very Low
| Category:
Definition Schemas
| Date Closed:
n/a
|
Details:
the uac_test is not needed. see:
http://n2.nabble.com/Is-the-win-def-uac-test-Necessary-tp3999228ef20093.html
|
Follow-ups:
n/a
|
|
10567
|
add schematron rules to ensure values match datatypes |
Open |
2007-01-23 |
n/a |
Priority:
Low
| Category:
Definition Schemas
| Date Closed:
n/a
|
Details:
Our current schematron rules won't catch the following:
<registry_state id="oval:org.mitre.oval:ste:500" version="1">
<value datatype="int">10.0.8326.0</value>
</registry_state>
The value of <value> is clearly not an int. It would be helpful if we had schematron rules that check the value of an element to make sure it matches the datatype specified.
|
Follow-ups:
Date Added: 2007-04-18 12:29:10 in version 5.3 added some schematron statements to check that the value is an int when the datatype is set to an int. still need to find a way to do the same for the other datatypes.
|
|
26310
|
make case insensitive equals the default operation for entities that are natively case-insensitive |
Open |
2010-06-04 |
n/a |
Priority:
Medium
| Category:
Definition Schemas
| Date Closed:
n/a
|
Details:
>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
|
Follow-ups:
n/a
|
|
26733
|
consider using xml namespaces to differentiate revisions to tests within a major version |
Open |
2010-07-06 |
n/a |
Priority:
Medium
| Category:
n/a
| Date Closed:
n/a
|
Details:
in the next major release of OVAL we need to consider using xml namespaces to differentiate versions of tests rather than renaming the test with each revision as is the practice in version 5.X
|
Follow-ups:
n/a
|
|
26179
|
make oval ids compatible with namespaces in xml 1.0 |
Open |
2010-05-25 |
n/a |
Priority:
Medium
| Category:
n/a
| Date Closed:
n/a
|
Details:
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/
|
Follow-ups:
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
|
|
8700
|
allow the use of filters at the set level instead of just the object reference level |
Closed |
2006-05-23 |
Fixed |
Priority:
Very Low
| Category:
Definition Schemas
| Date Closed:
2010-09-21 14:48:30
|
Details:
It has been mentioned that it would be nice to be able to apply filters to sets instead of just object references. Could we allow filters in both places? This would make content writing easier and would eliminate the need for some temporary objects. With the design in V5, if you want to create a set, and then perform a filter, you have to create a temporary object and then use an object reference in a new set an apply the filter to this.
|
Follow-ups:
Date Added: 2010-09-21 14:48:30 This feature request has been over come by the addition of filters on objects in version 5.8.
|
|
28629
|
spelling mistake in an entity name in the sol-def:smf_state and the sol-sc:smf_item |
Open |
2010-12-05 |
n/a |
Priority:
Medium
| Category:
n/a
| Date Closed:
n/a
|
Details:
The server_arguements entity in the sol-def:smf_state and the sol-sc:smf_item should be changed to server_arguments.
|
Follow-ups:
n/a
|
|
14072
|
change the epoch entity of rpminfo_test from string to int |
Open |
2008-01-15 |
n/a |
Priority:
Medium
| Category:
n/a
| Date Closed:
n/a
|
Details:
From Todd Dolinsky,
I also have a suggestion regarding the current use of the epoch element inside of the rpminfo_object of the linux-definitions-schema. Currently the epoch is listed as a "string", i.e.
It is my understanding that valid values for the epoch are always integers or the string "(none)". As the current schema mentions, "(none)" is equivalent to 0, so I would suggest modifying the datatype of the epoch to int from string. This will of course imply that OVAL authors won't be able to use "(none)" - they'll have to use 0 instead. The 'pattern match' operation would therefore no longer be allowed.
I think on the whole this seems to make more sense than using comparison operators against strings.
|
Follow-ups:
Date Added: 2010-08-05 14:52:47 As of version 5.8 the schema documentation will be updated to say that instead of an epoch value of '0' the string '(none)' should be used. In a later major revision the type of this entity should be changed to an int as suggested/ For the time being the impact to content and tools will be to large to justify the change.
The documentation change will be included in draft 6 of version 5.8.
|